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