릴리스 정보

|20.5 사용 시나리오

|MQSeries 함수를 다양한 시나리오로 사용할 수 있습니다. |이 섹션에서는 기본 메시지, 응용프로그램 연결성 및 데이터 책을 |포함한 일반적인 시나리오를 몇 가지 검토합니다.

|20.5.1 기본 메시지

|모든 데이터베이스 응용프로그램이 같은 DB2 서버에 연결되어 있을 때 MQSeries DB2 함수와의 |가장 기본적인 형태의 메시지 교환이 이루어집니다. |클라이언트는 데이터베이스 서버에 있거나 네트워크 환경에 분산되어 있습니다.

|간단한 시나리오에서 클라이언트 A는 MQSEND 함수를 호출하여 사용자 정의 |문자열을 기본 서비스 위치로 보냅니다. |그러면 MQSeries 함수가 데이터베이스 서버의 DB2에서 실행됩니다. |잠시 후에 클라이언트 B가 MQRECEIVE 함수를 호출하여 기본 서비스에서 정의한 |대기행렬 헤드에서 메시지를 제거하여 이를 클라이언트에게 리턴합니다. |이 작업을 수행할 MQSeries 함수가 다시 DB2에 의해 실행됩니다.

|데이터베이스 클라이언트는 간단한 메시지를 다양한 방법으로 사용할 수 있습니다. |일반적으로 다음과 같은 경우에 메시징을 사용합니다. |

• |데이터 콜렉션 -- 하나 이상의 다양한 정보 소스에서 메시지 형태로 정보를 받습니다. |정보 소스는 SAP나 사내에서 개발된 응용프로그램과 같은 상업용 응용프로그램입니다. |대기행렬에서 이러한 데이터를 받아서 추가로 처리하거나 분석하기 위해 |데이터베이스 테이블에 저장합니다.
• |워크로드 분산 -- 작업 요청이 동일한 응용프로그램의 여러 인스턴스가 공유하는 |대기행렬에 포스트됩니다. |인스턴스가 일부 작업을 수행할 준비가 되면 수행할 작업 요청이 있는 대기행렬의 |최상단에서 메시지를 받습니다. |이러한 기법을 사용하면 요청으로 채워진 단일 대기행렬로 표현되는 워크로드를 |여러 인스턴스가 공유할 수 있습니다.
• |응용프로그램 신호 -- 여러 프로세스가 공동 작업하는 경우, 서로 |협조하기 위해 메시지를 주로 사용합니다. |이 메시지에는 수행할 작업에 대한 명령이나 요청이 포함됩니다. |일반적으로 이러한 종류의 신호는 단방향입니다. 즉, 메시지를 보내는 개시자가 |응답을 기대하지 않습니다. |자세한 정보는 20.5.4.1, 요청/응답 통신을 참조하십시오.
• |응용프로그램 통지 -- 통지는 데이터를 보내는 개시자가 응답을 기대하지 |않는다는 점에서 신호와 비슷합니다. |그러나 일반적으로 통지에는 발생한 비지니스 이벤트에 대한 데이터가 포함됩니다. |20.5.4.2, Publish/Subscribe는 통지의 개선된 형태입니다. |

|다음 시나리오는 원격 메시지를 통합하기 위해 위에서 설명한 단순한 시나리오를 |확장한 것입니다. |즉, 머신 A와 머신 B 사이에서 메시지가 전송됩니다. 각 단계는 다음과 같습니다. |

