브로커는 모든 메시지 플로우에 대한 기본 오류 핸들링을
제공합니다. 기본 처리가 충분하지 않고 특정 오류 조건 및 상황에 대한
응답으로 특정 조치를 취하려는 경우 메시지 플로우를 개선하여 사용자만의
오류 핸들링을 제공할 수 있습니다. 예를 들어
특정 방식으로 처리하려는 특정 오류가 예상되는 메시지 플로우 또는
기타 처리가 제대로 완료되지 않은 경우 데이터베이스를 갱신하고 이들 갱신을
롤백해야 하는 플로우를 설계할 수 있습니다.
이러한 작업에
사용할 수 있는 옵션은 일부 경우에는 매우 복잡합니다. MQInput
및 TimeoutNotification 노드는 지속 메시지 및 트랜잭션을
처리하므로 이 노드에 제공되는 옵션은 광범위합니다. 또한 MQInput은 WebSphere MQ의
구성 옵션에 영향을 받습니다.
각각의 오류를 서로 다른 방식으로
핸들링하도록 할 수 있으므로 설명할 고정 프로시저는 없습니다.
이 절에서는 오류 핸들링 원리 및 사용
가능한 옵션에 대한 정보를 제공하고 이 절에서 제공하는 세부사항에 따라 각 상황에 필요한 선택사항의
조합을 결정해야 합니다.
메시지 플로우에서 이들 옵션을 하나 이상 선택할 수 있습니다.
- 노드의 failure 터미널을 노드의 내부 예외를 처리하는 일련의 노드에 연결합니다(fail 플로우).
- 입력 노드 또는 TryCatch 노드의 catch 터미널을
노드 외부에서 생성된 예외를 처리하는 일련의 노드에 연결합니다(catch 플로우).
- 메시지 플로우의 특정 지점에서 하나 이상의 TryCatch 노드를
삽입하여 try 터미널에 연결된 플로우에서 생성한 예외를 포착 및 처리합니다.
- Throw 노드를 포함하거나 ESQL THROW문을 코드화하여
예외를 생성합니다.
- 집계를 사용하는 경우 AggregateReply 노드의 catch 터미널을
연결하여 집계 예외를 처리합니다.
- 또는 MQInput 노드에서 수신한 모든 메시지가
트랜잭션에서 처리되는지를 확인합니다.
- 또는 MQInput 노드에서 수신한 모든 메시지가
지속 메시지인지를 확인합니다.
메시지 플로우에 사용자 정의 노드를 포함시키는 경우
이러한 노드에서 오류를 핸들링하는 방법을 이해하려면 노드와 함께 제공된 정보를
참조해야 합니다. 이 절에서는 내장 노드만 설명합니다.
오류 핸들링 방식을 설계할 때,
다음 요인을 고려하십시오.
- 대부분의 내장 노드에는 failure 터미널이 있습니다. 예외는 AggregateControl입니다. AggregateRequest, Input, Label, Output,
Passthrough, Publication, Real-timeInput Real-timeOptimizedFlow, Throw, Trace 및 TryCatch.
노드에서
예외가 감지되면 메시지 및 예외 정보가 노드의 failure 터미널로
전달됩니다. 노드에 failure 터미널이 없거나
노드가 연결되어 있지 않으면 브로커는 예외를 전달하고
제어를 예외를 처리할 수 있는 가장 가까운 이전 노드에
리턴합니다. 이 노드는 TryCatch 노드, AggregateReply 노드 또는 Input
노드일 수 있습니다.
또는 MQinput 노드가
내부 오류를 감지한 경우 이 노드의 동작은 약간 다릅니다. failure 터미널이
연결되어 있지 않으면 메시지를 입력 큐의 백아웃 리큐 큐 또는 이 큐가 정의되지 않은 경우
브로커 큐 관리자의 데드-레터 큐에 넣도록 시도합니다.
- catch 터미널이 있는 내장 노드는 적습니다.
AggregateReply, HTTPInput, MQInput,
SCADAInput, JMSInput, JMSOutput,TimeoutNotification 및 TryCatch가 이에 속합니다.
메시지가
처음으로 노드 외부에(예: Out 터미널에 연결된 노드) 전달된 경우에만 메시지가
catch 터미널로 전달됩니다.
- 메시지가 failure 또는 catch 터미널에 전달되면, 노드가
새 예외 목록을 작성하여 발생한 오류를 나타내는 예외로 채웁니다. 예외 목록은 메시지 트리의 부분으로 전달됩니다.
- MQInput
및 TimeoutNotification 노드에서는 트랜잭션 메시지를 추가로 처리합니다. (다른
입력 노드에서는 트랜잭션 메시지를 핸들링하지 않습니다.)
- 특정 $Root 또는 $Body를 지정하는 Trace 노드를
포함시키는 경우 전체 메시지의 구문이 분석됩니다. 이때 해당 노드를 포함하지 않는 경우에는
감지되지 않는 구문 분석기 오류가 생성될 수 있습니다.
오류를 핸들링하는 일반 원리는 다음과 같습니다.
- 입력 노드의 catch 터미널을 연결하는 경우 플로우가 출력 플로우에
생성되는 모든 예외를 핸들링함이 나타납니다. 포착 플로우에 예외가 있는 경우에만 브로커가
롤백을 수행하고 조치를 취합니다. 예외가 발생하여 포착된 후 롤백
조치를 수행하려면 포착 플로우에서 이를 제공해야 합니다.
- MQInput 또는 HTTPInput 노드의 catch 터미널을
연결하지 않으면 failure 터미널을 연결하고 실패 플로우를 제공하여 해당
노드에서 생성한 예외를 핸들링할 수 있습니다. 노드에서 예외가 발생하는
즉시 실패 플로우가 호출됩니다.
fail 플로우는
out 또는 catch 플로우에 있는 MQInput 노드 외부에서 예외가 생성된 경우, 메시지가 트랜잭션인 경우
및 입력 큐의 메시지 복귀로 백아웃 수가 백아웃 임계값에 도달하는 경우에도
호출됩니다.
HTTPInput
및 SCADAInput 노드는 노드 외부에서 예외가 생성되고 사용자가 catch 터미널에 연결되지 않은 경우
메시지를 failure 터미널에 전달하지 않습니다.
- 노드가 메시지를 catch 플로우에 전달하고 제어를 다시 동일한 노드로 리턴하는
다른 예외가 발생하면, catch 터미널이 연결되어 있지 않아도 노드에서 메시지를
핸들링합니다.
- 입력 노드의 failure 또는 catch 터미널을 연결하지 않은 경우
브로커는 입력 노드의 유형에 따라 서로 다른 디폴트 처리를
제공합니다.
- 더욱 포괄적인 오류 및 복구 접근 방식이 필요하면
하나 이상의 TryCatch 노드를 포함시켜 더욱 로컬화된 오류 핸들링 영역을
제공합니다.
- 특정 오류를 핸들링하는 공통 프로시저가 있으면
필요한 일련의 노드를 포함하는 서브플로우를 작성하는 것이
좋습니다. 해당 조치를 취해야 하는 모든 경우에 이 서브플로우를 포함시키십시오.
자세한 정보는 다음 주제를 참조하십시오.
메시지 플로우가 데이터베이스 갱신을 포함하는 경우
해당 데이터베이스와 상호작용하는 노드를 구성하는 방식 또한
오류 핸들링 방법에 영향을 줄 수 있습니다.
- 갱신을 확약할지 또는 롤백할지를 지정할 수 있습니다. 노드
등록 정보 트랜잭션을 설정하여
데이터베이스 갱신을 메시지 플로우에서 확약 또는 롤백할지를
지정하거나(자동 옵션)
노드 종료 시 확약 또는 롤백할지를 지정할 수
있습니다(확약 옵션). 메시지
플로우 오류 처리 및이러한 등록 정보 설정의 결합으로 올바른 결과가 생성되는지 확인해야 합니다.
- 데이터베이스 오류의 핸들링 방법을 지정할 수 있습니다. 경고를 오류로 처리 및 데이터베이스 오류에 예외 전달 등록 정보를
설정하여 데이터베이스 오류 핸들링의 디폴트 동작을 변경할 수 있습니다.
통합 데이터베이스 갱신에 대한 자세한 정보는
통합된 메시지 플로우에 대한 노드 구성을 참조하십시오.
집계에
대한 메시지 플로우는 이 절에서 설명하지 않은 추가 고려사항과 관련되어 있습니다.
이 고려사항은 집계 플로우의 예외 핸들링에서 설명합니다.
Error Handler 샘플은 오류 핸들링 루틴을 사용하여 오류에 대한
정보를 트랩하고 데이터베이스에 정보를 저장하는 방법에 대해
설명합니다. 오류 핸들링 루틴은 변경되지 않은 상태로 임의의 메시지 플로우에
추가할 수 있는 서브플로우입니다. 샘플은 트랜잭션성을 제어하도록 메시지
플로우를 구성하는 방법, 특히 전체 데이터 무결성을 확인하도록
전역적으로 통합된 트랜잭션 사용에 대해 설명합니다.