다음을 통해 공유

TPE에 대한 고려 사항 및 알려진 문제

  • 아티클

추적 프로필 및 TPE를 사용할 때는 다음 문제를 고려해야 합니다.

TPE에서 폴더 이름 지정

추적 프로필 편집기에서 폴더 이름을 지정할 때는 다음과 같은 명명 요구 사항에 따라야 합니다.

  • 폴더 이름과 데이터 항목 인스턴스 값을 합한 길이는 128자를 초과할 수 없습니다.

  • Continuation 및 ContinuationID 폴더의 경우 폴더 이름 지정 방식이 두 오케스트레이션 간에 상관 관계를 형성하는 데 핵심적인 요인이 됩니다. 예를 들어 오케스트레이션 A가 오케스트레이션 B의 부모이면 오케스트레이션 A는 오케스트레이션 B의 ContinuationID 폴더에 직접 매핑되는 이름을 가진 연속 폴더 이름을 포함합니다.

TPE에 대한 오케스트레이션 개발

오케스트레이션이 잘못된 셰이프로 시작하거나 끝날 경우 오케스트레이션을 비즈니스 활동에 매핑할 수 없습니다. 오케스트레이션 엔진은 다음을 비롯한 일부 셰이프에 대한 추적을 아래에 이 계정과 키의 예제가 나와 있습니다.

  • Message Assignment

  • 변환

  • Group(작업)

  • 일시 중지됨

  • Loop(While)

  • Branch

  • 종료

  • Throw

  • Catch

  • While

    추적 프로필 편집기 및 기타 BAM 도구에서 사용할 수 있도록 비즈니스 활동에 매핑할 경우 다음 지침을 따르십시오.

  • Group 셰이프의 경우 비트랜잭션 Scope 셰이프를 사용합니다.

  • While 셰이프의 경우 비트랜잭션 Scope 셰이프에 래핑합니다.

  • Terminate 셰이프의 경우 일반적인 시나리오에서 종료 이벤트는 발생하지 않으므로 해결 방법이 없습니다.

  • 끌어서 놓기 작업이 허용되지 않는 셰이프를 사용하여 일정을 시작하거나 종료하지 않도록 합니다.

실행 프로세스를 모니터링하는 추적 프로필 적용

추적 프로필을 업데이트하면 활동에 BAM Continuation이 포함된 경우 진행 중인 활동 인스턴스에 영향을 줄 수 있습니다. 특히 추적 프로필에 대한 업데이트에서 이미 기록된 활동 항목에 대한 데이터의 다운스트림 가로채기를 지정하는 경우 원래 값을 덮어쓸 수 있습니다. 기본적으로 모든 단일 이벤트 스트림은 활동/스트림이 시작된 시간에 해당 위치에 있던 프로필의 특정 버전에 각 스트림 개체가 연결되기 때문에 추적 프로필 업데이트 응용 프로그램의 영향을 받지 않습니다. 하지만 Continuation은 여러 이벤트 스트림의 상관 관계를 지정하는 방법이기 때문에 프로필 업데이트 시 아직 시작되지 않은 스트림은 업데이트에서 변경 내용을 선택하므로 앞에서 설명한 대로 데이터를 덮어쓸 수 있게 됩니다. 연속 작업에 대한 자세한 내용은 활동 연속 및 연속 을 만드는 방법을 참조하세요.

메시지 속성을 가져올 Send 또는 Receive 셰이프가 없는 추적 프로필

Continuation은 활동 간에 동일한 컨텍스트 속성 또는 페이로드 데이터를 통해 활동을 추적합니다. 메시지 ID, 서비스 ID 및 인스턴스 ID와 같은 속성은 활동 간에 값이 달라집니다.