1. |DB2 클라이언트가 머신 B의 원격 대기행렬을 나타내기 위해 정의된 대상 서비스를 |지정하는 MQSEND 호출을 실행합니다.
2. |MQSeries DB2 함수는 메시지를 보내는 실제 MQSeries 작업을 수행합니다. |머신 A의 MQSeries 서버는 메시지를 받아들이고 이 메시지가 머신 A의 현재 MQSeries 구성 및 |서비스 지점 정의로 정의한 목적지로 배달되도록 보장합니다. 서버는 머신 B의 |대기행렬임을 파악한 후 메시지를 머신 B의 MQSeries 서버로 배달하려고 시도합니다. |이 때 필요하면 투명하게 재시도합니다.
3. |머신 B의 MQSeries서버는 머신 A의 서버에서 보낸 메시지를 받고 |이 메시지를 머신 B의 목적지 대기행렬에 갖다 놓습니다.
4. |머신 B의 MQSeries 클라이언트는 대기행렬의 헤드에서 메시지를 요청합니다. |

|20.5.2 메시지 전송

|MQSEND를 사용하여 DB2 사용자나 개발자는 전송할 데이터, 전송할 위치 및 전송 시기를 |선택합니다. |업계에서는 이를 "보내고 잊어버리기" 즉, 보낸 사람은 단지 메시지를 보내기만 하고 |메시지가 목적지에 도달했는지 확인하는 것은 MQSeries 배달 프로토콜이라고 합니다. |다음은 이를 보여주는 예입니다.

|예 4: 사용자 정의 문자열을 서비스 지점 myPlace로 highPriority 규정과 함께 보냅니다.

|VALUES DB2MQ.MQSEND('myplace','highPriority','test')

|여기서 highPriority 규정은 MQSeries 우선순위를 가장 높은 레벨로 설정하고 지속성과 같은 |서비스 질도 동일하게 조정하는 AMI Repository에 정의된 규정을 참조합니다.

|메시지 내용은 SQL 및 사용자 지정 데이터의 적법한 결합으로 구성될 수 있습니다. |여기에는 중첩된 함수, 연산자 및 캐스트가 포함됩니다. |예를 들어, VARCHAR 컬럼 LASTNAME, FIRSTNAME 및 DEPARTMENT이 있는 EMPLOYEE 테이블에서 |DEPARTMENT 5LGA의 각 직원에 대해 이 정보를 포함하는 메시지를 보내려면 다음을 수행해야 합니다.

|예 5:

|SELECT DB2MQ.MQSEND(LASTNAME || ' ' || FIRSTNAME || ' ' || DEPARTMENT)
|   FROM EMPLOYEE
|   WHERE DEPARTMENT = '5LGA'

|이 테이블에 정수 AGE 컬럼도 있으면 다음이 포합됩니다.

|예 6:

|SELECT DB2MQ.MQSEND
|      (LASTNAME || ' ' || FIRSTNAME || ' ' || DEPARTMENT|| ' ' || char(AGE))
|   FROM EMPLOYEE
|   WHERE DEPARTMENT = '5LGA'

|EMPLOYEE 테이블에 ACE 컬럼이 아닌 CLOB 유형의 RESUME 컬럼이 있을 경우, DEPARTMENT |5LGA의 각 고용인에 대한 정보를 포함하는 메시지를 다음과 같이 내보냅니다.

|예 7:

|SELECT DB2MQ.MQSEND
|      (clob(LASTNAME) || ' ' || clob(FIRSTNAME) || ' ' || clob(DEPARTMENT) || ' ' || RESUME))
|   FROM EMPLOYEE
|   WHERE DEPARTMENT = '5LGA'

|예 8:

|마지막으로 다음 예는 유효한 SQL 표현식을 사용하여 메시지 내용을 추출하는 방법을 보여줍니다. |두 번째 테이블 DEPT에는 VARCHAR 컬럼 DEPT_NO 및 DEPT_NAME이 있고 직원의 |LASTNAME 및 DEPT_NAME을 포함하는 메시지를 보낼 수 있습니다.

|예 8:

|SELECT DB2MQ.MQSEND(e.LASTNAME || ' ' || d.DEPTNAME) FROM EMPLOYEE e, DEPT d
|   WHERE e.DEPARTMENT = d.DEPTNAME

|20.5.3 메시지 검색

