Verb processing

The connector processes business objects passed to it by an integration broker based on the verb for each business object. The connector uses business object handlers to process the business objects that the connector supports. The connector supports the following business object verbs:

Note:
Business objects with Create, Update, and Delete verbs can be issued either asynchronously or synchronously. The default mode is asynchronous. The connector does not support asynchronous delivery for business objects with the Retrieve, Exists, or Retrieve by Content verbs, Accordingly, for Retrieve, Exists, or Retrieve by Content verbs, the default mode is synchronous.

Create, update, and delete

Processing of business objects with create, update and delete verbs depends on whether the objects are issued asynchronously or synchronously.

Asynchronous delivery

This is the default delivery mode for business objects with Create, Update, and Delete verbs. A message is created from the business object using a data handler and then written to the output queue. If the message is delivered, the connector returns BON_SUCCESS, else BON_FAIL.

Note:
The connector has no way of verifying whether the message is received or if action has been taken.

Synchronous delivery

If a replyToQueue has been defined in the connector properties and a responseTimeout exists in the conversion properties for the business object, the connector issues a request in synchronous mode. The connector then waits for a response to verify that appropriate action was taken by the receiving application.

For FIX, the connector initially issues a message with a header as shown in Table 3.

Table 3. Request message descriptor header (MQMD)

Field Description Value
Format Format name Output format as defined in the conversion properties and truncated to 8 characters to meet IBM requirements (example: MQSTR)
MessageType Message Type MQMT_DATAGRAM*
Report Options for report message requested. When a response message is expected, this field is populated as follows:MQRO_PAN* to indicate that a positive-action report is required if processing is successful.MQRO_NAN* to indicate that a negative-action report is required if processing fails.MQRO_COPY_MSG_ID_TO_CORREL_ID* to indicate that the correlation ID of the report generated should equal the message ID of the request originally issued.
ReplyToQueue Name of reply queue When a response message is expected this field is populated with the value of connector property ReplyToQueue.
Persistence Message persistence
MQPER_PERSISTENT*
 
Expiry Message lifetime
MQEI_UNLIMITED*
 
* Indicates constant defined by IBM.

The message header described in Table 3 is followed by the message body. The message body is a business object that has been serialized using the data handler.

The Report field is set to indicate that both positive and negative action reports are expected from the receiving application. The thread that issued the message waits for a response message that indicates whether the receiving application was able to process the request.

When an application receives a synchronous request from the connector, it processes the business object and issues a report message as described in Table 4, Table 5, and Table 6.

Table 4. Response message descriptor header (MQMD)

Field Description Value
Format Format name Input format of busObj as defined in the conversion properties.
MessageType Message Type
MQMT_REPORT*
 
*Indicates constant defined by IBM.

Table 5. Population of response message

Verb Feedback field Message body
Create, Update, or Delete SUCCESS VALCHANGE (Optional) A serialized business object reflecting changes.

VALDUPES FAIL (Optional) An error message.

Table 6. FIX Feedback codes and IBM WebSphere Interchange Server response values

WebSphere MQ feedback code Equivalent IBM WebSphere Interchange Server response*
MQFB_PAN orMQFB_APPL_FIRST SUCCESS
MQFB_NAN orMQFB_APPL_FIRST + 1 FAIL
MQFB_APPL_FIRST + 2
 
VALCHANGE
MQFB_APPL_FIRST + 3
 
VALDUPES
MQFB_APPL_FIRST + 4
 
MULTIPLE_HITS
MQFB_APPL_FIRST + 5
 
FAIL_RETRIEVE_BY_CONTENT
MQFB_APPL_FIRST + 6
 
BO_DOES_NOT_EXIST
MQFB_APPL_FIRST + 7
 
UNABLE_TO_LOGIN
MQFB_APPL_FIRST + 8
 
APP_RESPONSE_TIMEOUT (results in immediate termination of connector)
*See the Connector Development Guide for details.

If the business object can be processed, the application creates a report message with the feedback field set to MQFB_PAN (or a specific IBM CrossWorlds value). Optionally the application populates the message body with a serialized business object containing any changes. If the business object cannot be processed, the application creates a report message with the feedback field set to MQFB_NAN (or a specific IBM CrossWorlds value) and then optionally includes an error message in the message body. In either case, the application sets the correlationID field of the message to the messageID of the connector message and issues it to the queue specified by the replyTo field.

Upon retrieval of a response message, the connector matches the correlationID of the response to the messageID of a request message. The connector then notifies the thread that issued the request. Depending on the feedback field of the response, the connector either expects a business object or an error message in the message body. If a business object was expected but the message body is not populated, the connector simply returns the same business object that was originally issued by the integration broker for the Request operation. If an error message was expected but the message body is not populated, a generic error message will be returned to the integration broker along with the response code.

Retrieve, exists and retrieve by content

Business objects with the Retrieve, Exists, and Retrieve By Content verbs support synchronous delivery only. The connector processes business objects with these verbs as it does for the synchronous delivery defined for create, update and delete. However, when using Retrieve, Exists, and Retrieve By Content verbs, the responseTimeout and replyToQueue are required. Furthermore, for Retrieve By Content and Retrieve verbs, the message body must be populated with a serialized business object to complete the transaction.

Table 7 shows the response messages for these verbs.

Table 7. Population of response message

Verb Feedback field Message body
Retrieve or RetrieveByContent FAIL FAIL_RETRIEVE_BY_CONTENT (Optional) An error message.

MULTIPLE_HITS SUCCESS A serialized business object.
Exist FAIL (Optional) An error message.

SUCCESS

Copyright IBM Corp. 1997, 2003