The Adapter for JMS sends and receives your document to InterChange Server in the form of a payload business object. The Adapter for JMS invokes the payload data handler to handle this business object when it receives or sends a WebSphere Partner Gateway document, as follows:
Therefore, you must create the business object definitions shown in Table 56 to represent the payload business-object structure that the Adapter for JMS expects.
Condition | Business object definition | For more information |
---|---|---|
If you are using None or Backend Integration packaging for your message and your documents do not have attachments |
Payload business object |
Creating the payload business-object structure for JMS. |
If you are using Backend Integration packaging for your document |
Business objects to hold the message header information:
|
Creating JMS header information. |
If the document includes attachments | You must also create additional business objects to represent the attachments. | Creating attachment-related business object definitions |
The structure of the payload business object for the JMS transport protocol depends on the packaging type, as follows:
As discussed in Business object for the document, you must create an attribute for each piece of payload information you need to transfer.
For more information on these steps, see Creating JMS header information.
If you are sending or receiving documents that use Backend Integration packaging over the JMS transport protocol, your request business object needs to contain custom transport-level header information. The Adapter for JMS expects this custom header information to be in its dynamic meta-object.
Figure 24 shows the business-object structure that the Adapter for JMS uses for a request business object representing a WebSphere Partner Gateway document that uses Backend Integration packaging.
Make sure your business-object structure includes a dynamic child meta-object by taking the following steps:
Each of these steps is described in the sections below.
A JMS-properties business object contains JMS properties required for transport-level headings, which are needed by Backend Integration packaging. It can also contain the content-type attribute, which specifies the content-type header to set in the request message, and the content-length attribute, which specifies the length of the message, in bytes. Table 5 describes each of the valid transport-header fields.
To create a JMS-properties business object definition, take the following steps:
All attributes should have an attribute type of String. For JMS messages, the names of transport-header fields use underscores instead of hyphens, as shown in Table 57.
This attribute-level application-specific information must have the following format:
name=JMSproperty;type=string
where JMSproperty is one of the values in the JMS property name column of Table 57.
Transport-header field | JMS property name |
---|---|
x-aux-sender-id | x_aux_sender_id |
x-aux-receiver-id | x_aux_receiver_id |
x-aux-protocol | x_aux_protocol |
x-aux-protocol-version | x_aux_protocol_version |
x-aux-process-type | x_aux_process_type |
x-aux-process-version | x_aux_process_version |
x-aux-create-datetime | x_aux_create_datetime |
x-aux-msg-id | x_aux_msg_id |
x-aux-production | x_aux_production |
x-aux-system-msg-id | x_aux_system_msg_id |
x-aux-payload-root-tag | x_aux_payload_root_tag |
x-aux-process-instance-id | x_aux_process_instance_id |
x-aux-event-status-code | x_aux_event_status_code |
x-aux-third-party-bus-id | x_aux_third_party_bus_id |
x-aux-transport-retry-count | x_aux_transport_retry_count |
content-type | content_type |
content-length | content_length |
In Figure 24, the JMSProps_BusObj business object definition contains attributes for the various transport-level header fields. These attributes all have attribute-level application-specific information to specify the name of the related protocol header. For example, the x_aux_sender_id attribute has the application-specific information set as follows:
name=x_aux_sender_id;type=string
This dynamic meta-object contains a child business object with configuration information for the Adapter for JMS. To create a business object definition for a dynamic meta-object, take the following steps:
For the Adapter for JMS to work with WebSphere Partner Gateway, the business object definition for the dynamic meta-object must include the attribute named JMSProperties, whose attribute type is the business object definition for the JMS-properties business object (see Creating the JMS-properties business object). For example, in Figure 24, the JMSDynMO_BusObj business object definition contains attributes for various configuration properties (not shown) and includes the JMSProperties attribute.
To incorporate the business-object structure into your request business object, you must make the following modifications to your request business object definition:
The attribute type for this attribute is the business object definition for the dynamic meta-object (see Creating the JMS dynamic meta-object).
The cw_mo_conn tag has the following format:
cw_mo_conn=dynamicMetaObjAttr
where dynamicMetaObjAttr is the name of the attribute in the request business object that holds the dynamic meta-object.
For example, in Figure 24, an attribute named JMSDynMO has been added to the request business object definition, HUB_JMSRequest_BusObj. This attribute contains the dynamic meta-object, which is a child business object of type JMSDynMO_BusObj. In addition, the application-specific information of the request business object has been modified to include the following cw_mo_conn tag to identify this dynamic meta-object:
cw_mo_conn=JMSDynMO