Application-to-application connectivity

You typically use application-to-application connectivity to solve the problem of putting together a diverse set of application subsystems.

To facilitate application integration, WebSphere® MQ® provides the means to interconnect applications. One common scenario is called request-and-reply communication.

The request-and-reply method enables one application to request the services of another application. One way to do this is for the requester to send a message to the service provider to request that some work be performed. When the provider completes the work, the provider might decide to send results, or just a confirmation of completion, back to the requester. Unless the requester waits for a reply before continuing, WebSphere MQ must provide a way to associate the reply with its request.

WebSphere MQ provides a correlation identifier to correlate messages in an exchange between a requester and a provider. The requester marks a message with a known correlation identifier. The provider marks its reply with the same correlation identifier. To retrieve the associated reply, the requester provides that correlation identifier when receiving messages from the queue. The provider returns the first message with a matching correlation identifier to the requester.

Examples that use the DB2MQ1C schema

The following examples use the DB2MQ1C schema for single-phase commit.

The following SQL SELECT statement sends a message consisting of the string

Msg
with corr id

to the service, MYSERVICE. The application uses the policy MYPOLICY with a correlation identifier CORRID1:


SELECT DB2MQ1C.MQSEND ('MYSERVICE', 'MYPOLICY', 'Msg with corr id', 'CORRID1') 
  FROM SYSIBM.SYSDUMMY1;
COMMIT;

You invoke the MQSEND function once because SYSIBM.SYSDUMMY1 has only one row. Because this MQSEND uses the DB2MQ1C schema, which is the single-phase commit UDF, the message is part of the DB2® transaction.

The following SQL SELECT statement receives the first message that matches the identifier CORRID1. The application receives the message from the queue that is specified by the service MYSERVICE and uses the policy MYPOLICY:


SELECT DB2MQ1C.MQRECEIVE ('MYSERVICE', 'MYPOLICY', 'CORRID1') 
  FROM SYSIBM.SYSDUMMY1;

The SELECT statement returns a VARCHAR(32000) string. If no messages are available with this correlation identifier, the result of the statement is a null value, and the queue does not change.

You can use WebSphere MQ user-defined functions to pass only XML messages between DB2® and the various WebSphere MQ implementations. You enable the WebSphere MQ XML functions in the following way:

enable_MQFunctions -n dbName -u uID -p password -v 0pc -xml [xmlSize]

WebSphere MQ XML functions

The following table is a brief description of some of the WebSphere MQ XML functions. These functions have a DB2MQ database schema. They are not under MQ user-defined functional transactional control. To make these MQ XML functions available, you must use the -xml parameter when you issue the enable_MQFunctions command.

Table 1. WebSphere MQ XML functions
WebSphere MQ XML functions	Description
DB2XML.MQPublishXML	Publish XML data in the queue.
DB2XML.MQReadXML	A nondestructive read of matching XML message(s) from the queue.
DB2XML.MQReadAllXML	A nondestructive read of all XML messages from the queue.
DB2XML.MQReceiveXML	A nondestructive receive of matching XML message(s) from the queue.
DB2XML.MQReceiveAllXML	A nondestructive receive of all XML messages from the queue.
DB2XML.MQSendXML	Send an XML message to the queue.