|MQSeries DB2 함수를 사용하여 메시지를 받거나 읽을 수 있습니다. |읽는 것과 받는 것의 차이는 읽는 경우 대기행렬의 헤드에서 메시지를 제거하지 않고 |메시지를 리턴하지만 받는 경우에는 메시지가 대기행렬에서 제거됩니다. |받는 작업을 사용하여 검색된 메시지는 한 번만 검색할 수 있지만 읽는 작업을 사용하여 |검색된 메시지는 여러 번 검색할 수 있습니다. |다음은 이를 보여주는 예입니다.

|예 8:

|VALUES DB2MQ.MQREAD()

|이 예에서는 기본 서비스 질 규정을 사용하는 기본 서비스가 정의한 대기행렬의 헤드에서 |메시지를 포함하는 VARCHAR 문자열을 리턴합니다. |읽을 메시지가 없을 경우, 널(NULL) 값이 리턴된다는 점에 주의하십시오. |이 작업으로 대기행렬은 변경되지 않습니다.

|예 9:

|VALUES DB2MQ.MQRECEIVE('Employee_Changes')

|위의 예는 기본 규정을 사용하는 Employee_Changes 서비스가 정의한 대기행렬의 |헤드에서 메시지를 제거하는 방법을 보여줍니다.

|DB2의 강력한 기능 중 하나는 사용자 정의(또는 DB2 제공) 함수에서 테이블을 |생성하는 기능입니다. 이 테이블 함수 기능을 이용하여 대기행렬의 내용을 |DB2 테이블로 구체화할 수 있습니다. 다음은 이를 보여주는 간단한 예입니다.

|예 10:

|SELECT t.* FROM table ( DB2MQ.MQREADALL()) t 

|이 조회는 이 메시지에 대한 메타데이터 및 기본 서비스에서 정의한 |대기행렬의 모든 메시지로 구성된 테이블을 리턴합니다. |리턴된 테이블 구조의 전체 정의는 부록에 정의되어 있지만 |첫 컬럼은 메시지 내용을 반영하며 나머지 컬럼에는 메타데이터가 포함됩니다. |메시지만 리턴하려면 위의 예를 다음과 같이 바꿀 수 있습니다.

|예 11:

|SELECT t.MSG FROM table (DB2MQ.MQREADALL()) t

|테이블 함수가 리턴한 테이블은 데이터베이스에서 직접 검색한 |테이블과 다르지 않습니다. |따라서 다양한 방법으로 이 테이블을 사용할 수 있습니다. |예를 들어, 테이블 내용을 다른 테이블과 조인하거나 대기행렬의 메시지 수를 |셀 수 있습니다.

|예 12:

|SELECT t.MSG, e.LASTNAME 
|   FROM table (DB2MQ.MQREADALL() ) t, EMPLOYEE e 
|      WHERE t.MSG = e.LASTNAME

|예 13:

|SELECT COUNT(*) FROM table (DB2MQ.MQREADALL()) t

|테이블 함수에 대한 뷰를 작성하여 테이블 소스가 대기행렬이라는 것을 숨길 수도 있습니다. |예를 들어, 다음 예에서는 NEW_EMPLOYEES 서비스가 참조하는 대기행렬에 대해 |NEW_EMP라는 뷰를 작성합니다.

|예 14:

|CREATE VIEW NEW_EMP (msg) AS
|   SELECT t.msg FROM table (DB2MQ.MQREADALL()) t

|이 경우 뷰는 전체 메시지를 포함하는 단일 컬럼과 함께 정의됩니다. |고정된 길이의 두 필드가 포함된 경우와 같이 메시지가 단순하게 구성되면 |메시지를 두 개의 컬럼으로 분석하기 위해 DB2 내장 함수를 사용하는 것이 편합니다. |예를 들어, 특정 대기행렬로 전송되는 메시지에는 항상 18문자의 성과 |그 뒤에 18문자의 이름이 나온다는 것을 알고 있는 경우, 다음과 같이 |별도의 컬럼으로 각 필드를 포함하고 있는 뷰를 정의할 수 있습니다.

