다중 연속 사용
여러 활동이 있는 환경에서 TPE(추적 프로필 편집기)를 사용하려면 수신 포트, 오케스트레이션 및 송신 포트를 적절한 순서대로 매핑하기 위해 활동을 추적하는 시나리오를 이해해야 합니다.
추적 프로필에서 TPE는 활동의 처음과 끝을 자동으로 평가합니다. 활동은 첫 데이터 조각이 수집될 때 시작되고 마지막 데이터 조각이 수집될 때 끝납니다.
대부분의 경우 두 오케스트레이션 간 연속과 같은 단일 연속을 만드는 것은 개발자에게 있어 매우 간단한 작업입니다. 그러나 다중 연속의 경우에는 복잡한 TPE 작업이 필요합니다. 여러 연속 시나리오에서는 BAM(비즈니스 활동 모니터링) 활동이 여러 수신 포트, 오케스트레이션 및 송신 포트에 걸쳐 있습니다. BAM 데이터를 하나의 레코드로 수집하려면 모든 BizTalk Server 일정 간에 연속을 만들어야 합니다. 이 과정은 TPE UI(사용자 인터페이스)를 통해 완료할 경우 복잡할 수 있습니다.
이 항목에서는 여러 시나리오에서 단일 및 다중 연속을 만드는 방법에 대해 설명합니다.
기본 시나리오 설명 – 여러 수신 포트, 오케스트레이션 및 송신 포트
이 시나리오는 수신 포트(R), 오케스트레이션(O) 및 송신 포트(S)가 여러 개 있는 BizTalk Server로 구성됩니다. 연속을 연결하는 데에는 일반 interchangeID 컨텍스트 속성이 사용됩니다. activityID 또는 기타 고유한 식별자와 같은 모든 컨텍스트 속성을 사용할 수 있습니다. 이 시나리오는 특정 콘텐츠와 관계가 없습니다.
이 시나리오에서는 이러한 포트 및 오케스트레이션에서 추적되는 데이터 항목/마일스톤/컨텍스트-속성-값에 대해 설명하지 않습니다. 매핑과 관련된 이러한 부분은 비즈니스 논리에 따라 달라집니다. 이 시나리오에서는 완료된 활동 테이블에 있는 단일 행의 모든 포트 및 오케스트레이션에서 모든 BAM 데이터를 캡처하는 것이 목표입니다. 오케스트레이션에서 메시지를 받아 처리할 수 있는 다양한 방법이 존재하며, 이러한 방법은 저마다 흥미로운 문제점과 솔루션을 갖고 있습니다.
참고
하나의 포트나 하나의 오케스트레이션으로 구성된 시나리오는 많은 포트와 많은 오케스트레이션으로 구성된 시나리오의 특수 사례로 간주될 수 있습니다.
시나리오 솔루션 1 – 하나의 수신 포트 및 하나의 오케스트레이션
이 시나리오에서 메시지는 정확히 하나의 수신 포트(R1)에 도착하고 정확히 하나의 오케스트레이션(O1)에 의해 처리됩니다.
연속을 만드는 과정은 다음과 같습니다.
추적 프로필의 폴더 활동 트리 보기에서 연속을 만듭니다.
이벤트 원본 선택 단추를 클릭한 다음 상황에 맞는 속성 선택 메뉴 항목을 클릭하여 컨텍스트 속성 스키마를 선택합니다.
Context 속성 이름 목록에서 interchangeId 속성을 찾은 다음 선택합니다.
속성 스키마에서 방금 만든 연속 폴더에 interchangeID를 매핑합니다.
활동 트리에서 새로 만든 interchangeID 노드를 마우스 오른쪽 단추로 클릭한 다음 매핑할 포트를 선택합니다.
표시되는 포트 선택 대화 상자에서 모든 N 수신 포트를 선택합니다.
폴더 활동 트리에 continuationID 폴더를 만듭니다.
이벤트 원본 선택 단추를 클릭한 다음 오케스트레이션 일정 선택 메뉴 항목을 클릭하여 각 오케스트레이션을 엽니다. 각 오케스트레이션에서 오케스트레이션의 한 셰이프를 마우스 오른쪽 단추로 클릭한 다음 interchangeID 컨텍스트 속성을 새로 만든 continuationID에 매핑합니다.
세 개의 오케스트레이션이 있는 배포에서 추적 프로필은 다음과 같습니다.
시나리오 솔루션 2 – 하나의 수신 포트 및 여러 오케스트레이션
이 시나리오에서 메시지는 정확히 하나의 수신 포트에 도착하고 모든 오케스트레이션에 의해 처리됩니다. 이는 각 오케스트레이션에 메시지가 동시에 전송될 때 발생합니다.
이 경우 각 오케스트레이션에 대해 하나의 연속과 continuationID가 필요합니다. 연속 작업을 만드는 프로세스는 시나리오 솔루션 1에 설명된 단계와 유사합니다. 3개 오케스트레이션 배포의 경우 결과 추적 프로필은 다음과 같습니다.
시나리오 솔루션 3 - 콘텐츠 기반 라우팅
이 시나리오에서는 CBR(콘텐츠 기반 라우팅) 솔루션을 정의합니다. 메시지는 정확히 하나의 수신 포트에 도착하고 정확히 하나의 송신 포트에 전송됩니다. 이 라우팅은 메시지의 컨텍스트 속성 값을 기반으로 발생합니다. 이 경우 하나의 연속이 필요합니다. 매핑은 다음과 같습니다.
참고
위의 매핑은 정확히 하나의 수신 포트에 도착하고 모든 송신 포트에 전송되는 메시지에 대해서도 유효합니다.
시나리오 솔루션 4 – 하나의 오케스트레이션, 여러 송신 포트
이 시나리오에서는 여러 송신이 있습니다. 포트와 같은 HBA(호스트 버스 어댑터) 초기자 포트를 가져오고 표시합니다. 메시지는 처리 규칙에 의해 결정되고 모든 송신 포트로 전송되는 오케스트레이션 중 하나에 의해 정확히 처리됩니다. 이 경우 하나의 연속이 필요합니다. 매핑은 다음과 같습니다.
시나리오 솔루션 5 – 순차 오케스트레이션
이 시나리오에서 메시지는 각 오케스트레이션에 의해 순서대로 하나씩 처리되고 연속을 통해 다음 오케스트레이션으로 전달됩니다. 매핑은 다음과 같습니다.
비동기 환경에서 데이터 수집
연속을 설정하는 경우 BAM은 데이터가 도착할 것이라고 예상합니다. 비동기 환경에서는 백 엔드 프로세스로부터 응답을 받지 못할 수 있습니다.
응답 데이터를 받지 못한 경우 활동 인스턴스는 무기한으로 대기합니다. 활동은 절대 완료되지 않으며 레코드는 BAM 기본 가져오기 데이터베이스의 테이블에 남아 있습니다. 나머지 데이터가 도착할 시기를 알 수 없는 장기 실행 트랜잭션의 경우 비즈니스 논리 또는 프로세스에 따라 데이터 도착이 달라지므로 시간 제한이 없으며 데이터가 도착하면 활동이 완료된 것으로 표시됩니다. 데이터는 같은 날에 도착할 수도 있고, 최악의 경우 다음 해에 도착할 수도 있습니다.
이 경우 관련 활동을 사용하면 됩니다.
활동을 두 개의 활동으로 분할합니다. 두 개의 활동을 연결하고 응답을 원래 활동에 연결합니다.
관련 활동에 대한 자세한 내용은 활동 관계를 참조하세요.