어댑터 오류를 처리하는 방법

아티클
05/04/2023

일반적으로 어댑터는 처리할 수 없는 메시지를 일시 중단해야 합니다. 이 같은 사항은 어댑터의 목적에 따라 다르지만 일반적으로 전송 오류가 발생하는 수신 어댑터 등의 경우에는 메시지를 일시 중단해야 합니다. 오류 처리와 관련한 보안 고려 사항도 있습니다. 예를 들어 어댑터가 실패한 모든 메시지를 자동으로 일시 중단하면 어댑터가 서비스 거부 공격에 노출되어 BizTalk Server의 일시 중단된 큐가 가득 차게 될 수 있습니다. HTTP와 같은 일부 어댑터는 요청이 거부되었음을 나타내는 오류 코드를 클라이언트에 반환할 수 있습니다. 이러한 어댑터 유형의 경우 메시지를 일시 중단하는 것보다 오류 코드를 반환하는 것이 더 적합합니다. 일반적으로 송신 어댑터는 기본 전송 및 보조 전송 모두에 대한 재시도 횟수를 모두 사용한 후에만 메시지를 일시 중단합니다.

작업을 포함하는 일괄 처리 대신 개별 작업에 오류 처리 연결

어댑터 내 메시지의 일괄 처리는 어댑터 사용자에게 표시되지 않습니다. 즉, 일괄 처리에 포함된 작업 중 하나가 실패해도 다른 작업에는 아무런 영향을 주지 않습니다. 그러나 일괄 처리는 원자성이므로 한 메시지에 오류가 발생하면 일괄 처리에도 오류가 발생하여 아무런 작업도 처리되지 않습니다.

사용자는 오류 처리, 성공한 메시지 재전송 및 실패한 메시지의 일시 중단을 담당하는 코드를 작성해야 합니다. BizTalk Server는 어댑터가 실패한 특정 작업을 확인할 수 있도록 하는 세부 오류 구조를 제공하며 이를 통해 성공한 작업을 다시 전송하고 실패한 작업은 일시 중단하는 추가 일괄 처리를 생성할 수 있습니다.

작업의 최종 상태는 어댑터 내 일괄 처리의 영향을 받지 않습니다.

SetErrorInfo를 사용하여 BizTalk Server에 오류 보고

메시지를 일시 중단할 경우 이전 메시지 컨텍스트에서 BizTalk Server로 오류 정보를 제공해야 합니다. BizTalk Server IBaseMessage 및 ITransportProxy 인터페이스 모두에서 SetErrorInfo 메서드를 사용하여 오류 보고 기능을 제공합니다. 오류 보고는 다음과 같이 수행할 수 있습니다.

메시지를 처리하는 동안 오류가 발생하면 메시지(IBaseMessage)에서 SetErrorInfo(Exception e)를 사용하여 예외를 일시 중단되도록 설정합니다. 이렇게 하면 엔진이 이후 진단을 위해 메시지와 함께 오류를 보존하고 관리자에게 알리기 위해 이를 이벤트 로그에 기록합니다.
초기화 또는 내부 부기 중 오류가 발생하는 경우(메시지 처리 중이 아님) 초기화 중에 전달된 ITransportProxy 포인터에서 SetErrorInfo(Exception e)를 호출해야 합니다. 어댑터가 BaseAdapter 구현을 기반으로 할 경우 항상 이 포인터에 액세스할 수 있어야 합니다. 그렇지 않으면 이 포인터를 캐시해야 합니다.

이러한 방법 중 하나로 오류를 보고하면 오류 메시지가 이벤트 로그에 기록됩니다. 가능한 경우 오류를 관련 메시지와 연결하는 것이 좋습니다.

데이터베이스 오프라인 상태 처리

BizTalk Server 데이터베이스 중 하나가 오프라인 상태가 되면 BizTalk 서비스는 자체적으로 재생됩니다. 서비스를 재생하기에 앞서 메시징 엔진은 가능한 모든 방법을 동원하여 모든 수신 위치를 종료합니다. 이 작업이 60초 이상 소요될 경우 서비스는 종료됩니다. 엔진은 트랜잭션을 수행하므로 데이터가 손실되지는 않습니다.

