오류 핸들링을 위한 ESQL 코딩

소개

메시지 플로우에서 메시지를 처리할 때 다음과 같은 이유로 오류가 발생할 수 있습니다.
  1. 외부 원인. 예를 들면, 들어오는 메시지의 구문이 올바르지 않거나, 플로우에 사용되는 데이터베이스가 종료되었거나, 브로커가 실행 중인 시스템의 전원 공급장치가 고장난 경우입니다.
  2. 내부 원인. 예를 들면, 제한조건 점검으로 인해 행을 데이터베이스 테이블에 삽입하려는 시도가 실패하거나, 데이터베이스에서 읽은 문자열에 알파벳 문자가 있어서 숫자로 변환할 수 없는 경우입니다.

    내부 오류는 데이터베이스에 올바르지 않은 데이터를 저장하는 프로그램이나 플로우 논리의 결함으로 인해 발생할 수 있습니다.

메시지 플로우 설계자는 오류를 고려하여 오류 핸들링 방법을 결정해야 합니다.

디폴트 오류 핸들링 사용

ESQL 오류를 핸들링하기 위한 가장 간단한 방법은 아무 것도 수행하지 않고 브로커의 디폴트 작동을 사용하는 것입니다. 디폴트 작동은 실패한 메시지 처리를 간단히 줄이고 다음 메시지로 진행합니다. 입력 및 출력 노드는 처리를 간단히 줄일 때 발생하는 상황을 올바르게 제어하는 옵션을 제공합니다.

입력 및 출력 노드가 트랜잭션 모드로 설정되면 브로커는 상태를 처리 중인 메시지의 이전 상태로 복원합니다.
  1. 명확하게 입력 큐에서 가져온 입력 메시지는 다시 큐에 넣어집니다.
  2. 플로우가 명확하게 출력 큐에 기록한 출력 메시지는 제거됩니다.
입력 및 출력 노드가 트랜잭션 모드로 설정되지 않으면 다음과 같은 상황이 발생합니다.
  1. 입력 큐에서 가져온 입력 메시지는 다시 큐에 넣어 지지 않습니다.
  2. 플로우가 출력 큐에 기록한 출력 메시지는 그대로 남습니다.

위의 방법들은 각각 고유한 장점을 가지고 있습니다. 트랜잭션 모드는 데이터의 연속성을 보존하는 반면, 비트랜잭션 모드는 메시지 처리의 지속성을 최대화합니다. 트랜잭션 모델에서는 실패한 입력 메시지가 다시 입력 큐에 넣어지므로 브로커가 다시 처리를 시도한다는 점에 유의하십시오. 가장 가능한 결과는 데드-레터 큐에 넣어지는 시점인 재시도 한계에 도달할 때까지 메시지가 계속 실패한다는 것입니다. 메시지 처리에 실패하는 이유가 시스템 이벤트 로그(Windows) 또는 syslog(UNIX)에 기록됩니다. 따라서 실패 메시지는 성공적인 후속 메시지의 처리를 얼마간 억제한 후 브로커에 의해 처리되지 않은 상태로 남겨집니다.

대부분의 데이터베이스는 트랜잭션 방식으로 작동하므로, 데이터베이스 테이블에 대해 수행된 모든 변경사항은 메시지 처리에 성공할 경우에 확약되고 실패하면 롤백되어, 데이터의 무결성을 유지합니다. 이에 대한 예외로, 브로커 자체 또는 데이터베이스가 실패할 경우가 있습니다. (예를 들면, 실행 중인 시스템의 전원 공급이 차단되었을 수 있습니다.) 이 경우 일부 데이터베이스에서의 변경사항은 확약되지만 다른 데이터베이스에서의 변경사항은 확약되지 않습니다. 또는 데이터베이스 변경사항은 확약되지만 입력 및 출력 메시지는 확약되지 않습니다. 이러한 가능성이 클 경우에는 플로우를 통합하고 관련 데이터베이스를 이와 같은 작동 방식으로 구성해야 합니다.