|예 15:

|CREATE VIEW NEW_EMP2 AS
|   SELECT left(t.msg,18) AS LNAME, right(t.msg,18) AS FNAME
|   FROM table(DB2MQ.MQREADALL()) t

|DB2 Stored Procedure Builder의 새로운 기능인 MQSeries 지원 마법사를 사용하여 |분리된 메시지 구조를 컬럼으로 맵핑하는 새로운 DB2 테이블 함수 및 뷰를 작성할 수 |있습니다.

|이는 하나 이상의 메시지 내용을 데이터베이스로 저장할 경우에 좋습니다. |메시지 내용을 조작하고 저장하는 SQL의 전체 성능을 사용하여 수행할 수 있습니다. |다음은 가장 간단한 예입니다.

|예 16:

|INSERT INTO MESSAGES 
|   SELECT t.msg FROM table (DB2MQ.MQRECEIVEALL()) t

|하나의 컬럼 VARCHAR(2000)가 있는 MESSAGES 테이블에서 위의 명령문을 사용하면 |기본 서비스 대기행렬의 메시지를 테이블에 삽입합니다. |이 방법을 수정하여 다양한 경우에 사용할 수 있습니다.

|20.5.4 응용프로그램간 연결성

|응용프로그램 통합은 많은 솔루션에서 일반적인 요소입니다. |구입한 응용프로그램을 기존 구조에 통합하거나 새로 개발한 응용프로그램만 |기존 환경에 통합할 경우, 모두 이기종 서브시스템 콜렉션이 전체적으로 |작업할 수 있도록 함께 통합해야 하는 문제에 직면하게 됩니다. |MQSeries는 일반적으로 응용프로그램을 통합하는 필수적인 도구입니다. |대부분의 하드웨어, 소프트웨어 및 언어 환경에서 액세스할 수 있는 MQSeries는 |이기종 응용프로그램 콜렉션을 서로 연결하는 방법을 제공합니다.

|이 섹션에서는 몇 개의 응용프로그램 통합 시나리오와 DB2와 함께 사용하는 방법에 |대해 설명합니다. 주제가 광범위하므로 응용프로그램 통합에 대한 포괄적인 접근은 |이 범위에 포함되지 않습니다. |따라서 요청/응답 통신과 MQSeries Integrator 및 Publish/Subscribe의 두 가지 간단한 |항목에 초점을 맞춥니다.

|20.5.4.1 요청/응답 통신

|요청/응답(R/R) 통신 방법은 하나의 응용프로그램이 다른 응용프로그램의 서비스를 |요청하는 일반적인 방법입니다. |이를 수행하는 한 방법은 리퀘스터가 서비스 제공자에게 수행할 작업을 요청하는 메시지를 |보내는 것입니다. |작업이 완료되면 제공자는 결과(또는 완료 확인만)를 다시 리퀘스터에게 보낼 수 있습니다. |위에서 설명한 기본 메시지 전송 방법 이외에는 |보낸 사람의 요청을 서비스 제공자의 응답과 연결하는 방법이 없습니다. |계속 진행하기 전에 리퀘스터가 응답을 기다리지 않는 경우, 각 응답을 |리퀘스터와 연결하는 메커니즘이 사용되어야 합니다. |개발자가 이러한 메커니즘을 만들 필요 없이 |MQSeries는 교환시 메시지 상관을 허용하는 상관 ID를 제공합니다.

|여러 가지 방법으로 이 메커니즘을 사용할 수 있지만 가장 간단한 방법은 |리퀘스터가 다음과 같은 방법 등을 사용하여 알려진 상관 ID로 |메시지를 표시하는 것입니다.

|예 17:

|DB2MQ.MQSEND ('myRequester','myPolicy','SendStatus:cust1','Req1')