다음 키를 사용하여 레지스트리에서 시간 제한을 조정할 수 있습니다.

DWORD   
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingDBFailoverShutdownTimeLimit

Isolated 어댑터의 경우 BizTalk Server에 자체 프로세스가 없으므로 BizTalk Server 데이터베이스 중 하나가 오프라인 상태가 되면 수신 위치가 비활성화됩니다. 데이터베이스가 다시 온라인 상태가 되면 해당 수신 위치는 다시 활성화됩니다.

이벤트 로그에 기록

어댑터는 예외를 전달하는 IBTTransportProxy 인터페이스를 사용하여 이벤트 로그 항목을 작성할 수 있습니다. 네이티브 코드로 개발된 어댑터는 IErrorInfo 인터페이스 인 IBTTransportProxy.SetErrorInfo(Exceptione)를 전달해야 합니다.

메시징 엔진은 전송 실패 후 어댑터가 메시지를 재시도하거나, 백업 전송으로 메시지를 이동하거나, 메시지를 일시 중단하는 것과 같은 이벤트를 어댑터 대신 이벤트 로그에 기록합니다. 이러한 작업을 위해 어댑터는 API를 호출하기 전에 메시지에 대한 예외를 설정하기만 하면 됩니다. 다음 코드 조각에서 이를 보여 줍니다.

IBaseMessage msg;  
...  
// Set exception on msg to indicate why transmission failed...  
msg.SetErrorInfo(  
 new ApplicationException(  
 "The TCP connection was closed by the destination"));

수신별 일괄 처리 오류 처리

수신 오류 처리

어댑터가 작업 또는 작업의 일괄 처리를 BizTalk Server로 전송할 때 발생하는 오류에는 다양한 이유가 있습니다. 가장 중요한 두 가지 이유는 다음과 같습니다.

수신 파이프라인에 오류가 발생했습니다.
메시지를 게시하는 동안 라우팅 오류가 발생했습니다.

메시징 엔진은 수신 파이프라인 오류 발생 시 자동으로 메시지를 일시 중단합니다. 이때 일시 중단 작업이 수행되지 않는 경우도 있습니다. 예를 들어 메시지를 게시하는 동안 메시징 엔진에 라우팅 오류가 발생하면 엔진은 메시지를 일시 중단하지 않습니다.

메시지는 언제든지 실패할 수 있습니다. 이러한 상황에서 어댑터는 MoveToSuspendQ API를 명시적으로 호출해야 하며 메시지를 일시 중단해야 합니다. 어댑터가 메시지를 일시 중단할 때는 다음 조건 중 하나를 갖추어야 합니다.
어댑터가 전송(권장)한 것과 동일한 메시지 개체를 일시 중단해야 합니다.
어댑터가 새 메시지를 만들어야 할 경우 원래 전송된 메시지의 메시지 컨텍스트에 대한 포인터로 새 메시지의 메시지 컨텍스트를 설정해야 합니다. 이는 메시지의 메시지 컨텍스트에 메시지 및 오류에 대한 중요한 정보가 다량 포함되어 있기 때문입니다. 실패한 메시지를 디버깅하려면 이 정보가 필요합니다.

참고

어댑터가 새 메시지 개체를 만들고 이를 일시 중단할 경우 어댑터가 이전 메시지 개체의 오류 정보를 새 메시지 개체로 복사해야 합니다.

BizTalk Server와 함께 제공된 HTTP 어댑터 등의 일부 어댑터에서는 메시지를 일시 중단할 필요가 없으며 이러한 어댑터는 오류를 클라이언트로 반환할 수 있습니다.

오류의 원인

오류의 간단한 원인은 일괄 처리가 생성되거나 IBTTTransportBatch::D one 이 호출될 때 발생할 수 있는 오류입니다.