사용자 정의 오류 핸들링 사용

사용자 정의 오류 핸들러 작성에 대한 일반적인 팁은 다음과 같습니다.
  1. 디폴트 오류 핸들링보다 더 나은 것이 필요할 경우, 첫 번째 단계는 핸들러를 사용하는 것입니다(DECLARE HANDLER문 참조). 노드마다 하나의 핸들러를 작성하여 가능한 모든 예외(또는 예측할 수 있는 모든 예외)를 차단하십시오.
  2. 오류가 차단되도록 하면 오류 핸들러는 오류를 핸들링하는 데 적절한 논리를 사용할 수 있습니다. 또는 오류 핸들러는 THROW 명령문이나 노드를 사용하여 예외를 작성할 수 있습니다. 이 예외는 플로우 논리의 한층 높은 수준에서 핸들링되거나 입력 노드에 도달하여 트랜잭션이 롤백되도록 할 수도 있습니다. 예외 전달을 참조하십시오.
  3. 핸들러가 포착하지 못하는 예외를 노드가 전달할 경우, 플로우는 failure 터미널(접속되어 있는 경우)로 전환되거나 디폴트 오류 핸들링에 의해 핸들링됩니다(접속되어 있지 않는 경우).

    failure 터미널을 사용하여 핸들링하지 않은 오류를 포착하십시오. 간단한 논리 플로우를 failure 터미널에 접속시키십시오. 이 논리 플로우는 데이터베이스(메시지의 비트스트림을 포함할 수 있음)에 로그 레코드를 기록하거나 레코드를 이벤트 로그에 기록하는 Compute 노드나 데이터베이스로 구성할 수 있습니다. 메시지를 특수 큐에 기록하는 출력 노드도 포함할 수 있습니다.

    전체 예외 트리는 failure 터미널에 연결된 노드로 전달됩니다. (예외 트리는 예외 목록 트리 구조에 설명되어 있습니다.)

  4. 오류 핸들러가 각각의 오류를 적절한 위치(예: 시스템 이벤트 로그)에 기록합니다.

메시지 플로우의 오류를 처리하는 데 사용할 수 있는 옵션에 대한 자세한 정보는 메시지 플로우 내의 오류 핸들링을 참조하십시오. 다음 주제에서는 수행할 수 있는 예에 대해 설명합니다.

오류 감지 코딩

다음 절에서는 브로커가 오류를 감지한다고 가정합니다. 그러나 플로우 논리가 오류를 감지할 수도 있습니다. 예를 들면, 플로우 논리를 코딩할 때 다음을 사용할 수 있습니다.
  • 발생하면 안되는 상황을 특별히 감지하도록 삽입된 IF 문
  • 불가능한 라우트를 코드를 통해 트랩하기 위한 case 표현식 또는 명령문의 ELSE 절.
플로우 논리에서 감지되는 오류의 예로, 메시지 유형을 표시하는 광범위한 정수 값을 가지고 있는 필드를 고려하십시오. 이와 같은 경우, 메시지가 필드의 값이 알려진 메시지 유형에 해당되지 않는 상황에 이르기까지 방치하는 것은 권장되지 않습니다. 이와 같은 상황에 발생할 수 있습니다. 시스템이 추가 메시지 유형을 지원하기 위해 업그레이드되었지만 시스템의 한 부분이 업그레이드되지 않은 경우입니다.

고유한 논리를 사용하여 올바르지 않은 입력 메시지 핸들링

구문상 올바르지 않은 입력 메시지(그리고 오류 발생 가능성이 있는 메시지 형식 정보로 인해 올바르지 않은 것으로 표시되는 입력 메시지)는 브로커가 메시지에 포함된 내용을 알 수 없으므로 처리하기가 힘듭니다. 최상의 방법은 입력 모드가 메시지를 완전히 구문 분석하여 유효성을 검증하도록 구성하는 것입니다.