|이 명령문은 요청의 상관 ID를 나타내기 위해 위의 MQSEND 명령문에 마지막 매개변수 Req1을 추가합니다.

|이 특정 요청에 대한 응답을 받으려면 다음과 같이 해당되는 MQRECEIVE문을 사용하여 |이 상관 ID와 일치하는 표시된 서비스가 정의한 첫 메시지를 선택적으로 검색합니다.

|예 18:

|DB2MQ.MQRECEIVE('myReceiver','myPolicy','Req1')

|요청을 서비스하는 응용프로그램이 사용 중이거나 리퀘스터가 응답을 받기 전에 |위의 MQRECEIVE를 실행하면 이 상관 식별자와 일치하는 메시지를 찾을 수 없습니다.

|서비스 요청 및 상관 식별자를 모두 받으려면 다음과 같은 명령문을 사용합니다.

|예 19:

|SELECT msg, correlid FROM table (DB2MQ.MQRECEIVEALL('aServiceProvider','myPolicy',1)) t

|이 명령문은 서비스 aServiceProvider에서 첫 번째 요청의 상관 ID 및 메시지를 리턴합니다.

|일단 서비스가 수행되면 aRequester가 설명하는 대기행렬로 응답 메시지를 보냅니다. |그 동안 서비스 리퀘스터는 다른 작업을 할 수 있습니다. |실제로 설정된 시간 내에 초기 서비스 요청에 대한 응답을 받는다는 보장이 없습니다. |이와 같은 응용프로그램 레벨 시간종료는 개발자가 관리해야 합니다. |리퀘스터는 응답을 발견하기 위해 폴링해야 합니다.

|이러한 시간과 무관한 비동기 처리의 장점은 리퀘스터 및 서비스 제공자가 |서로 완전히 독립적으로 실행할 수 있다는 점입니다. |또한 응용프로그램이 간헐적으로만 연결되는 환경 및 여러 요청이나 응답이 처리되기 전에 |누적되는 배치 위주의 환경에서 사용될 수 있습니다. |이러한 누적은 데이터 웨어하우스나 조작 데이터 저장소를 정기적으로 갱신하는 |데이터 웨어하우스 환경에서 주로 사용됩니다.

|20.5.4.2 Publish/Subscribe

|단순 데이터 publication

|응용프로그램 통합의 또 다른 일반적인 시나리오는 한 응용프로그램이 |다른 응용프로그램에게 이벤트를 통지하는 것입니다. |이는 다른 응용프로그램이 모니터하는 대기행렬로 메시지를 보냄으로써 쉽게 수행할 수 있습니다. |메시지 내용은 사용자 정의 문자열이나 데이터베이스 컬럼으로 구성될 수 있습니다. |단순한 메시지인 경우, 주로 MQSEND 함수를 사용해서 보내야 합니다. |이러한 메시지를 여러 수신자에게 동시에 보내야 할 경우, MQSeries AMI의 |분산 목록 기능을 사용할 수 있습니다.

|분산 목록은 AMI 관리 도구로 정의됩니다. 분산 목록은 개별 서비스 목록으로 구성됩니다. |분산 목록으로 보낸 메시지는 목록에서 정의된 모든 서비스로 전달됩니다. |이는 일부 서비스가 항상 모든 메시지와 관련이 있다는 것을 알고 있을 경우 특히 유용합니다. |다음 예는 분산 목록 interestedParties에 메시지를 보내는 경우입니다.

|예 20:

|DB2MQ.MQSEND('interestedParties','information of general interest');

|특정 서비스를 받아야 하는 메시지를 더 잘 제어해야 할 경우, |Publish/Subscribe 기능이 필요합니다. |Publish/Subscribe 시스템은 일반적으로 여러 subscribers에게 메시지를 받기 위해 |여러 subscribers가 등록할 수 있는 확장 가능한 보안 환경을 제공합니다. |이 기능을 지원하기 위해 MQSeries Integrator 또는 MQSeries Publish/Subscribe 기능과 |함께 MQPublish 인터페이스를 사용할 수 있습니다.

