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