그러나, 이 방법은 사전 정의된 메시지(즉, MRM 또는 IDOC)에만 적용됩니다.

이 방법으로 입력 노드를 구성한 경우, 입력 메시지를 올바르게 구문 분석할 수 없으면 다음이 보장됩니다.
  • 입력 메시지는 노드의 출력 터미널에서 나타나지 않습니다. (failure 터미널로 이동합니다.)
  • 입력 메시지는 메시지 플로우의 기본 부분을 입력하지 않습니다.
  • 입력 메시지로 인해 데이터베이스가 갱신되지 않습니다.
  • 출력 큐에 메시지가 작성되지 않습니다.

실패 메시지를 처리하려면 failure 터미널에 단순 논리 플로우를 연결하십시오.

이 방법의 유일한 단점은 정상 플로우가 모든 메시지 필드에 액세스하지 않아도 될 경우에 메시지의 전체 구문 분석 강요로 성능에 영향을 준다는 것입니다.

고유한 논리를 사용하여 데이터베이스 오류 핸들링

데이터베이스 오류는 다음 세 가지 범주에 속합니다.
  1. 데이터베이스가 전혀 작동하지 않습니다(예: 오프 라인 상태).
  2. 데이터베이스는 작동하지만 사용자 요청을 거부합니다(예: 잠금 경합 발생).
  3. 데이터베이스는 작동하지만 수행하기 위해 요청하는 작업이 불가능합니다(예: 존재하지 않는 테이블에서 읽기).

디폴트 오류 핸들링보다 더 나은 것이 필요할 경우, 첫 번째 단계는 핸들러를 사용하여 예외를 차단하는 것입니다(DECLARE HANDLER문 참조). 핸들러는 데이터베이스가 리턴하는 SQL 상태에서 실패 특성을 판별할 수 있습니다.

데이터베이스가 작동하지 않음
데이터베이스가 전혀 작동하지 않지만 메시지 처리에 데이터베이스가 중요한 경우에는 수행할 수 있는 방법이 많지 않습니다. 이 경우 핸들러가 원인을 판별한 후 다음을 수행할 수 있습니다.
  • RESIGNAL 문을 사용하여 원래의 오류가 다시 전달되도록 합니다. 따라서 디폴트 오류 핸들러가 인계할 수 있습니다.
  • 다른 데이터베이스를 사용합니다.
  • 메시지를 특정의 출력 큐에 기록합니다.

    그러나 이 종류의 방법을 사용할 때는 주의해야 합니다. 핸들러는 예외를 수용하므로 다른 데이터베이스에 대한 변경사항이나 큐에 쓴 내용이 확약됩니다.

데이터베이스가 요청을 거부함
잠금 경합이 발생하는 상황은 "데이터베이스 작동 안함" 경우와 유사합니다. 이는 데이터베이스가 실패한 요청 뿐만 아니라 현재 메시지에 대해 수행된 모든 변경사항을 백아웃하기 때문입니다. 따라서 유일한 갱신사항이라는 확신이 없으면 오류를 기록하거나 메시지를 특수한 큐로 전달할 수 있는 것을 제외하고는 디폴트 오류 핸들링보다 더 나은 방법은 없습니다.
불가능한 요청
데이터베이스는 작동하지만 수행하기 위해 요청하는 작업이 불가능한 경우에는 광범위한 문제점과 연관되어 있을 수 있습니다.
예와 같이, 데이터베이스가 단지 플로우가 예상하는 이름 테이블을 가지고 있지 않으면, 오류를 기록하거나 메시지를 특수한 큐로 전달할 수 있는 것을 제외하고는 디폴트 오류 핸들링보다 좋은 방법은 없습니다.
그러나 많은 다른 오류를 핸들링할 수 있습니다. 예를 들면, 행을 삽입하려고 하는데 이미 그 행이 있어서 새 행이 중복되므로 시도가 실패할 수 있습니다. 또는 행을 갱신하려고 하는데 그 행이 없어서(즉, 갱신에서 0개의 행을 갱신함) 실패할 수도 있습니다. 이와 같은 경우, 핸들러는 사용자가 적합하다고 생각하는 어떤 논리도 통합할 수 있습니다. 누락된 행을 삽입하거나 기존 행을 이용할 수 있습니다(행의 값이 적합한지 확인할 수 있음).
주: 0개 행 갱신이 오류로 보고될 경우, 노드 등록 정보 "경고를 오류로 처리"를 참으로 설정해야 합니다. 이 설정은 디폴트 설정이 아닙니다.

