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.7.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.