Error Handler 샘플 정보
Error Handler 샘플은 트랜잭션 처리에 관련된 비즈니스가 오류 핸들링에 필요한 루틴을 개발하고자 한다는 시나리오를 기본으로 합니다. 이 샘플은
WebSphere Message Broker에서
제공하는 일부 기능의 사용 방법을 보여줍니다.
은행과 같은 비즈니스에서는 트랜잭션이 한 번만 처리되고 모든 오류에 레코드가 남기를 원할 수 있습니다.
Error Handler 샘플에서, 메시지 플로우에 스탭 번호에 대한 메시지를 넣어 이 정보로 데이터베이스를 갱신합니다.
올바르지 않은 스탭 번호를 가진 메시지를 넣음으로써 오류 핸들링 루틴이 어떻게 작동하는지 알 수 있습니다.
Error Handler 샘플은 다음 작업에 대해 설명합니다.
- 오류에 대한 정보를 수집하고 데이터베이스에 정보를 저장하기 위해 오류 핸들링 루틴을 사용하는 방법. 샘플에 사용된 Error Handler 루틴은
모든 메시지 플로우에 추가될 수 있으며 변경되지 않는 서브플로우입니다.
- 트랜잭션 방식을 제어하도록 메시지 플로우를 구성하는 방법.
특히, 샘플에서는 데이터 전체의 무결성을 보장하기 위해 전역적으로 통합된 트랜잭션의 사용 방법을 보여줍니다.
z/OS에서는 이것이 디폴트 조작 모드입니다. 분산 플랫폼에서
전역 통합을 위해서는 특정 구성이 필요하며 XA 프로토콜을 사용하여 구현됩니다.
이 샘플에서 샘플의 기본 메시지 플로우는 스탭 번호에 대한 정보로 DB2 데이터베이스를 갱신합니다.
오류 핸들링 서브플로우는 스탭 번호를 처리할 때 발생한 오류에 대한 정보로 다른 DB2 데이터베이스를 갱신합니다. 기본 플로우에서 데이터베이스 갱신은 트랜잭션의 제어를 받으므로, 오류가 발생하여 오류 핸들링 서브플로우가 메시지를 처리할 경우 스탭 번호에 대한 데이터베이스 갱신은 롤백되며 확약되지 않습니다. 오류에 대한 정보가 롤백되지 않도록 하기 위해 오류 핸들링 서브플로우에서의
데이터베이스 갱신은 트랜잭션의 제어를 받지 않습니다. 그 이유는 오류 레코드를 제공하려면 정보를 확약해야 하기 때문입니다.
메시지
Error Handler 샘플 실행을 위해 두 개의 입력 메시지가 제공됩니다. 하나는 올바른 스탭 일련 번호를 포함하는 메시지이고, 다른 하나는 올바르지 않은 스탭 일련 번호를 포함하는 메시지입니다.
올바른 스탭 메시지는 다음과 같은 XML 형식으로 구성됩니다.
<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>
올바르지 않은 스탭 메시지는 다음과 같은 XML 형식으로 구성됩니다.
<Staff>
<StaffNumber>99</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>
메시지 플로우
다음 그림은 기본 메시지 플로우를 보여줍니다.

