|A set of MQSeries functions are provided with DB2 UDB Version 7.2 to |allow SQL statements to include messaging operations. This means that |this support is available to applications written in any supported language, |for example, C, Java, SQL using any of the database interfaces. All |examples shown below are in SQL. This SQL may be used from other |programming languages in all the standard ways. All of the MQSeries |messaging styles described above are supported. For more information |about the MQSeries functions, see the SQL Reference section of the Release |Notes.
|In a basic configuration, an MQSeries server is located on the database |server machine along with DB2. The MQSeries functions are installed |into DB2 and provide access to the MQSeries server. DB2 clients may be |located on any machine accessible to the DB2 server. Multiple clients |can concurrently access the MQSeries functions through the database. |Through the provided functions, DB2 clients may perform messaging operations |within SQL statements. These messaging operations allow DB2 |applications to communicate among themselves or with other MQSeries |applications.
|The enable_MQFunctions command is used to enable a DB2 database |for the MQSeries functions. It will automatically establish a simple |default configuration that client applications may utilize with no further |administrative action. For a description, see 20.6, enable_MQFunctions and 20.7, disable_MQFunctions. The default configuration allows |application programmers a quick way to get started and a simpler interface for |development. Additional functionality may be configured incrementally |as needed.
|Example 1: To send a simple message using the default configuration, |the SQL statement would be:
|VALUES DB2MQ.MQSEND('simple message')
|This will send the message simple message to the MQSeries |queue manager and queue specified by the default configuration.
|The Application Messaging Interface (AMI) of MQSeries provides a clean |separation between messaging actions and the definitions that dictate how |those actions should be carried out. These definitions are kept in an |external repository file and managed using the AMI Administration tool. |This makes AMI applications simple to develop and maintain. The |MQSeries functions provided with DB2 are based on the AMI MQSeries |interface. AMI supports the use of an external configuration file, |called the AMI Repository, to store configuration information. The |default configuration includes an MQSeries AMI Repository configured for use |with DB2.
|Two key concepts in MQSeries AMI, service points and policies, are carried |forward into the DB2 MQSeries functions. A service point is a logical |end-point from which a message may be sent or received. In the AMI |repository, each service point is defined with an MQSeries queue name and |queue manager. Policies define the quality of service options that |should be used for a given messaging operation. Key qualities of |service include message priority and persistence. Default service |points and policy definitions are provided and may be used by developers to |further simplify their applications. Example 1 can be re-written as |follows to explicitly specify the default service point and policy name:
|Example 2:
|VALUES DB2MQ.MQSEND('DB2.DEFAULT.SERVICE', 'DB2.DEFAULT.POLICY', | 'simple message')
|Queues may be serviced by one or more applications at the server upon which |the queues and applications reside. In many configurations multiple |queues will be defined to support different applications and purposes. |For this reason, it is often important to define different service points when |making MQSeries requests. This is demonstrated in the following |example:
|Example 3:
|VALUES DB2MQ.MQSEND('ODS_Input', 'simple message')
|
|MQSeries provides the ability for message operations and database |operations to be combined in a single unit of work as an atomic |transaction. This feature is not initially supported by the MQSeries |Functions on Unix and Windows.
|When using the sending or receiving functions, the maximum length of a |message of type VARCHAR is 4000 characters. The maximum length when |sending or receiving a message of type CLOB is 1 MB. These are also the |maximum message sizes for publishing a message using MQPublish.
|Different functions are sometimes required when working with CLOB messages |and VARCHAR messages. Generally, the CLOB version of an MQ function |uses the identical syntax as its counterpart. The only difference is |that its name has the characters CLOB at the end. For example, the CLOB |equivalent of MQREAD is MQREADCLOB. For a detailed list of these |functions, see 43.6.3, CLOB data now supported in MQSeries functions.
|The return codes returned by the MQSeries Functions can be found in |Appendix B of the MQSeries Application Messaging Interface Manual.