Service requests

The adapter transforms all service requests that it receives from a collaboration to FRONT ARENA messages. These messages are forwarded to the bridge component of the adapter. The OutputQueue defined in the static configuration meta-object is used for this purpose. For more information, see Custom business object handler.

The adapter can be set up to handle service requests either synchronously or asynchronously. This is done by either specifying the parameter ResponseTimeout in the static configuration meta-object or omitting it. For more information, see Custom business object handler. If the parameter is set, a ReplyToQueue must be specified in the connector-specific properties of the adapter.

If the adapter is set up to handle service requests asynchronously, a request is considered to be successful if it can be forwarded to the OutputQueue. BON_SUCCESS is returned.

In the synchronous mode, the adapter waits for a reply from the bridge component of the adapter for the period of time specified in ResponseTimeout. If a reply is received within the given time interval, it is passed back to the calling collaboration. Otherwise, a failure is assumed, and a negative response (BON_FAIL is returned to the collaboration.

The bridge component of the adapter can be set up to handle service requests synchronously or asynchronously. The setup of both components must be consistent to make the processing work as expected.

Table 57.

Connector configuration: Connector-specific properties
Property name Description Default
ReplyToQueue The queue in which the adapter expects the replies to service requests sent to the bridge component of the adapter. N/A

Table 58.

Static configuration meta-object: MO_FrontArena_DefaultConfig
Property name Application-specific information
Default OutputQueue=queue://DENALI/ FRONTARENA.OUT? targetClient=1;ResponseTimeout =60000;
Note:
It is essential that the OutputQueue name is followed by ?targetClient=1. This ensures that the messages sent to the bridge component of the adapter have the expected format.

Create

Processing of business objects with the Create verb depends on whether the objects are issued asynchronously or synchronously.

Asynchronous processing: This is the default delivery mode for business objects with Create verbs. A message is created from the business object using the data handler and then written to the OutputQueue specified in the conversion meta-object. For more information, see Custom business object handler. If the message is delivered, the adapter returns BON_SUCCESS, else BON_FAIL.

Note:
With asynchronous processing, the connector has no way of verifying whether the message is received or if action has been taken.

Synchronous processing: 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 the receiving application.

The request message sent to the bridge component of the adapter consists of an MQMD header followed by the message body containing the FRONT ARENA message created from the business object by the data handler.

The MQMD header is initialized based on the information in the following table:

Table 59. Request Message Descriptor Header (MQMD):

Format Description Value
Format The message format. The value of the parameter, InputFormat, in the conversion meta-object attribute belonging to the given <business object name>_<verb> combination. This value can be changed by explicitly setting the corresponding OutputFormat parameter.

Note:
The value of this field is ignored by the bridge component of the adapter.
Message type The message type. MQMT_DIAGRAM
Report Options for the 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 The name of the reply queue. When a response message is expected this field is populated with the value of the connector-specific property ReplyToQueue. The value of this field is ignored by the bridge component of the adapter.
Note: It uses the fixed reply to queue defined in its configuration for passing back the request processing results.
Persistence Message persistence MQPER_PERSISTENT
Expiry Message lifetime MQEI_UNLIMITED

If the business object can be processed, the bridge component of the adapter creates a report message with the feedback field set to MQFB_PAN. Additionally, the application populates the message body with a serialized business object containing the attributes of the object just created.

Note:
The list of attributes in this response message can differ from that in the request message, however, depending on the FRONT ARENA application configuration.

If the business object cannot be processed, a report message with the feedback field set to MQFB_NAN is returned. The message body includes an error message explaining the reason of the failure.

In either case, the application sets the CorrelationID field of the reply message to the MessageID of the request message and issues it to the queue specified by the ReplyToQueue 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 connector either expects a business object or an error message in the message body.

Update

The processing of business objects with the Update verb is analogous to the processing of business objects with the Create verb.

If the request can be processed successfully, the feedback field in the reply message header is set to MQFB_APPL_FIRST + 2 (BON_VALCHANGE) in this case. Again, the message body contains details about the updated object.

Delete

The processing of business objects with the Delete verb is analogous to the processing of business objects with the Create verb.

Retrieve

Business objects with the Retrieve verb support synchronous processing only. Basically, the adapter processes business objects with this verb as it does for the synchronous processing defined for the Create, Update and Delete verbs. Different feedback codes are returned, however.

Exists

This verb is not supported.

Retrieve by content

This verb is not supported. From the FRONT ARENA application perspective, there is no difference between Retrieve and RetrieveByContent.

The following table gives an overview of the feedback codes delivered by the bridge component of the adapter.

Table 60.

FRONT ARENA - Bridge component feedback codes
Result of processing Feedback code Message body
MQFB_PAN BON_SUCCESS Insert, Delete, or Retrieve successful.
MQFB_NAN BON_FAIL Insert, Update, Delete or Retrieve failed. For Retrieve:Failures other than multiple hits and BO do not exist.
MQFB_APPL_FIRST + 2 BON_VALCHANGE The update successful
MQFB_APPL_FIRST + 4 BON_MULTIPLE_ HITS The retrieve found several matching objects.
MQFB_APPL_FIRST + 6 BON_BO_DOES_ NOT_EXIST The retrieve did not find any matching objects.

Copyright IBM Corp. 1997, 2004