전송 실패 제한된 수의 이유로 제출 호출이 실패할 수 있으며 모두 치명적입니다. 그 이유는 다음과 같습니다.
BizTalk Server 처리 공간에 메모리 부족 오류가 발생할 경우
스키마 어셈블리가 배포에서 삭제된 경우. 이 경우 비밀 오류와 함께 제출 이 실패합니다. MQSeries 어댑터에서 BizTalk Server의 일반 오류 예외가 catch되면 시스템 이벤트 로그에 확장된 오류 메시지가 기록됩니다. 이 메시지는 배포에서 스키마 어셈블리가 삭제되어 오류가 발생했을 수 있다고 제시합니다.

일반적으로 제출 이 실패하면 동일한 트랜잭션을 사용하여 메시지를 일시 중단해야 합니다.
IBTTransportBatch::Done 오류 IBTTransportBatch::D one 호출은 여러 가지 이유 중 하나로 인해 실패할 수 있습니다. 일반적으로 항상 일시 중단 작업을 시도한 후 이 작업이 실패할 경우에만 트랜잭션을 종료해야 합니다. IBTTransportBatch::D one의 오류로 인한 오류 코드 중 하나는 BizTalk Server 종료하려고 한다는 것입니다. 이 경우 Terminate 호출이 동시에 발생할 수 있으므로 트랜잭션을 종료하고 그대로 두어야 합니다. 다른 시나리오는 일괄 처리를 성공적으로 생성하고 IBTTransportBatch::D one을 성공적으로 실행한 경우에 발생합니다. 이러한 경우 오류는 BatchComplete 에서 반환되며 어댑터는 이를 사용하여 수행할 작업을 결정해야 합니다. 이 섹션의 나머지 부분에서 이러한 경우에 대해 설명합니다.

BatchComplete 오류 처리

BatchComplete는 일괄 처리 작업의 완료 상태 나타내기 위해 BizTalk Server 호출되는 어댑터에서 제공하는 콜백입니다.

BatchComplete에 전달되는 가장 중요한 매개 변수는 일괄 처리 상태 hResult입니다. 이것은 일괄 처리의 성공 또는 실패를 나타냅니다. 일괄 처리가 실패하면 일괄 처리의 모든 작업이 실패합니다. 어댑터는 일괄 처리 상태 구조를 거치며 실패한 메시지를 확인합니다(일괄 처리 필터링이라고 함).

비트랜잭션 BatchComplete 오류

비전송 어댑터의 경우 SubmitMessage SubmitRequestMessage/ 또는 SubmitResponseMessage 작업에 오류가 발생하는 경우 응답을 선택해야 합니다. 일반적으로 어댑터는 MoveToSuspendQ를 호출하여 메시지를 일시 중단합니다.

DeleteMessage, MoveToSuspendQ, ResubmitMessage 작업은 항상 통과해야 합니다. 이러한 작업이 실패하면 일반적으로 어댑터에 버그가 있는 것입니다. 이 경우 오류를 처리하는 코드를 작성할 필요가 없습니다. 그러나 다른 작업이 실패하여 일괄 처리가 실패하면 이러한 작업을 새로운 일괄 처리로 다시 실행해야 합니다.

어댑터가 MovetoBackupTransport 를 호출하고 백업 전송이 없어 실패하는 경우 어댑터는 MoveToSuspendQ 를 호출하여 메시지를 일시 중단해야 합니다.

트랜잭션 BatchComplete 오류

어댑터에서 만든 트랜잭션을 사용하여 BizTalk Server로 일괄 처리를 전송할 때는 다음 두 시나리오 중 하나를 따라야 합니다.

단일 메시지 일괄 처리 사용 BizTalk Server에 단일 메시지 일괄 처리를 보냅니다. 이때 단일 메시지가 실패할 경우 동일한 트랜잭션으로 BizTalk Server에 두 번째 일괄 처리를 보낼 수 있지만 실패한 메시지는 다시 전송하는 대신 일시 중단된 큐로 이동해야 합니다. 실패한 메시지를 제거하면 두 번째 일괄 처리 전송이 성공합니다. 그 다음에는 BizTalk Server에서 두 번째 일괄 처리의 성공을 확인한 후 트랜잭션을 커밋할 수 있습니다. 두 번째 일괄 처리가 실패하면 어댑터에서 트랜잭션을 중단하거나 해당 메시지를 보관할 다른 곳을 찾아야 합니다. 이 시나리오에서는 트랜잭션 롤백 처리로 인해 성능이 현저히 저하됩니다.