다음 방법을 사용하여 이러한 시나리오를 해결할 수 있는 추적 프로필을 만들 수 있습니다.

  • 오케스트레이션이 다른 오케스트레이션과의 동적 바인딩을 통해 메시지를 전송하면 고유한 전역 페이로드 데이터 값을 Continuation에 사용할 수 있습니다.

  • 메시지에 고유한 페이로드 데이터가 없으면 메시지의 교환 ID를 사용할 수 있습니다. 교환 ID를 사용하려면 동일한 Receive 셰이프에서 추적해야 합니다. 새 메시지를 만들어지면 교환 ID가 변경되므로 새 메시지를 만들 때 교환 ID를 사용할 수 없습니다. Receive 또는 Send 셰이프 이외의 셰이프에서 교환 ID를 추적할 경우 결과를 신뢰할 수 없습니다.

  • 파이프라인에서 수신된 정확히 동일한 메시지가 오케스트레이션에 사용될 경우 메시지 ID를 사용할 수도 있습니다. 즉, 오케스트레이션 포트는 파이프라인에 바인딩되어 있으며 Receive 셰이프와 메시지 ID가 해당 위치에서 추적됩니다. 다른 셰이프에서 메시지 ID를 추적하면 해당 메시지 ID를 Continuation에 사용할 수 없습니다.

  • 오케스트레이션이 다른 오케스트레이션을 호출하고 메시지가 전달되지 않거나 오케스트레이션이 다른 오케스트레이션을 호출하지만 호출 수신자에게 페이로드 데이터 값을 검색할 수 있는 생성, 수신 또는 보내기 셰이프가 없는 경우 사용자는 instance ID를 사용할 수 있습니다. 호출된 오케스트레이션에 대한 instance ID는 변경되지 않습니다.

  • 오케스트레이션이 직접 호출이 아닌 실행 호출을 통해 다른 오케스트레이션을 로드할 경우 정적 메시지 속성을 사용하여 활동을 추적할 수 없습니다. 또한 사용자는 Continuation을 활성화할 수 없습니다. 이러한 경우에는 추적할 고유한 페이로드 데이터가 포함된 파이프라인을 메시지가 통과하는 경우에만 추적이 가능합니다.

세션 ID를 통과 파이프라인에 대한 Continuation 토큰으로 사용할 수 없음

추적 프로필에서 메시지 페이로드의 항목을 선택하면 추적 프로필이 해당 메시지의 스키마에 바인딩됩니다. 통과 파이프라인에서 스키마 이름 값은 Null 값입니다. BAM이 포트 이름 및 스키마 이름별로 구성을 로드하려고 하면 세션 ID 스키마와 일치하는 항목을 찾을 수 없으며 엔진에서 어떠한 데이터도 추적하지 않습니다.

통과 파이프라인의 경우 추적 프로필에서 모든 페이로드 추적을 제거할 수 있으며, 페이로드 데이터를 추적해야 할 경우에는 XML 파이프라인을 사용할 수 있습니다.

고유한 포트 이름 사용

TPE는 양방향 포트를 열거할 때 두 개의 논리적 포트인 송신 및 수신 포트로 표시합니다. 이러한 각 논리적 포트는 같은 이름으로 표시됩니다. BizTalk Server에서는 같은 이름을 사용하여 단방향 포트와 양방향 포트를 만들 수 있습니다. 예를 들어 이름이 "Port1"인 양방향 포트를 만든 후 같은 이름으로 수신 포트를 만들 수 있습니다. 이러한 경우 TPE는 수신 포트는 한 번 표시하고 양방향 포트는 두 번(수신 포트로 한 번, 송신 포트로 한 번) 표시합니다.

이 경우 TPE는 두 수신 포트에 추적 프로필을 적용합니다. 따라서 포트를 제대로 식별할 수 있도록 고유한 이름을 지정하는 것이 좋습니다.

첫 번째 셰이프가 Parallel 셰이프인 TPE 오케스트레이션 사용

Fork, Parallel 또는 Listen 셰이프로 오케스트레이션을 시작할 경우 분기 중 하나에 활동 ID를 매핑할 수 없습니다. 병렬 처리의 경우 Fork 셰이프 위에 ActivityID를 매핑할 수 있습니다. 또한 오케스트레이션 맨 위에서 Parallel 셰이프 문제가 발생하지 않도록 BAM을 통해 활동 ID를 생성할 수도 있습니다.

중요

활동을 둘 이상의 경로에 매핑하고 ActivityID를 Fork 셰이프의 한 경로에 매핑하면 ActivityID가 매핑되지 않은 경로를 따라 처리가 수행될 경우 오류가 발생합니다.

디자인 타임에서의 메시지 속성 가용성