|MQPublish를 사용하여 사용자는 선택적으로 메시지와 연관된 주제를 지정할 수 있습니다. |주제를 사용하여 subscriber는 받을 메시지를 더욱 명확하게 지정할 수 있습니다. |다음과 같은 단계를 수행합니다. |

1. |MQSeries 관리자가 MQSeries Integrator publish/subscribe 기능을 구성합니다.
2. |관심있는 응용프로그램은 MQSI 구성에서 정의한 subscription 지점에 subscribe하여 |선택적으로 관심있는 주제를 지정합니다. |각 subscriber는 관련 주제를 선택하고 MQSeries Integrator V2의 내용에 기초한 |subscription을 이용할 수도 있습니다. |서비스 이름으로 표시된 대기행렬이 subscriber를 정의함에 주의하십시오.
3. |DB2 응용프로그램은 서비스 지점 Weather에 메시지를 발행합니다. |메시지는 weather가 Austin 주제의 경우 Sleet임을 나타내므로 |관심있는 subscribers에게 Austin의 weather가 Sleet임을 통지합니다.
4. |실제로 메시지를 발행하는 메커니즘은 DB2가 제공하는 MQSeries 함수에 의해 |처리됩니다. 메시지는 Weather라는 이름의 서비스를 사용하여 MQSeries Integrator로 보내집니다.
5. |MQSI는 Weather 서비스에서 메시지를 받아 MQSI 구성에서 정의한 처리를 수행하며 |충족시키는 subscriptions를 판별합니다. |그런 다음 MQSI는 메시지를 기준에 맞는 subscriber 대기행렬에 전달합니다.
6. |Weather 서비스에 subscribe하고 Austin에 관심이 있다고 등록한 응용프로그램은 |수신하는 서비스에서 Sleet 메시지를 받습니다. |

|모든 기본값 및 널(NULL) 주제를 사용하여 이 데이터를 발행하려면 |다음 명령문을 사용해야 합니다.

|예 21:

|SELECT DB2MQ.MQPUBLISH(LASTNAME || ' ' || FIRSTNAME || ' ' || DEPARTMENT|| ' ' ||char(AGE)) 
|   FROM EMPLOYEE
|   WHERE DEPARTMENT = '5LGA'

|모든 매개변수를 완벽하게 지정하고 LASTNAME만 포함하도록 메시지를 단순화하면 |명령문은 다음과 같습니다.

|예 22:

|SELECT DB2MQ.MQPUBLISH('HR_INFO_PUB', 'SPECIAL_POLICY', LASTNAME, 
|   'ALL_EMP:5LGA', 'MANAGER') 
|   FROM EMPLOYEE
|   WHERE DEPARTMENT = '5LGA'

|이 명령문은 SPECIAL_POLICY 서비스를 사용하여 메시지를 HR_INFO_PUB publication 서비스에 |발행합니다. |메시지는 보낸 사람이 MANAGER 주제임을 나타냅니다. |주제 문자열은 ':'를 사용하여 연결한 여러 주제를 지정할 수 있음을 보여줍니다. |이 예에서 두 개의 주제를 사용함으로써 subscribers는 ALL_EMP 또는 단지 5LGA에만 등록하여 |이 메시지를 받을 수 있습니다.

|발행된 메시지를 받으려면 먼저 주어진 주제를 포함하는 메시지에 대한 관련 사항을 등록하고 |메시지를 받아야 하는 subscriber 서비스 이름을 표시해야 합니다. |AMI subscriber 서비스는 중개인 서비스 및 받는 사람 서비스를 정의합니다. |중개인 서비스는 subscriber가 publish/subscribe 중개인과 통신하는 방법이며 |받는 사람 서비스는 subscription 요청과 일치하는 메시지를 보낼 위치입니다. |다음 명령문은 ALL_EMP 주제에 대한 관련 사항을 등록합니다.