어댑터의 성능 향상을 위해 사용할 수 있는 몇 가지 방법이 있습니다. 예를 들어 MQSeries 어댑터는 런타임에 접근 방법을 동적으로 조정하며 100개의 메시지 일괄 처리로 실행됩니다. MQSeries 어댑터는 오류가 발생할 경우 일괄 처리를 종료해야 하지만 잘못된 메시지 통과 시 단일 메시지 일괄 처리로 잠시 전환됩니다. 그런 다음 100개의 메시지 일괄 처리로 다시 전환됩니다. 이때 오류가 발생하면 다시 느려집니다.
선점형 일시 중단 사용 오류가 있는 메시지가 미리 일시 중단되는 다중 메시지 일괄 처리를 생성합니다. 일괄 처리에는 Submit 및 MoveToSuspendQ 작업이 혼합되어 있으며 트랜잭션에서 첫 번째이자 유일한 일괄 처리입니다. 이 일괄 처리는 잘못된 데이터가 미리 일시 중단되므로 성공하며 BizTalk Server의 확인을 수신한 후 트랜잭션을 커밋할 수 있습니다.

이 기술은 나중에 검토가 필요한 것처럼 보일 수 있지만 MSMQ 어댑터에도 사용되며 안정적인 고유 메시지 ID를 기반으로 합니다. 이 어댑터는 메시지 일괄 처리를 생성합니다. 오류가 발생하면 트랜잭션 및 일괄 처리를 롤백하지만 임시 데이터 구조에 메시지 ID를 저장합니다. 이때 이 구조가 무한정 커지지 않도록 하기 위해 구조의 항목은 일정 시간이 지난 후 제거됩니다. 각 일괄 처리가 전송되기 전에 어댑터는 잘못된 메시지 ID 목록을 확인합니다. 여기서 어댑터가 잘못된 메시지를 발견하면 이전에 한 번 실패했으므로 이번에도 메시지가 실패할 것이라는 사실을 인식하여 해당 메시지를 전송하는 대신 미리 일시 중단합니다.

모든 어댑터가 안정적인 고유 메시지 ID를 갖는 것은 아니며 트랜잭션 저장소는 이를 갖지 않을 가능성이 높습니다. 이로 인해 많은 트랜잭션 어댑터가 단일 메시지 일괄 처리 보내기로 제한됩니다.

기타 오류 처리

메시지 일시 중단 오류와 같은 다른 모든 경우에서 어댑터는 트랜잭션을 종료해야 합니다. 그렇지 않으면 메시지가 중복되거나 삭제됩니다.

가능한 경우 어댑터는 일괄 처리가 실패할 때마다 트랜잭션을 중단해야 합니다. 그러나 어댑터가 트랜잭션을 중단할 수 없는 시나리오가 있습니다. 이러한 시나리오에서 어댑터는 동일한 트랜잭션을 사용하여 메시지를 일시 중단해야 합니다.

트랜잭션 수신 오류 처리

오류가 발생하면 트랜잭션을 종료하는 것이 일반적인 트랜잭션 처리 패턴입니다. 이 경우 모든 것이 이전 상태로 돌아가고 데이터가 손실되지 않습니다. 그러나 데이터베이스의 스테이징 테이블에서 한 번에 하나의 행을 끌어오거나 MQSeries 또는 MSMQ와 같은 큐 제품에서 한 번에 하나의 메시지를 끌어오는 것과 같이 트랜잭션 공급 데이터를 사용할 경우 이것만으로는 충분한 결과를 얻지 못할 수 있습니다. 단순히 트랜잭션을 종료하고 되돌아가서 동일한 데이터를 다시 선택하면 같은 오류가 발생하여 시스템이 반복 루프 상태에 빠질 가능성이 높습니다.