고유한 논리를 사용하여 출력 노드에서 오류 핸들링

변경 시작MQ 출력 노드에서 발생하는 오류는 SQL 상태에서 오류의 특성을 보고하고 SQL 고유 오류 변수에서 추가 정보를 제공합니다. 따라서 디폴트 오류 핸들링 이상이 필요할 경우, 첫 번째 단계는 핸들러를 사용하여 예외를 차단하는 것입니다(DECLARE HANDLER문 참조). 이와 같은 핸들러는 단일 PROPAGATE 문만 일반적으로 묶을 수 있습니다. 변경 끝

고유한 논리를 사용하여 다른 오류 핸들링

위에서 다룬 오류 외에도, 다양한 기타 오류가 빌생할 수 있습니다. 예를 들면, 산술 계산 오버플로우, 데이터의 부적합성으로 인한 캐스트 실패 또는 유형 제한으로 인한 메시지 필드 액세스 실패 등이 발생할 수 있습니다. 브로커는 이와 같은 오류를 처리하기 위해 두 가지의 프로그래밍 방법을 제공합니다.
  1. 오류로 인해 핸들링되거나 트랜잭션을 롤백하도록 남겨지는 예외가 발생합니다.
  2. 실패는 나중에 테스트하는 특수 값으로 기록됩니다.

유형 제한조건이 없으면, 존재하지 않는 메시지 필드에 액세스하려고 할 때 널(null) 값이 생성됩니다. 널(null) 값은 표현식을 통해 전달되며 결과를 널(null)로 만듭니다. 따라서 표현식(복합)이 널 값을 리턴하지 않을 경우, 결과를 계산하는 데 필요한 모든 값이 널(null)이 아니었음을 알 수 있습니다.

캐스트 표현식에는 디폴트 절이 있을 수 있습니다. 디폴트 절이 있을 경우 캐스트는 실패합니다. 예외를 전달하는 대신 단지 디폴트 값을 리턴합니다. 디폴트 값은 innocuous number(예: 정수의 0)나 컨텍스트에서 명백하게 올바르지 않은 값(예: 고객 번호로 -1)이 될 수 있습니다. 널(null)은 다른 모든 값과 다르고 오류 조건이 마스킹될 가능성없이 표현식을 통해 전달되는 값이므로 특히 적합합니다.

기타 노드 내의 오류 핸들링

기타 노드(즉, PROPAGATE문의 다운스트림)에서 발생하는 예외는 정상적인 방식으로 핸들러에 의해 포착될 수도 있습니다. 그러나, 이러한 오류를 핸들링하다 보면 다른 노드가 오류 핸들링에 관여될 가능성이 크다는 특수 문제점이 발생합니다(다른 노드가 원래 오류에 관련되기 때문이며 예외의 진원지일 필요는 없음).

이러한 상황에 도움이 되도록 데이터베이스와 Compute 노드에는 out1, out2, out3out4라는 네 개의 새 터미널이 있습니다. 또한, PROPAGATE문의 구문은 이러한 추가 터미널에 대한 제어를 제공하도록 대상 표현식, 메시지 소스 및 제어 절을 포함하도록 확장되었습니다.

주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ac17140_