추적 프로필을 만들 때 모든 메시지 속성을 사용할 수 있는 것은 아닙니다. 매핑한 메시지 속성의 원본 셰이프가 오케스트레이션 맨 위에 있을 때 이러한 문제가 가장 발생하기 쉽습니다. 이러한 경우 메시지 속성 값이 Null입니다.

Listen 셰이프가 오케스트레이션의 첫 번째 셰이프인 경우가 여기에 해당합니다. 메시지 속성이 이 셰이프에서 매핑되는 경우 InstanceID, ServiceID 및 ServiceClassID의 값만 있습니다. MessageID는 이 시점에서 범위 내에 없으므로 Null 값을 갖습니다.

마일스톤을 보고하기 위해 Loop 셰이프 내에 셰이프를 매핑할 수 없음

TPE는 Loop 셰이프 내에서 포함된 소스가 루프 외부의 항목에 매핑된 활동으로 매핑되지 못하도록 합니다.

반복 활동은 오케스트레이션 내에서 반복되는 액션을 참조합니다. 오케스트레이션 내에서 반복되는 액션에서 이벤트를 캡처할 수 있습니다. 이렇게 하려면 다른 활동을 만든 후 새 활동 마일스톤 및 데이터를 모두 루프 내에 매핑합니다. 루프에서 예약된 실행마다 데이터 처리가 두 번 이상 발생하므로 이 작업이 필요합니다.

예를 들어 한 루프 내에서 처리되는 여러 품목을 포함하는 구매 주문서가 있을 경우 "품목 가격이 $100인 구매 주문서는 무엇입니까?"라는 질문은 모호합니다. 다음과 같은 질문이 명확합니다.

가격이 $100인 품목을 포함하는 구매 주문서는 무엇입니까?

총 품목 가격/최소 품목 가격/최대 품목 가격이 $100인 구매 주문서는 무엇입니까?

명확한 질문을 만들려면 품목을 구매 주문서와는 별개로 생각해야 합니다. 추적 프로필 편집기에서 루트 활동(예: 구매 주문서)은 루프 외부의 모든 액션에 매핑됩니다. 자식 활동(예: 품목)은 루프 내의 액션에 매핑됩니다.

이러한 유형의 구성체를 사용하는 일반적인 방법은 반복 루프를 분해하고 관련 활동이 외부 활동과 연관된 내부 활동에 기반을 두도록 하는 것입니다.

페이로드 항목을 루트 활동에 대한 ActivityID로 사용해야 하며 루프 내의 일부 메시지에서 이 페이로드 항목을 사용할 수 있어야 합니다. 활동을 자식 활동 아래에 표시되는 관계 노드에 매핑한 후 루트 활동으로 명명합니다.

여러 응용 프로그램에 걸쳐 있는 추적 프로필

추적 프로필이 여러 응용 프로그램에 걸쳐 있는 경우 솔루션의 모든 응용 프로그램을 배포한 후 추적 프로필을 배포해야 합니다. 추적 프로필이 배포된 마지막 항목이 아닌 경우 배포 마법사에서 BTTDeploy.exe 호출할 때 "매핑 원본을 찾을 수 없습니다."라는 메시지가 표시됩니다.

여러 BizTalk Server 아티팩트를 문서 참조 URL 또는 MessageID 노드에 매핑

TPE에서는 여러 BizTalk Server 아티팩트를 동일한 문서 참조 URL 또는 MessageID 노드에 끌어다 놓을 수 있습니다.

여러 소스가 특정 BAM 활동의 동일한 항목에 매핑되는 경우 BAM 처리 중에 마지막으로 나온 아티팩트가 추적 데이터에 포함된 아티팩트이며 BAM 포털에서 볼 수 있습니다.

BizTalk 솔루션 버전과 일치하도록 BTT 버전 업데이트

BAM 개발자 및 운영자는 BTT 파일 업데이트를 자동화하여 추적 프로필과 BizTalk 솔루션 간에 버전을 동기화 상태로 유지 관리할 수 있습니다. 이렇게 하려면 BTT 파일의 DataLevel 요소에서 Version 특성을 수정합니다. 다음 예제 요소에서는 TargetAssemblyName 및 SchemaName 특성에 있는 버전 정보를 수정할 수 있습니다.