이전 버전의 BizTalk Server에서 SQL 어댑터는 이러한 오류에 취약했으나 릴리스 이후 실패한 메시지를 일시 중단하고 트랜잭션을 커밋하도록 어댑터 동작이 변경되었습니다. 동일한 트랜잭션의 일시 중단된 큐로 메시지를 이동한 후 트랜잭션을 커밋하면 데이터 손실을 방지할 수 있고 어댑터가 잘못된 데이터를 통과하도록 할 수 있습니다.

어댑터의 수신 부분에 메시지 제출 작업에 대한 응답으로 오류 메시지가 전달되면 어댑터는 해당 오류를 처리하고 메시지를 일시 중단된 큐로 이동해야 합니다.

어댑터가 트랜잭션 개체를 만들고 트랜잭션으로 메시지를 전송하는 트랜잭션 일괄 처리의 경우 오류가 발생하면 어댑터는 동일한 트랜잭션에서 메시지를 일시 중단된 큐로 이동해야 합니다. 트랜잭션은 데이터가 삭제되지 않도록 합니다. 이때 오류를 발생시키는 데이터도 삭제하지 말아야 합니다.

등록 없이 메시지 처리

메시지를 수락하도록 정의된 등록이 없으면 BizTalk Server는 해당 MessageBox 데이터베이스에 대한 메시지 게시를 수락하지 않습니다. 등록은 오케스트레이션 또는 송신 포트에 의해 이루어집니다. 다중 등록을 정의할 수 있으며 이 경우 메시지는 여러 대상으로 전송됩니다. 등록이 없으면 BizTalk Server는 메시지를 거부하고 메시지를 일시 중단하지도 않습니다. 어댑터가 이 오류를 처리하지 않고 명시적으로 메시지를 일시 중단하면 해당 메시지가 삭제되며 데이터가 손실될 수 있습니다. 물론 트랜잭션 어댑터에서 트랜잭션을 종료하고 메시지를 대상으로 되돌릴 수 있습니다.

수신 스트림을 사용한 검색 지원

수신 쪽 스트림은 BizTalk Server 파이프라인 오류 시 메시지를 일시 중단할 수 있도록 Seek 메서드를 지원해야 합니다. 메시지 스트림을 검색할 수 없는 경우 BizTalk Server 검색을 실행하려고 할 때 오류가 발생합니다.

대부분의 경우 Seek를 지원하는 것은 쉽지 않습니다. 예를 들어 네트워크에서 데이터를 스트리밍할 때 네트워크 리소스로 돌아가서 다시 데이터를 요청하는 것이 어려울 수 있습니다.

BizTalk Server와 함께 제공되는 많은 어댑터는 BizTalk Server가 데이터를 읽음과 동시에 디스크의 파일로 메시지 데이터를 스풀링합니다. 이렇게 하면 어댑터가 오류(예: 메시지 데이터의 파이프라인 처리 중)가 발생하는 경우 해당 파일에서 Seek 를 사용할 수 있습니다. 내부적으로 어댑터는 검색할 수 없는 들어오는 스트림을 래핑하고 구성 가능한 크기 임계값에 도달하면 디스크로 오버플로하는 ReadOnlySeekableStream 클래스를 사용합니다. 임계값 크기보다 작은 메시지의 경우 디스크에 오버플로되지 않습니다.

사용자가 구성할 수 있는 오류 처리 옵션 구성

오류에 대한 올바른 단일 해결책이 없는 경우도 있습니다. 이 경우 사용자가 구성할 수 있는 옵션을 통해 동작을 선택할 수 있으며 MQSeries 어댑터를 사용하여 이를 수행할 수 있습니다.

오류 발견 시 어댑터가 메시지를 일시 중단할 경우 문제는 BizTalk Server의 일시 중단된 큐가 "블랙홀"과 같아 큐에 메시지를 넣는 것은 상대적으로 쉽지만 큐에서 다시 꺼내는 것은 어렵다는 것입니다.

