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.
Property name | Application-specific information |
---|---|
Default | OutputQueue=queue://DENALI/ FRONTARENA.OUT? targetClient=1;ResponseTimeout =60000; |
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.
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.
|
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:
|
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.
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.
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.
The processing of business objects with the Delete verb is analogous to the processing of business objects with the Create verb.
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.
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.