The adapter processes business objects passed to it by a collaboration based on the verb for each business object. The adapter uses business object handlers and the doForVerb() method to process the business objects that the adapter supports. The adapter supports the following business object verbs:
Processing of business objects with create, update and delete verbs depends on whether the objects are issued asynchronously or synchronously.
The default delivery mode for business objects with create, update, and delete verbs is asynchronous. 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 adapter returns BON_SUCCESS, else BON_FAIL.
If a replyToQueue has been defined in the connector properties and a ResponseTimeout exists in the conversion properties for the business object, the adapter issues a request in synchronous mode. The adapter then waits for a response to verify that appropriate action was taken by WebSphere Commerce.
The adapter initially issues a message with a header as shown in Table 1.
Table 1. 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 1 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 WebSphere Commerce. The thread that issued the message waits for a response message that indicates whether WebSphere Commerce was able to process the request.
When WebSphere Commerce receives a synchronous request from the adapter, it
processes the data of the business object and issues a report message as
described in Table 2, Table 3, and Table 4.
Table 2. 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 3. 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 4. WebSphere MQ feedback codes and ICS response values
WebSphere MQ feedback code | Equivalent ICS response* |
---|---|
MQFB_PAN or MQFB_APPL_FIRST
|
SUCCESS
|
MQFB_NAN or MQFB_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)
|
MQFB_NONE
|
What the connector receives if no feedback code is specified in the
response message
|
* 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 ICS 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 ICS 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 adapter message and issues it to the queue specified by the replyTo field.
Upon retrieval of a response message, the adapter matches the correlationID of the response to the messageID of a request message. The adapter then notifies the thread that issued the request. Depending on the feedback field of the response, the adapter 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 adapter simply returns the same business object that was originally issued by InterChange Server 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 InterChange Server along with the response code.
You can extend the WebSphere MQ feedback codes to override default interpretations shown in Table 4 by specifying the connector property FeedbackCodeMappingMO. This property allows you to create a meta-object in which all ICS-specific return status values are mapped to the WebSphere MQ feedback codes.
The return status assigned to a feedback code is passed to InterChange Server. For more information, see "FeedbackCodeMappingMO".
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 and retrieve by content verbs, the message body must be populated with a serialized business object to complete the transaction.
Table 5 shows the response messages for these verbs.
Table 5. 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
|
|