일부 어댑터 사용자는 일시 중단된 큐를 빈 상태로 유지하고 싶어할 수 있습니다. 예를 들어 MQSeries 어댑터의 경우 사용자에게 다음 작업 중 하나를 수행할 수 있는 구성 옵션이 제공됩니다.

오류 발견 시 어댑터가 현재 트랜잭션을 종료하고 자체적으로 비활성화되도록 설정합니다.
실패한 메시지를 일시 중단하고 트랜잭션을 커밋합니다. BizTalk Server가 성공적으로 메시지를 일시 중단했을 때도 어댑터는 이를 수행합니다. 이 작업은 이벤트 로그가 완전히 정확하지 않게 되더라도 고객의 요구 사항을 만족합니다.

단일 스레드 사용 및 BatchComplete 대기를 통해 수신 순서 지정

BizTalk Server의 인터페이스는 동시성을 지원하여 성능과 기능을 확장하도록 설계되었습니다. 그러나 MQSeries 또는 MSMQ와 같은 메시지 큐 제품에서 메시지를 수신할 때와 같이 수신되는 메시지의 순서가 정확히 지정되도록 해야 하는 경우 어댑터에서 몇 가지 추가 작업을 수행하여 일부 경우에서는 동시성이 비활성화되도록 해야 합니다. 이 작업은 다음 두 단계로 수행할 수 있습니다.

어댑터에서 처리되는 모든 데이터에 대해 단일 스레드를 사용해야 합니다.
BizTalk Server가 각 일괄 처리를 완전히 처리할 때까지 기다려야 합니다. 이는 중요한 요구 사항이며 .NET 스레드 동기화 기본 형식을 사용하여 지킬 수 있습니다. 예를 들어 AutoResetEvent를 사용하면 다음을 수행할 수 있습니다.
- 기본 작업자 스레드와 BatchComplete 콜백 개체 모두에서 액세스할 수 있는 이벤트 개체를 선언합니다.
- 기본 작업자 스레드에서 평소와 같이 일괄 처리에 메시지를 제출한 다음, 일괄 처리 IBTTransportBatch::D one 호출 직전에 이벤트 개체에서 AutoResetEvent.Reset을 호출합니다.
- 이 동일한 스레드의 이벤트 개체에서 AutoResetEvent.WaitOne 을 호출합니다. 이렇게 하면 주 작업자 스레드가 차단됩니다. BizTalk Server BatchComplete 콜백에서 동일한 이벤트 개체에서 AutoResetEvent.Set를 호출하여 작업자 스레드의 차단을 해제하여 다른 메시지를 처리할 준비가 되도록 합니다.
이와 같은 수신 순서는 상당한 성능 저하를 유발하기 때문에 구성할 수 있도록 하는 것이 좋습니다. 대부분의 사용자 시나리오에서는 메시지 정렬이 필요 없습니다. 또한 메시지 일시 중단으로 인해 정렬이 손상될 수 있습니다. 이 경우 수행해야 하는 작업은 응용 프로그램에 따라 다르므로 어댑터를 통해 사용자에게 구성 지점을 제공하는 것이 가장 좋습니다.

정렬 시나리오에서 일부 고객은 정렬을 손상시키는 것보다 처리 중지(어댑터 비활성화)를 선호했으며 정렬된 수신을 지원하는 MQSeries 어댑터를 통해 이 옵션을 사용할 수 있습니다.

송신별 일괄 처리 오류 처리

일괄 처리 및 송신 재시도 처리

다음은 송신측 일괄 처리의 일반적인 예입니다.

BizTalk Server가 어댑터에 메시지 일괄 처리를 제공합니다.
어댑터가 메시지를 대상에 올바르게 제공했음을 확인하면 어댑터는 BizTalk Server에서 삭제 작업을 실행하여 작업 완료 상태를 나타냅니다. 일반적으로 여러 메시지 삭제 작업을 임의로 일괄 처리하여 성능을 향상시킬 수 있습니다.