다음 그림은 오류 핸들링 서브플로우를 보여줍니다.
다음 표에서는 Error Handler 샘플에서 사용하는 노드 유형을 나열합니다. Subflow 노드는 실제 노드가 아니므로 노드 팔레트에서 사용할 수 없습니다. Subflow 노드는 단지 기본 메시지 플로우에서 Error_Handler.msgflow 서브플로우가 호출되는 위치를 표시합니다.
노드 유형 |
노드 이름 |
MQInput |
STAFF_IN |
MQOutput |
STAFF_FAIL; STAFF_OUT |
Database |
Update Staff Database; Update Error Database |
Filter |
Check Valid Staff Number; Check Backout Count |
Throw |
Throw; Throw to Complete Rollback |
TryCatch |
TryCatch |
Subflow |
Error_Handler |
자세한 정보는 WebSphere Message Broker 문서에서 Error Handler 샘플 메시지 플로우의 노드를 읽으십시오.
올바른 스탭 메시지의 라우트
입력 큐에 올바른 스탭 메시지를 넣으면, 메시지는 아래에 설명된 대로 노드를 따라 이동합니다. 큐 중 하나라도 사용이 불가능할 경우, 메시지는 이 경로를 따를 수 없습니다.
기본 메시지 플로우에서
- STAFF_IN. 이 노드는 입력 큐에서 입력 메시지를 가져옵니다.
- Error_Handler. 이 노드는 오류 핸들링 서브플로우를 나타냅니다.
이제 메시지는 기본 메시지 플로우에서 나가 서브플로우로 들어갑니다.
서브플로우에서
- Start Subflow. 메시지가 플로우에서 다음 노드로 전달됩니다.
- Check Backout Count. 노드는 백아웃 수가 0인지를 점검합니다.
입력 메시지가 처음 이 노드를 통해 전달되므로 현재 수는 0이며 메시지는 다음 노드로 전달됩니다.
수가 0보다 크면 메시지가 제거됩니다.
- TryCatch. 스탭 번호가 올바르므로 메시지가 Back To Main Flow 노드로 전달됩니다.
메시지 내의 스탭 번호가 올바르지 않을 때 번호가 올바르지 않다는 것을 발견한 단계로 메시지가 진행하면, 메시지가 대신 Update Error Database 노드로 전달됩니다.
- Back To Main Flow. 이 시점에 메시지는 서브플로우에서 나가 기본 메시지 플로우로 되돌아갑니다.
기본 메시지 플로우에서
- Check Valid Staff Number. 스탭 번호가 올바르기 때문에 메시지가 Update Staff Database 노드로 전달됩니다.
- Update Staff Database. STAFFDB 데이터베이스는 메시지 내의 스탭 세부사항으로 갱신됩니다.
- STAFF_OUT. 이 노드는 STAFF_OUT 큐에 메시지를 넣습니다.
올바르지 않은 스탭 메시지의 라우트
입력 큐에 올바르지 않은 스탭 메시지를 넣으면, 메시지는 아래에 설명된 대로 노드를 따라 이동합니다. 큐 중 하나라도 사용이 불가능할 경우, 메시지는 이 경로를 따를 수 없습니다.
각 노드가 수행하는 작업에 대한 자세한 정보를 보려면 기본 주제의 그림에 있는 노드를 누르십시오.
기본 메시지 플로우에서
- STAFF_IN. 이 노드는 입력 큐에서 입력 메시지를 가져옵니다.
- Error_Handler. 이 노드는 오류 핸들링 서브플로우를 나타냅니다.
이제 메시지는 기본 메시지 플로우에서 나가 서브플로우로 들어갑니다.
서브플로우에서
- Start Subflow. 메시지가 플로우에서 다음 노드로 전달됩니다.
- Check Backout Count. 노드는 백아웃 수가 0인지를 점검합니다.
입력 메시지가 처음 이 노드를 통해 전달되므로 현재 수는 0이며 메시지는 다음 노드로 전달됩니다. 아래의 13 단계와 비교하십시오.
- TryCatch.
메시지의 스탭 번호가 올바르지 않으나 이 번호가 올바르지 않다는 것이 아직 발견되지는 않았습니다. 따라서 입력 메시지는 Update Error Database 노드가 아닌 Back To Main Flow 노드로 전달됩니다.
- Back To Main Flow. 이 시점에 메시지는 서브플로우에서 나가 기본 메시지 플로우로 되돌아갑니다.
기본 메시지 플로우에서
- Check Valid Staff Number. 스탭 번호가 올바르지 않기 때문에 메시지는 Update Staff Database 노드가 아닌 Throw Exception 노드로 전달됩니다.
- Throw Exception. 이 노드는 메시지의 처리를 정지하고 오류 번호 "3001"과 "스탭 번호가 올바르지 않음"이라는 텍스트를 메시지 컨텐츠에 기록합니다.
이제 메시지는 '롤백'됩니다. 즉, 메시지는 다시 제어점(이 경우에는 서브플로우의 TryCatch 노드임)으로 전달됩니다.
서브플로우에서
- TryCatch. 이 노드는 메시지 처리 시 예외가 있음을 감지하고 메시지를 Update Error Database 노드로 전달합니다.
- Update Error Database. ERRORDB 데이터베이스는 Throw Exception 노드에 설정된 대로 오류 세부사항으로 갱신됩니다(8 단계).
- Throw To Complete Rollback. 이 노드는 메시지 처리를 정지하고 오류 번호 "3002"와 "Error_Handler 메시지 플로우에서. 세부사항은 ERRORDB를 참조하십시오"라는 텍스트를 메시지 컨텐츠에 기록합니다. 이제 메시지는 제어점(기본 메시지 플로우의 STAFF_IN 노드임)으로 전달됩니다.
이것이 Catch 처리의 최종 단계입니다. 이 단계는 원래 try 경로에서 트랜잭션 제어 하에 데이터베이스 갱신을 비롯하여(즉, 기본 플로우에서 STAFFDB 갱신) 전체 트랜잭션을 롤백하는 효과가 있습니다.
그러나 ERRORDB 갱신(즉, 트랜잭션의 제어를 받지 않음)은 계속해서 확약됩니다.
기본 메시지 플로우에서
- STAFF_IN. 메시지 처리 중에 예외가 발생했기 때문에 메시지는 메시지 플로우를 통해 전달되지 않고 STAFF_FAIL 노드로 전달됩니다.
- STAFF_FAIL. 이 노드는 STAFF_FAIL 큐에 메시지를 넣습니다. 또는
STAFF_FAIL 큐를 사용하지 않을 경우 메시지는 여기서 정지하지 않습니다.
메시지는 STAFF_IN 노드로 다시 전달된 다음, 서브플로우로 전달됩니다.
그런 다음 메시지는 Check Backout Count 노드에 도달합니다. 노드는 백아웃 수가 0인지를 점검합니다.
메시지가 이전에 이 노드를 통해 전달되어 백아웃 수가 0이 아니므로 메시지가 제거됩니다.
STAFF_FAIL 큐를 사용하지 않을 경우, 메시지를 제거하면 메시지가 플로우를 계속해서 이동하는 것을 방지할 수 있습니다.
위의 4 단계와 비교하십시오.
TryCatch 노드를 사용하거나 노드를 MQInput 노드의 Catch 터미널에 접속할 때, catch 경로가 호출되면 try 경로에서 발생한 처리는
확약되지 않는다고 가정할 수 있습니다(노드가 올바르게 구성된 경우).
그러나 이 경우는 그렇지 않습니다. 예를 들어, 트랜잭션 제어 하의
try 경로에서 데이터베이스가 갱신되고 catch 경로가 호출되어 정상적으로 완료되면,
데이터베이스 갱신은 계속 확약됩니다.
이 샘플의 요구사항은 다른 큐에서 메시지를 읽고 데이터베이스를 갱신하며 메시지를 쓰는 것입니다. 오류가 발생할 경우, 데이터베이스 갱신은 롤백됩니다.
Catch 처리는 오류 데이터베이스를 오류 세부사항으로 갱신하며 원래 메시지를 실패 큐에 씁니다.
프로그래밍 조건에서 다음과 같은 작업이 발생합니다.
BEGIN (Start 'outer' unit-of-work.)
MQGET (Get message from the input queue.)
TRY
BEGIN (Start 'inner' unit-of-work.)
Update database
MQPUT (Put message onto the output queue.)
IF ERROR
ROLLBACK inner unit-of-work GO TO CATCH
ELSE
COMMIT inner and outer unit-of-work as one unit-of-work
END IF
CATCH
Update error database
MQPUT (Put message onto the failure queue.)
COMMIT outer unit-of-work
그러나 XA 트랜잭션 관리자 및 WebSphere MQ는 동일한 응용프로그램에서 두 가지 레벨의 작업 단위를 지원하지 않습니다. 결과적으로, Error Handler 샘플은 다음 구조를 사용합니다.
- try 경로에서의 데이터베이스 갱신은 트랜잭션의 제어를 받습니다. 샘플에서 이는 STAFFDB 갱신입니다.
- catch 경로에서의 데이터베이스 갱신은 트랜잭션의 제어를 받지 않습니다.
이는 ERRORDB 데이터베이스입니다.
- MQInput 노드의 Failure 터미널은 실패 큐를 향하는 MQOutput 노드로 접속됩니다.
- Catch 처리의 최종 단계는 Throw 노드를 사용하여 오류를 다시 전달하는 것입니다.
- 메시지는 실패 경로를 MQInput 노드로, 여기서 다시 실패 큐로 롤백합니다.
이 샘플에는 하나가 아닌 두 개의 데이터베이스가 있습니다. 왜냐하면 WebSphere MQ에서는 동일한 메시지 플로우 내의 통합된 트랜잭션 및 통합되지 않은 트랜잭션 모두에 동일한 데이터베이스 연결을 사용할 수 없기 때문입니다.
Error Handler 샘플의 경우 기본 메시지 플로우에서 데이터베이스 갱신은 트랜잭션의
제어를 받으므로, 오류가 발생할 경우 갱신은 롤백되며 확약되지 않습니다.
서브플로우에서 데이터베이스 갱신은 트랜잭션의 제어를 받지 않으므로 갱신은 항상 확약됩니다.
따라서 Error Handler 샘플에는 두 개의 별도의 데이터베이스가 필요합니다.
자세한 정보는 WebSphere Message Broker 문서의
메시지 플로우에서 트랜잭션 통합을 참조하십시오.
샘플 홈으로 돌아가기