<DataLevel Name="City" SourceTypeSelected="Messaging Payload" TargetAssemblyName="TheImplementationOfOrderMgmt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c5b33e44ffa4658b" SchemaName="TheImplementationOfOrderMgmt.PurchaseOrder,TheImplementationOfOrderMgmt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c5b33e44ffa4658b" SomXPath="/*[local-name()='<Schema>' and namespace-uri()='http://TheImplementationOfOrderMgmt.PurchaseOrder']/*[local-name()='PurchaseOrder' and namespace-uri()='http://TheImplementationOfOrderMgmt.PurchaseOrder']/*[local-name()='Header' and namespace-uri()='']/*[local-name()='ShipTo' and namespace-uri()='']/@*[local-name()='City' and namespace-uri()='']" XPath="/*[local-name()='PurchaseOrder' and namespace-uri()='http://TheImplementationOfOrderMgmt.PurchaseOrder']/*[local-name()='Header' and namespace-uri()='']/*[local-name()='ShipTo' and namespace-uri()='']/@*[local-name()='City' and namespace-uri()='']" IsBeginActivity="true" IsEndActivity="false">

일부 오케스트레이션 셰이프는 TPE에서 추적할 수 없음

오케스트레이션 엔진은 다음 셰이프에 대한 이벤트를 생성하지 않으므로 TPE에서 이러한 셰이프를 추적 또는 매핑할 수 없습니다.

  • Task

  • 모든 분기

  • 일시 중지됨

  • 종료

  • Throw

  • Catch

  • MessageAssignment(Construct 셰이프에 속하므로)

  • Transform(Construct 셰이프에 속하므로)

  • 반복

TPE에서 배포된 추적 프로필을 검색할 수 없음

추적 프로필을 업그레이드하거나 다시 배포한 경우 배포한 추적 프로필을 검색하지 못할 수 있습니다. 이 문제는 BizTalkMgmtDb 데이터베이스의 서버 이름이 레지스트리에 저장되는 방식이 일치하지 않기 때문에 발생할 수 있습니다.

BizTalkMgmtDb는 그룹을 구성하는 동안 레지스트리에 기록됩니다. TPE에서는 이 항목을 사용하여 기본 가져오기 데이터베이스를 찾고 추적 프로필을 필터링합니다.

구성하는 동안 몇 가지 형식으로 서버 이름을 입력할 수 있습니다. 예:

  • mgmtsvr1316267,15001\inst

  • MGMTSVR1316267\inst,15001

    TPE에서는 레지스트리 항목을 사용할 때 기본 문자열 비교를 수행합니다. 배포된 추적 프로필을 검색하려면 저장된 서버 및 데이터베이스 이름을 검사하고 TPE 관리 데이터베이스 설정 대화 상자에 입력해야 합니다.

서버 및 데이터베이스 이름 구문을 확인하여 BizTalk 관리 데이터베이스에 입력하려면 다음을 수행하십시오.

  1. BizTalk Server사용자 지정 Configuration Manager 엽니다. 사용자 지정 Configuration Manager 사용하는 방법에 대한 자세한 내용은 BizTalk Server 구성을 참조하세요.

  2. 탐색 창에서 그룹을 선택하여 그룹 구성 페이지를 엽니다.

  3. 데이터 저장소 그리드에서 서버 이름 및 데이터베이스 이름의 형식을 확인합니다.

  4. TPE를 열고 도구 메뉴 항목을 선택합니다.

  5. 관리 데이터베이스 설정 메뉴 항목을 선택하여 관리 데이터베이스 설정 대화 상자를 엽니다.

  6. SQL Server 텍스트 상자에 사용자 지정 Configuration Manager 그룹 페이지의 데이터 저장소 그리드의 서버 이름 필드에 사용된 서버 이름을 입력합니다.

  7. 데이터베이스 이름 텍스트 상자에 사용자 지정 Configuration Manager 그룹 페이지의 데이터 저장소 그리드의 데이터베이스 이름 필드에 사용된 데이터베이스 이름을 입력합니다.

  8. 확인 단추를 클릭하여 항목을 저장합니다.

참고 항목

TPE 사용
Tracking Profile Editor(추적 프로필 편집기)