|예 23:

|DB2MQ.MQSUBSCRIBE('aSubscriber', 'ALL_EMP')

|일단 응용프로그램이 subscribe하면 ALL_EM 주제와 함께 발행된 메시지가 subscriber |서비스에 의해 정의된 받는 사람 서비스로 전달됩니다. |응용프로그램은 동시에 여러 개의 subscriptions를 가질 수 있습니다. |subscription에 맞는 메시지를 받기 위해 표준 메시지 검색 함수를 사용할 수 있습니다. |예를 들어 subscriber 서비스 aSubscriber가 받는 사람 서비스를 |aSubscriberReceiver로 정의하면 다음 명령문은 첫 번째 메시지를 손상시키지 않으면서 |읽습니다.

|예 24:

|DB2MQ.MQREAD('aSubscriberReceiver')

|메시지 및 메시지가 발행될 주제를 파악하기 위해 테이블 함수 중 하나를 사용할 수 있습니다. |다음 명령문은 aSubscriberReceiver에서 처음 다섯 개의 메시지를 받아 |메시지 및 주제를 모두 표시합니다.

|예 25:

|SELECT t.msg, t.topic FROM table (DB2MQ.MQRECEIVEALL('aSubscriberReceiver',5)) t

|주제가 ALL_EMP인 모든 메시지를 읽기 위해 SQL의 기능을 이용하여 다음을 실행할 수 있습니다.

|예 26:

|SELECT t.msg FROM table (DB2MQ.MQREADALL('aSubscriberReceiver')) t 
|   WHERE t.topic = 'ALL_EMP'

|주:

MQRECEIVEALL이 제한조건과 함께 사용되면 ALL_EMP 주제로 |발행된 메시지뿐 아니라 전체 대기행렬이 소비됨에 주의해야 합니다. |이는 제한조건이 적용되기 전에 테이블 함수가 수행되기 때문입니다. |

|특정 주제에 subscribe하는 데 더 이상 관련 사항이 없으면 다음과 같은 |명령문을 사용하여 명시적으로 unsubscribe해야 합니다.

|예 27:

|DB2MQ.MQUNSUBSCRIBE('aSubscriber', 'ALL_EMP')

|일단 이 명령문이 실행되면 publish/subscribe 중개인은 이 subscription과 일치하는 메시지를 |더 이상 배달하지 않습니다.

|자동 publication

|데이터베이스 메시지의 또 다른 중요한 기법은 자동 publication입니다. |DB2의 트리거 기능을 사용하여 트리거 호출의 일부로 메시지를 자동으로 발행할 수 있습니다. |자동 데이터 publication을 위한 다른 방법들도 있지만 트리거에 기반한 접근 방법을 사용하면 |관리자나 개발자가 메시지 내용을 더 자유롭게 구성할 수 있으며 트리거 조치를 |더 융통성 있게 정의할 수 있습니다. |트리거를 사용할 경우에는 빈도 및 실행 비용에 주의해야 합니다. |다음은 MQSeries DB2 함수와 함께 트리거를 사용하는 방법을 보여주는 예입니다.

|아래 예는 새 직원이 고용될 때마다 쉽게 메시지를 발행하는 방법을 보여줍니다. |NEW_EMP에 대한 관심을 등록하고 HR_INFO_PUB 서비스에 subscribe한 사용자나 응용프로그램은 |각각의 새 직원의 날짜, 이름 및 부서를 포함하는 메시지를 받게 됩니다.

|예 28:

|CREATE TRIGGER new_employee AFTER INSERT ON employee REFERENCING NEW AS n
|      FOR EACH ROW MODE DB2SQL
|      VALUES DB2MQ.MQPUBLISH('HR_INFO_PUB&',  'NEW_EMP', 
|      current date || ' ' || LASTNAME || ' ' || DEPARTMENT)