송신측 어댑터가 메시지를 처리하지 못하면 해당 메시지에 대해 다음 동작 중 하나를 수행합니다.
어댑터에서 BizTalk Server에 메시지 재시도를 요청합니다. BizTalk Server는 메시지를 자동으로 재시도하지 않습니다. BizTalk Server는 재시도 횟수를 유지하며 이 정보는 메시지 컨텍스트에서 확인할 수 있습니다.
어댑터가 메시지를 처리할 수 없다고 판단할 수 있습니다. 이 경우 메시지를 다음 전송으로 이동할 수 있습니다. 어댑터는 Batch 개체의 MoveToNextTransport 호출을 사용하여 이 작업을 수행합니다.
어댑터가 메시지를 일시 중단된 큐로 이동할 수 있습니다.

어댑터가 메시지에 수행할 작업을 결정합니다. 이때 BizTalk Server 지원이 쉬워지도록 어댑터의 동작을 일관되게 만드는 것이 좋습니다.

어댑터의 동작을 아래와 같이 만드는 것이 가장 좋습니다. BizTalk Server와 함께 제공되는 어댑터의 동작은 다음과 같습니다.

일괄 처리에서 송신 오류 처리 시 권장되는 동작

송신 어댑터가 일부 메시지를 수신하고 이를 BizTalk Server로 전송합니다.

성공한 각 메시지에 대해 어댑터는 BizTalk Server에서 해당 메시지를 삭제해야 합니다. BizTalk Server와의 모든 통신은 일괄 처리를 통해 수행되며 삭제 작업은 일괄 처리될 수 있습니다. 이때 해당 일괄 처리가 BizTalk Server가 어댑터에 만든 일괄 처리와 동일할 필요는 없습니다. SolicitResponse 시나리오에서와 같이 응답 메시지가 있으면 해당 메시지를 SubmitResponse를 사용하여 연결된 삭제 작업과 함께 BizTalk Server로 전송해야 합니다.

어댑터에서 메시지 처리에 실패하면 재시도 횟수를 확인합니다.
- 재시도 횟수가 초과되지 않았으면 메시지를 BizTalk Server로 다시 전송하고 메시지에 대한 재시도 횟수를 설정합니다. 메시지 컨텍스트는 어댑터가 사용해야 하는 재시도 횟수 및 재시도 간격을 제공합니다.
- 재시도 횟수를 초과한 경우 어댑터는 MoveToNextTransport를 사용하여 메시지를 이동하려고 시도해야 합니다. 다시 제출 및 MoveToNextTransport 메시지는 BizTalk Server 동일한 일괄 처리의 삭제와 혼합할 수 있습니다. 이는 필수 단계는 아니지만 수행할 경우 유용할 수 있습니다.
다시 제출 및 MoveToNextTransport 는 어댑터가 오류를 처리하는 방법입니다. 그러나 오류 처리 과정에서 오류가 발생할 수 있습니다. 이 경우 BizTalk Server 응답을 처리할 때(BatchComplete 메서드에서) 어댑터는 BizTalk Server 대해 다른 일괄 처리를 만들어 해당 실패로 수행할 작업을 나타내야 합니다.

다른 오류 처리 과정에서 발생하는 오류를 처리할 경우 다음 단계를 따르십시오.
- 다시 제출이 실패하면 MoveToNextTransport를 사용합니다.
- MoveToNextTransport가 실패하면 MoveToSuspendQ를 사용합니다.
성공한 작업을 수신할 때까지 BizTalk Server에서 일괄 처리를 계속 만들어야 합니다.

메시지 컨텍스트 속성 Serialization

메시지 컨텍스트 속성에 할당된 모든 개체는 serialize 가능해야 합니다. 그렇지 않으면 메시징 엔진이 E_NOINTERFACE 형식의 예외를 throw합니다. 이 반환 값은 메시지 컨텍스트를 할당 받으려는 serialize 불가능한 개체를 나타냅니다.

다음을 통해 공유