오케스트레이션 은 MessageBox 데이터베이스를 통해 메시지를 구독(수신)하고 게시(보내기)할 수 있는 실행 가능한 비즈니스 프로세스입니다. 또한 오케스트레이션은 새 메시지를 생성할 수 있습니다. 메시지는 메시지의 수명 주기에 설명된 구독 및 라우팅 인프라를 사용하여 수신됩니다. 구독이 오케스트레이션을 위해 채워지면 새 인스턴스가 활성화되고 메시지가 배달되거나 인스턴스 구독의 경우 필요한 경우 인스턴스가 리하디드되고 메시지가 전달됩니다. 오케스트레이션에서 메시지를 보내면 적절한 속성이 라우팅에 사용하기 위해 데이터베이스에 삽입되는 수신 위치에 도착하는 메시지와 동일한 방식으로 MessageBox에 게시됩니다.
오케스트레이션에서 생성된 메시지는 MessageBox 데이터베이스에 배치되고 오케스트레이션 인스턴스에서 참조해야 하지만 아직 전송되지 않았기 때문에 게시해서는 안 됩니다. XLANG/s 하위 서비스는 메시지 에이전트 API를 호출하여 메시지를 직접 삽입합니다. 이를 통해 오케스트레이션 엔진은 메시지 본문을 MessageBox에 삽입하고 실행 중인 오케스트레이션 인스턴스와 직접 연결할 수 있습니다. MessageBox 데이터베이스에서 생성된 메시지의 지속성은 데이터베이스 작업의 추가 최적화로 오케스트레이션의 지속성 지점과 조정됩니다.
게시 및 구독이 서로 다르게 동작하는 것처럼 보이게 하는 오케스트레이션의 개념은 바인딩입니다. 오케스트레이션 포트는 상호 작용을 설명하는 논리 포트입니다. 메시지가 배달되도록 이러한 논리 포트를 실제 포트에 바인딩해야 하지만 이 바인딩 프로세스는 메시지 라우팅에 대한 구독을 구성하는 것 이상입니다.
이러한 포트를 바인딩하는 네 가지 기본 옵션이 있습니다.
지금 지정(오케스트레이션에서 직접 포트 지정)
나중에 지정(배포 시 포트 지정)
오케스트레이션 코드에서 주소가 설정된 동적 송신 포트 사용
오케스트레이션에서 MessageBox 데이터베이스 또는 다른 오케스트레이션으로 직접 바인딩 만들기
오케스트레이션 배포
디자인 타임에 바인딩을 지정하면 오케스트레이션이 배포될 때 오케스트레이션에 구성된 매개 변수와 일치하는 실제 포트가 만들어집니다. 배포 시 바인딩이 구성된 경우 논리 포트의 요구 사항과 일치하는 모든 포트를 오케스트레이션 포트에 바인딩할 수 있습니다. 동적 바인딩의 경우 실제 포트는 지금 지정 옵션과 마찬가지로 만들어지지만 포트는 주소 정보가 구성되지 않은 동적 송신 포트입니다.
혼동되는 개념은 오케스트레이션의 송신 포트가 실제 송신 포트에 바인딩되어 있지만 해당 메시지가 다른 구독자에게 전달되는 것을 배제하지 않는다는 것입니다. 즉, 다른 송신 포트가 해당 필터를 통해 바인딩된 포트로 전송되는 메시지에 대해 구독이 있는 경우 두 송신 포트 모두 메시지를 받습니다. 바인딩은 오케스트레이션에서 보낸 메시지가 항상 바인딩된 송신 포트에 대한 조건과 일치하게 구독을 만듭니다. 마찬가지로 수신 포트에 바인딩된 오케스트레이션 포트는 메시지 유형 및 수신 포트 ID에 따라 적절한 구독을 만듭니다. 구독은 오케스트레이션을 수신하고 나가는 메시지가 바인딩된 포트로 전달되도록 보장하지만 메시지는 여전히 앞에서 설명한 것과 동일한 게시 및 구독 메커니즘을 통과합니다.
아마도 가장 오해되고 잘못 사용되거나 사용되지 않는 바인딩 옵션은 직접 바인딩 옵션일 것입니다. 직접 바인딩을 사용하면 오케스트레이션에서 메시지가 수신 위치에서 게시되는 것과 매우 유사한 다양한 라우팅 속성을 사용하여 MessageBox 데이터베이스에 메시지를 게시할 수 있습니다. 간단한 직접 메시징의 경우, 메시지는 BizTalk Server에 수신된 다른 게시된 메시지처럼 라우팅될 수 있도록 승격된 속성을 사용하여 MessageBox에 게시됩니다. 적어도 하나의 구독자가 존재해야 모든 구독자가 이 메시지를 받을 수 있으며, 그렇지 않으면 오케스트레이션에서 라우팅 실패 오류를 받게 됩니다.
직접 바인딩에 대한 또 다른 옵션은 자체 상관 관계 포트를 사용하는 것입니다. 자체 상관 관계 포트는 고유한 상관 관계 토큰을 만들고 인스턴스 간의 메시지 상관 관계에만 해당 토큰을 사용하는 포트입니다. 자체 상관 관계 포트의 가장 일반적인 용도는 포트 매개 변수를 전달하는 오케스트레이션을 호출하거나 시작하는 것입니다. 호출된 오케스트레이션에서 포트를 사용하여 메시지를 보낼 수 있지만 호출 오케스트레이션에서 동일한 포트를 사용하여 메시지를 받을 수 있습니다. 포트에 고유한 상관 관계 토큰이 있으므로 메시지는 호출 오케스트레이션으로 다시 라우팅됩니다. 자체 상관 관계 포트는 오케스트레이션 인스턴스 간의 프라이빗 통신 채널 역할을 합니다.
마지막 옵션은 호출 오케스트레이션과 호출된 오케스트레이션 모두에서 포트가 동일한 공유 포트 유형을 사용하여 구성되고 포트 구성에서 동일한 포트가 선택된 파트너 오케스트레이션을 사용하는 것입니다. 예를 들어 Orch1과 Orch2 모두에서 Orch2.MyDirectPort가 선택됩니다. 이 유형의 바인딩은 보내는 오케스트레이션 유형, 포트 이름 및 작업 이름을 기반으로 수신 오케스트레이션에 대한 구독을 설정합니다. 이렇게 하면 메시지가 올바른 인스턴스로 라우팅됩니다.
모든 직접 메시징 옵션은 기본 게시 및 구독 모델을 사용합니다. 이러한 옵션의 차이점은 구독 및 라우팅을 만드는 데 사용되는 속성과 해결에 도움이 되는 사용 사례에 있습니다.
오케스트레이션에서 직접 바인딩된 포트를 사용할 때 발생하는 일반적인 문제 중 하나는 오케스트레이션이 구독하는 메시지도 게시할 수 있다는 것입니다. 예를 들어 오케스트레이션은 PurchaseOrder 메시지에 의해 활성화되도록 구성됩니다. 이 오케스트레이션은 직접 포트를 사용하여 PurchaseOrder 메시지를 MessageBox에 게시합니다. 그러나 예상대로 메시지를 수신하는 것 외에도 PurchaseOrder 메시지에 대한 구독이 있었기 때문에 오케스트레이션의 또 다른 인스턴스가 시작됩니다. 처리는 무한 루프에 들어가고 개발자가 무슨 일이 일어났는지 파악하는 데 다소 시간이 걸릴 수 있습니다.
상관 관계
오케스트레이션의 상관 관계는 동일한 실행 중인 오케스트레이션 인스턴스로 관련 메시지를 수신하는 메커니즘입니다. 오케스트레이션 디자이너에서 개발자는 다음 일반적인 단계에 따라 상관 관계를 사용합니다.
메시지를 연결하는 데 사용되는 승격된 속성을 포함하는 상관 관계 유형을 정의합니다.
방금 정의된 상관 관계 유형의 인스턴스인 상관 관계 집합을 정의합니다.
송신 및 수신 포트의 경우 지정된 상관 관계 집합을 시작하거나 따르는지 여부를 지정합니다.
인스턴스 구독은 상관 관계 집합이 시작될 때 활성화되며, 이때 이 집합을 따르는 모든 포트에 대한 구독이 생성되어 메시지를 수신하게 됩니다. 상관 관계 유형은 상관 관계에 사용할 속성을 정의하므로 오케스트레이션 엔진은 시작 작업에서 보내거나 받는 메시지에서 이러한 속성을 추출할 수 있습니다. 그런 다음 이러한 값을 사용하여 이 상관 관계 집합을 따르는 나머지 모든 작업에 대한 구독을 정의합니다.
BizTalk Server로 수신되어 상관 관계에 사용되는 메시지의 경우, 속성이 올바르게 정의되어 메시지 컨텍스트로 승격되어야 합니다. 파이프라인의 디스어셈블러 구성 요소가 메시지를 처음 받을 때 값을 추출하면 대부분의 속성이 승격됩니다. 따라서 PassThrough 수신 파이프라인을 사용하여 오케스트레이션의 실행 중인 인스턴스와 상관 관계가 있어야 하는 메시지를 받을 수 없습니다. 이 문제는 웹 서비스 게시 마법사를 사용할 때 PassThrough 파이프라인이 수신 파이프라인의 기본값이므로 SOAP 수신 어댑터를 사용하여 상관 관계가 있는 메시지를 받을 때 발생합니다.