내부 오류는 데이터베이스에 올바르지 않은 데이터를 저장하는 프로그램이나 플로우 논리의 결함으로 인해 발생할 수 있습니다.
ESQL 오류를 핸들링하기 위한 가장 간단한 방법은 아무 것도 수행하지 않고 브로커의 디폴트 작동을 사용하는 것입니다. 디폴트 작동은 실패한 메시지 처리를 간단히 줄이고 다음 메시지로 진행합니다. 입력 및 출력 노드는 처리를 간단히 줄일 때 발생하는 상황을 올바르게 제어하는 옵션을 제공합니다.
위의 방법들은 각각 고유한 장점을 가지고 있습니다. 트랜잭션 모드는 데이터의 연속성을 보존하는 반면, 비트랜잭션 모드는 메시지 처리의 지속성을 최대화합니다. 트랜잭션 모델에서는 실패한 입력 메시지가 다시 입력 큐에 넣어지므로 브로커가 다시 처리를 시도한다는 점에 유의하십시오. 가장 가능한 결과는 데드-레터 큐에 넣어지는 시점인 재시도 한계에 도달할 때까지 메시지가 계속 실패한다는 것입니다. 메시지 처리에 실패하는 이유가 시스템 이벤트 로그(Windows) 또는 syslog(UNIX)에 기록됩니다. 따라서 실패 메시지는 성공적인 후속 메시지의 처리를 얼마간 억제한 후 브로커에 의해 처리되지 않은 상태로 남겨집니다.
대부분의 데이터베이스는 트랜잭션 방식으로 작동하므로, 데이터베이스 테이블에 대해 수행된 모든 변경사항은 메시지 처리에 성공할 경우에 확약되고 실패하면 롤백되어, 데이터의 무결성을 유지합니다. 이에 대한 예외로, 브로커 자체 또는 데이터베이스가 실패할 경우가 있습니다. (예를 들면, 실행 중인 시스템의 전원 공급이 차단되었을 수 있습니다.) 이 경우 일부 데이터베이스에서의 변경사항은 확약되지만 다른 데이터베이스에서의 변경사항은 확약되지 않습니다. 또는 데이터베이스 변경사항은 확약되지만 입력 및 출력 메시지는 확약되지 않습니다. 이러한 가능성이 클 경우에는 플로우를 통합하고 관련 데이터베이스를 이와 같은 작동 방식으로 구성해야 합니다.
failure 터미널을 사용하여 핸들링하지 않은 오류를 포착하십시오. 간단한 논리 플로우를 failure 터미널에 접속시키십시오. 이 논리 플로우는 데이터베이스(메시지의 비트스트림을 포함할 수 있음)에 로그 레코드를 기록하거나 레코드를 이벤트 로그에 기록하는 Compute 노드나 데이터베이스로 구성할 수 있습니다. 메시지를 특수 큐에 기록하는 출력 노드도 포함할 수 있습니다.
전체 예외 트리는 failure 터미널에 연결된 노드로 전달됩니다. (예외 트리는 예외 목록 트리 구조에 설명되어 있습니다.)
메시지 플로우의 오류를 처리하는 데 사용할 수 있는 옵션에 대한 자세한 정보는 메시지 플로우 내의 오류 핸들링을 참조하십시오. 다음 주제에서는 수행할 수 있는 예에 대해 설명합니다.
구문상 올바르지 않은 입력 메시지(그리고 오류 발생 가능성이 있는 메시지 형식 정보로 인해 올바르지 않은 것으로 표시되는 입력 메시지)는 브로커가 메시지에 포함된 내용을 알 수 없으므로 처리하기가 힘듭니다. 최상의 방법은 입력 모드가 메시지를 완전히 구문 분석하여 유효성을 검증하도록 구성하는 것입니다.
그러나, 이 방법은 사전 정의된 메시지(즉, MRM 또는 IDOC)에만 적용됩니다.
실패 메시지를 처리하려면 failure 터미널에 단순 논리 플로우를 연결하십시오.
이 방법의 유일한 단점은 정상 플로우가 모든 메시지 필드에 액세스하지 않아도 될 경우에 메시지의 전체 구문 분석 강요로 성능에 영향을 준다는 것입니다.
디폴트 오류 핸들링보다 더 나은 것이 필요할 경우, 첫 번째 단계는 핸들러를 사용하여 예외를 차단하는 것입니다(DECLARE HANDLER문 참조). 핸들러는 데이터베이스가 리턴하는 SQL 상태에서 실패 특성을 판별할 수 있습니다.
그러나 이 종류의 방법을 사용할 때는 주의해야 합니다. 핸들러는 예외를 수용하므로 다른 데이터베이스에 대한 변경사항이나 큐에 쓴 내용이 확약됩니다.
MQ 출력 노드에서 발생하는 오류는 SQL 상태에서 오류의 특성을 보고하고
SQL 고유 오류 변수에서 추가 정보를
제공합니다. 따라서 디폴트 오류 핸들링 이상이 필요할 경우, 첫 번째 단계는 핸들러를 사용하여 예외를
차단하는 것입니다(DECLARE HANDLER문 참조). 이와 같은 핸들러는 단일 PROPAGATE 문만 일반적으로
묶을 수 있습니다.
유형 제한조건이 없으면, 존재하지 않는 메시지 필드에 액세스하려고 할 때 널(null) 값이 생성됩니다. 널(null) 값은 표현식을 통해 전달되며 결과를 널(null)로 만듭니다. 따라서 표현식(복합)이 널 값을 리턴하지 않을 경우, 결과를 계산하는 데 필요한 모든 값이 널(null)이 아니었음을 알 수 있습니다.
캐스트 표현식에는 디폴트 절이 있을 수 있습니다. 디폴트 절이 있을 경우 캐스트는 실패합니다. 예외를 전달하는 대신 단지 디폴트 값을 리턴합니다. 디폴트 값은 innocuous number(예: 정수의 0)나 컨텍스트에서 명백하게 올바르지 않은 값(예: 고객 번호로 -1)이 될 수 있습니다. 널(null)은 다른 모든 값과 다르고 오류 조건이 마스킹될 가능성없이 표현식을 통해 전달되는 값이므로 특히 적합합니다.
기타 노드(즉, PROPAGATE문의 다운스트림)에서 발생하는 예외는 정상적인 방식으로 핸들러에 의해 포착될 수도 있습니다. 그러나, 이러한 오류를 핸들링하다 보면 다른 노드가 오류 핸들링에 관여될 가능성이 크다는 특수 문제점이 발생합니다(다른 노드가 원래 오류에 관련되기 때문이며 예외의 진원지일 필요는 없음).
이러한 상황에 도움이 되도록 데이터베이스와 Compute 노드에는 out1, out2, out3 및 out4라는 네 개의 새 터미널이 있습니다. 또한, PROPAGATE문의 구문은 이러한 추가 터미널에 대한 제어를 제공하도록 대상 표현식, 메시지 소스 및 제어 절을 포함하도록 확장되었습니다.