BizTalk Ack 전파

Question

BizTalk 인터페이스에 HL7 메시지를 받고 메시지를 클라이언트의 서버에 전달했습니다. 이 인터페이스에는 RP와 SP가 있습니다. 현재의 동작은 RP가 메시지를받는 순간 두 가지 방법으로 ACK를 생성한다는 것입니다. 그러면 SP는 클라이언트에 메시지를 보내고 클라이언트는 ACK로 응답합니다. SP는 ack를 수신하면 클라이언트 서버가 보낸 ACK를 사용합니다. 내 질문은 SP에서 ACK가 RP로 전달되고 동일한 RP 소켓의 소스로 돌아가도록 BizTalk을 구성하는 방법입니다. 나는 오케스트레이션을 피하려고 노력하고 있는데 이것이 사용자 정의 파이프 라인 구성 요소가되어야합니까?

감사합니다.

Answer 1

이렇게 많은 조사와 흔적과 오류가 있습니다. 이 기능은 BizTalk 2013 R2의 기본 기능입니다. 이전에 작동하지 않는 이유는 RP가 RP의 수신 파이프 라인에서 생성 된 ACK, 특히 디스어셈블러에 의해 생성 된 ACK를 수신했기 때문입니다. 따라서 클라이언트로부터의 ACK가 리턴 될 때, RP는 어디로 가야하고 RP에서 일시 중지됩니까. 파티를 만들고 Ack 라우팅을 선택하여 Ack Type을 None으로 설정하면이 문제를 해결할 수 있습니다.

구현 제한으로 인해 위의 방법을 사용할 수있는 당사자를 만들 수 없습니다. 대신 RP의 수신 파이프 라인에 대한 사용자 지정 파이프 라인 구성 요소를 코딩하여 역 어셈블러에서 ACK를 억제해야했습니다. 이것은 잘 작동했습니다.

Answer 2

HL7 Party를 사용하고 Acknowledgement Tab에서 Acknowledgement Type을 'None'으로 설정하여 접근 할 수 있습니다. 이렇게하면 HL7 디스어셈블러가 메시지 수신시 확인을 생성하지 않습니다. 수신 시스템에서 수신 확인을 받으면 송신 측에서 원래의 메시지 컨텍스트와 동일한 EpmRRCorrelationToken 컨텍스트 특성이 있는지 확인하십시오. ACK 메시지에이 컨텍스트 속성을 쓰려면 송신 포트 (수신 측)에서 사용자 지정 파이프 라인 구성 요소를 사용해야 할 수도 있습니다. 이렇게하면 ACK 메시지가 RCV 포트로 전송됩니다. 나는 전에 이것을 한 적이 없지만 효과가있다.

메시지 전송 시스템은 BizTalk가 메시지를 성공적으로 보내고 메시지 수신 시스템에서 수신 확인을받을 때까지 확인 응답을 기다릴 것이기 때문에 디자인 측면에서는 그리 좋은 생각이 아닙니다. 수신 시스템에 문제가 있고 메시지를 사용할 수 없거나 예정된 다운 시간이있는 경우를 고려해야합니다. 대부분의 시간 전송 시스템은 확인 응답에 대해 시간 초과가 설정되어 있고 해당 시간 프레임에서 확인을받지 못하면 다시 시도하므로 중복 된 메시지 문제가 발생합니다.

Answer 3

먼저 오케스트레이션 사용에는 아무런 문제가 없습니다. '성과'에 대해 걱정하지 마십시오.

올바른 BizTalk 방식은 오케스트레이션을 사용하여 다운 스트림 시스템과의 동기화를 관리하는 것입니다.