MessageBox 직접 연결 포트의 상관 관계

Question

응용 프로그램에서 호스팅되는 MyUsefulOrch이라는 오케스트레이션이 있습니다. MySharedApp.

MyUsefulOrch는 요청을 수신하는 인바운드 메시지 박스-직접 바운드 포트를 가지고 있으며, 몇 가지 유용한 작업을 수행 한 후, 아웃 바운드 메시지 박스-직접 바인딩 포트는 발신자에게 메시지를 보낼 수 있습니다.

지금, 나는 또 다른 오케스트레이션 MyUsefulOrch에서 제공하는 유용한 처리의 혜택을 원하는 MyCallerOrch라고합니다. 그러나 MyCallerOrch은 다른 응용 프로그램에서 호스팅됩니다 (MyCallingApp).

나는 MyCallerOrch에서 MyUsefulOrch 포함 된 어셈블리에 대한 참조를 갖고 싶어하지 않습니다.

내 문제는 지금은 MyCallerOrch에서 MyUsefulOrch에 메시지를 전송하고 그것에서 응답을받을 수 있는지 확인하고있다.

아하! 상관 관계가 트릭을해야합니다! 그러나이 시나리오에서 상관 관계가 작동하도록하려면 어떻게해야합니까? 예를 들어

는 :

• 나는 속성 스키마에 상관 ID를 둘 것하고는 메시지 박스로 전송하기 전에 MyCallerOrch에서이 속성 아래에있는 메시지 컨텍스트에 GUID를 물건?
• 어떻게 MyCallerOrch 그것이 MyUsefulOrch에서 수신해야에만 응답을받을 수 있도록합니까?
• 두 오케스트레이션 사이에서 보내지는 메시지의 메시지 본문에 상관 ID 값을 입력해야합니까?

나는 이것을 극복하는 방법에 대해 가능한 한 설명 적으로 이상적인 도움을 주시면 감사하겠습니다.

미리 감사드립니다.

Answer 1

나는 2 응용 프로그램을 사용하면 강력한 형식의 스키마를 사용하는 경우, 서로에게 메시지를 보낼려고하고 있기 때문에, 두 응용 프로그램은 스키마에 대해 알아야 할 것이다 당신이 바로 그 트랙

에 꽤 많이 생각합니다. 이 경우 공용 스키마를 별도의 어셈블리로 분리하고 두 오케스트레이션 응용 프로그램 모두에서이를 참조하는 것이 좋습니다. (서버에 등록 된 스키마는 여러 응용 프로그램에서도 고유 한 XMLNS # ROOT가 있어야 함)

그러나 실제로 공유 스키마 어셈블리 참조에도 견딜 수없는 경우 형식화되지 않은 메시지를 사용해야 할 수도 있습니다.

리처드 Seroter 그의 기사는 또한 컨텍스트 속성에 GUID의 상관 관계를 스탬핑 자동차에 대한 기술을 설명 here

예를 가지고있다.

편집 : 좋은 지적. 파이프 라인이없는 메시지에서 사용자 정의 컨텍스트 특성을 승격시킬 수 있습니다. here 및 here의 트릭을 참조하십시오. 이는 MyUsefulOrch에 컨텍스트 특성을 보내기에 충분하며 마찬가지로 MyUsefulOrch 내에서 리턴 메시지에서 사용자 정의 컨텍스트를 승격시킬 수 있습니다 (이후 MyUsefulOrch는 상관 관계가 필요하지 않습니다.) 그러나 반환 메시지에 새 상관 관계 속성을 추가하지 않는 한 MyCallingOrch를 반환하면 사용자 지정 컨텍스트 속성을 사용하여 "다음 상관 관계"를 계속 유지할 수 있다고 생각할 수 없습니다.

Answer 2

호출자 오케스트레이션의 양방향 요청/응답 보내기 포트를 사용하여 유용한 오케스트레이션에 메시지를 보내면 상관 관계를 사용하여 관련 메시지를 호출자의 사용자 지정 orch로 다시 라우팅 할 수 있습니다.

트릭은 유용한 orch를 수정해야한다는 것입니다 (물론 더 유용하게 사용하려면).

사용자 지정 오크 발신자가 응답을 기다리고 있는지 여부를 제어 할 수 없거나 제어 할 수없는 경우 인바운드 (요청) 포트를 단방향 포트로 만들어야합니다. 그런 다음 오케스트레이션은 단방향 아웃 바운드 (응답) 포트로 전송하여 완료됩니다.

양방향/요청 - 응답 호출자로부터 수신 한 메시지를 올바르게 라우팅하려면 유용한 orch 내에있는 아웃 바운드 메시지의 구성 형태가 메시지 할당 모양을 사용하여 다음 메시지 등록 정보를 true로 설정해야합니다.

• BTS.RouteDirectToTP
• BTS.IsRequestResponse

그 두 가지 속성을 설정하기 전에, 그러나, 또한 t에 msgOut(*) f= msgIn(*); 같은 것을 할 수 있는지 확인 다른 속성이 복사되도록 동일한 메시지 할당 모양. 인바운드 및 아웃 바운드 메시지가 같지 않은 경우 필요한 속성 각각을 수동으로 하나씩 설정해야합니다.

물론 위의 두 가지 외에 이러한 특성은 유용한 orch의 결과가 호출자에게 적절하게 전달되도록하는 데 도움이됩니다. 그러나,

• BTS.CorrelationToken
• BTS.EpmRRCorrelationToken
• BTS.IsRequestResponse
• BTS.ReqRespTransmitPipelineID
• BTS.RouteDirectToTP

내가 앞서 자신의 조금을 받고 있어요 : 그들은 당신의 상관 세트 안에하고있다한다 , 아웃 바운드 s에 상관 세트를 지정하면 경우에만 BTS.EpmRRCorrelationToken exists msgIn 끝 모양. 이것은 매우 중요합니다. 저는 정확한 구절을 바탕으로 결정을 내리면서 난형에서 결정 모양을 사용했습니다. 결과가 참이면 이전에 구성한 메시지를 으로 보내고 위의 상관 관계 세트를 초기화 상관 세트으로 지정하십시오.이로 인해 BizTalk는 예상 된 응답으로 호출자에게 메시지를 다시 라우팅합니다.

의사 결정의 결과가 잘못된 경우 유용한 조정자의 호출자는 단방향입니다. 당신은 여전히 ​​결과를 보내고 싶어합니다 (누군가 다른 사람에게 구독하게하십시오). 양방향 응답과 동일한 송신 포트를 사용할 수도 있습니다. 이 아닌 상관 집합을 지정하십시오.

물론 이것을 철저히 테스트하고 싶을 것입니다. 그것은 내가 그것을 사용한 한 가지 시나리오에서 저에게 효과적 일지 몰라도, 다른 사람들이 그들의 실사를하지 못하게하는 것은 아닙니다.