발신 처리를 위한 메시지 일괄 처리
송신 어댑터 일괄 처리 관리
송신 측에서 트랜잭션을 사용할 경우 BizTalk Server에서 만들고 대상 시스템으로 메시지를 보내는 데 사용한 트랜잭션을 해당 메시지를 삭제하는 데도 사용합니다(메시지가 제대로 보내진 경우). 이 과정에서 오류가 발생하면 트랜잭션이 종료될 수 있습니다. 이 경우 삭제가 중단되고 데이터는 대상 시스템이 아니라 BizTalk Server에 남게 되므로 메시지가 중복되지 않습니다. 트랜잭션은 비동기 송신 어댑터에서만 지원됩니다. 동기 송신 어댑터에는 트랜잭션을 사용할 수 없습니다.
그러나 트랜잭션을 종료하는 것으로 어댑터의 역할이 끝나는 것은 아닙니다. 어댑터는 주어진 메시지의 상태를 올바르게 처리하는 작업도 수행해야 합니다. 특히 어댑터는 재시도 횟수 및 백업 전송을 사용할 수 있는지 여부에 따라 Resubmit, MoveToNextTransport 및 MoveToSuspendQ 메서드를 적절하게 호출해야 합니다.
삭제 및 SubmitResponse 작업을 동일한 트랜잭션을 사용하는 일괄 처리에 배치하는 것이 중요합니다. 오류가 발생할 경우에는 트랜잭션을 종료함으로써 외부 시스템에 데이터가 한 번만 전송되도록 보장합니다. 하지만 BizTalk Server 메시지를 다시 제출하거나 MoveToNextTransport를 호출하려고 합니다. 이 작업을 수행하려면 해당 작업에 대해 별도의 일반(비트랜잭션) 일괄 처리를 사용합니다.
다음 그림에서는 응답 메시지에 별도의 일괄 처리를 사용하는 과정을 보여 줍니다.
엔드포인트를 기준으로 송신 측 트랜잭션 일괄 처리 정렬
BizTalk Server에서 어댑터로 보낸 메시지 일괄 처리는 여러 송신 포트 또는 엔드포인트로 분산될 수 있습니다. 어댑터는 일반적으로 단일 엔드포인트에 대한 트랜잭션을 원하기 때문에 어댑터는 송신 포트(SPName 또는 OutboundTransportLocation)를 기준으로 메시지를 정렬해야 합니다. 이렇게 함으로써 어댑터는 특정 송신 포트로만 향하는 트랜잭션을 만들 수 있습니다.
예를 들어 FTP 송신 어댑터가 BizTalk Server로부터 메시지 일괄 처리를 수신하는 경우 현재 활성 상태인 모든 FTP 송신 포트에 대한 혼합된 메시지 일괄 처리를 수신합니다. 이러한 동작은 해당 API가 단일 처리를 기반으로 하기 때문입니다. 즉, 송신 포트당 FTP 어댑터가 하나씩 로드되는 것이 아니라 FTP 어댑터가 총 하나만 로드됩니다.
따라서 어댑터는 먼저 BizTalk Server로부터 받은 메시지 일괄 처리를 각 엔드포인트에 하나씩 개별 일괄 처리로 정렬해야 합니다. 그런 다음, 각 엔드포인트를 차례로 처리하고 각 엔드포인트에 대해 삭제 일괄 처리를 만듭니다. SDK 샘플 코드의 재사용 가능한 BaseAdapter 일반 클래스는 이와 동일한 방식으로 작동합니다.
동적 송신을 위한 정렬
포트에서 메시지 헤더와 URL 자체에 충분한 구성 정보만 제공한다면 BizTalk Server 오케스트레이션은 구성되지 않은 포트로 메시지를 보낼 수 있습니다. 단, BizTalk Server에서는 URL의 프로토콜을 인식해야 합니다.
메시지를 정렬할 때는 엔드포인트를 정의하는 항목을 주의 깊게 설정해야 합니다. 동적 송신의 경우 이 작업은 특히 중요합니다. URI로만 엔드포인트를 정의할 경우에는 작업이 훨씬 간단합니다. 하지만 FTP 세션에서는 실제 엔드포인트를 정의하기 위해 FTP 서버에서 사용자 이름 로그온 정보를 사용할 수도 있습니다. 이 경우 어댑터가 다른 계정으로 로그인하면 다른 디렉터리에 연결될 수도 있습니다.
경우에 따라 SSO(Enterprise Single Sign-On) 명령 ValidateAndRedeemTicket를 실행할 때까지 실제 엔드포인트를 알 수 없습니다.
MQSeries의 경우 트랜잭션 사용 여부를 구성할 수 있습니다. 원격 COM+ 개체의 용도와 아키텍처를 고려하면 트랜잭션 엔드포인트를 비트랜잭션 엔드포인트와는 별개의 것으로 취급하는 것이 가장 좋습니다.
다시 말해, 단일 엔드포인트 일괄 처리로 메시지를 정렬하는 것은 때로는 번거로운 작업이 될 수도 있고 컨텍스트 값과 SSO 호출에 대한 결과까지 고려해야 하는 추가적인 단계를 수행해야 할 수도 있습니다.
정적 송신을 위한 정렬
정적으로 구성된 엔드포인트의 경우 메시지 컨텍스트에 SPID(정적 포트 ID)라는 고유 GUID가 있습니다. 이 값을 사용하여 엔드포인트를 정렬할 수 있습니다. 다음 코드를 사용하면 이 값을 검색할 수 있습니다.
string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");
이 코드는 XSD(XML 스키마 정의) 기반 구성 프레임워크에 소개된 문제를 검토할 때 유용합니다. 이 프레임워크에서는 단일 컨텍스트 속성의 XML에 포함된 엔드포인트 키의 일부인 속성을 사용할 수 있습니다. 컨텍스트의 SPID를 알면 이를 통해 일괄 처리를 정렬할 수 있습니다. SPID를 알 수 없는 경우에는 동적 송신을 수행하게 되므로 일괄 처리를 정렬하는 데 사용할 대체 키를 만들어야 합니다.
다음 그림에서는 엔드포인트를 기준으로 한 메시지 정렬을 보여 줍니다.
메시지 재시도 횟수는 일괄 처리의 성공이나 실패와는 관계가 없습니다. 송신 측에서 일괄 처리 내의 메시지 몇 개가 실패하는 경우 메시지 일괄 처리 전체가 실패할 수도 있습니다. 따라서 어댑터는 수신하는 모든 메시지에 대해 성공 여부를 판단해야 합니다. 실패한 일괄 처리 시나리오에서는 모든 메시지를 다시 전송해야 할 수도 있습니다. 하지만 실패한 일괄 처리의 모든 메시지를 다시 전송할 경우 성공한 메시지에 대해서도 재시도 횟수(BizTalk Server 엔진에서 유지 관리함)가 잘못 증가하는 결과가 나타날 수 있는데, 이는 성공한 메시지도 실패한 메시지와 동일한 일괄 처리 내에 있을 수 있기 때문입니다. 이 경우 어댑터가 아웃바운드 일괄 처리를 다시 만들고 외부 시스템에 대해 성공 메시지를 다시 시도할 수 있습니다.