Request processing

You use the request processing capability of the connector to enable a collaboration to invoke an HTTP service. You must configure the connector and its request processing components: the protocol handler framework and protocol handlers.

At run time, the connector receives requests from the collaboration in the form of business objects. The business objects-- request, and optionally response and fault business objects-- are contained by the TLO issued by a collaboration that is configured to use HTTP services. The TLO and its child business objects contain attributes and ASI that specify the processing mode (synchronous or asynchronous), the data handler mime type, which protocol handler to use, as well as the address of the target. The protocol handler uses this information to invoke an instance of the data handler, convert the request business object to a request message, and invoke the target HTTP service. If the mode is synchronous, the protocol handler again invokes the data handler to convert the response message into a response business object and returns this to the collaboration.

In response to a request message, the connector can receive any of the following from the remote trading partner:

Protocol handlers play a key role in request processing.

Protocol handling

A collaboration can invoke an HTTP service over HTTP or HTTPS transports. The connector has one protocol handler and corresponding channel: an HTTP-HTTPS protocol handler for invoking HTTP and HTTPS services

The protocol handler framework manages the protocol handler, loading it at startup time. When the connector receives a request business object, the request thread (note that each collaboration request comes in a thread of its own) invokes the protocol handler framework to process the request.

The protocol handler framework reads the TLOs Handler attribute ASI to determine which protocol handler to use. Applying a series of rules (see HTTP-HTTPS protocol handler processing), the protocol handler invokes a data handler to convert the request business object into a request message. The protocol handler packages the request message into the transport--HTTP(S)-- message.

The protocol handler then reads the Destination attribute of the request business object Protocol Config MO to determine the target address. The HTTP Config MO attribute Method will specify the HTTP method to use at runtime. The default method will be POST. The protocol handler then invokes the target HTTP service with the request message.

Reading the ws_mode TLO ASI, the protocol handler determines whether the processing mode is synchronous or asynchronous. If this ASI is set to asynch, the protocol handler processing is completed. Otherwise the protocol handler waits for a response message. If a response message arrives, the protocol handler extracts the protocol headers and the payload. It then invokes the data handler (indicated by the MimeType TLO attribute) to convert the message into a response or fault business object. Again using the Protocol Config MO, the protocol handler sets the protocol headers in the business object. The protocol handler then returns the response or fault business object to the collaboration.

Depending on connector configuration, there may be one or more protocol handlers plugged into the connector. Connector-specific properties allow you to configure protocol handlers.

HTTP-HTTPS protocol handler processing

The HTTP-HTTPS protocol handler performs as described in Protocol handling with exceptions noted in this section. Figure 16 shows the HTTP-HTTPS protocol handler for a synchronous operation.

Figure 16. HTTP-HTTPS protocol handler: synchronous request processing

Figure 17 shows the HTTP-HTTPS protocol handler for an asynchronous request process

Figure 17. HTTP-HTTPS protocol handler: asynchronous request processing

Note:
This section describes HTTP protocol handling only.

The HTTP-HTTPS protocol handler uses the object-level ASI (cw_mo_http) of the request business object to determine the Protocol Config MO. The HTTP-HTTPS protocol handler determines the URL of the target HTTP service by reading the Destination attribute in the HTTP Protocol Config MO. If the URL is missing or is incomplete, the protocol handler fails the service call. For further information on the HTTP Protocol Config MO and its attributes, see HTTP Protocol Config MO for request processing.

The HTTP-HTTPS protocol handler invokes the HTTP service using the request message returned by the data handler. If HTTP Proxy connector configuration properties are specified, the HTTP-HTTPS protocol handler behaves accordingly. If a response is returned, the HTTP-HTTPS protocol handler reads it.

Table 30 summarizes the order of precedence of rules used by the HTTP-HTTPS protocol handler to determine the Charset, MimeType, ContentType, and Content-Type header for outgoing request messages.

Table 30. HTTP-HTTPS protocol handler processing rules for outbound messages
Order of Precedence Charset MimeType ContentType Content-Type header
1 Protocol Config MO's Content-Type Header MimeType property in TLO attribute Protocol Config MO's Content-Type Header Protocol Config MO's Content-Type Header
2 Charset property in TLO attribute Default to ContentType Construct Content-Type Header using ContentType and Charset
3 If the ContentType is text/*, default to ISO-8859-1. Otherwise, charset will not be used.

As shown in Table 30:

Table 32 summarizes the order of precedence for rules used by the handler when determining the Charset, MimeType, ContentType, and Content-Type header for response messages.

Table 32. HTTP(s) protocol handler processing rules for inbound synchronous response message
Order of Precedence Charset MimeType ContentType Content-Type header
1 Incoming HTTP message Content-Type header Message TransformationMap or EmptyResponseRule (if response is empty) child business object in the Request business object's Protocol Config MO Incoming HTTP message Content-Type header Incoming HTTP message Content-Type header
2 Message TransformationMap or EmptyResponseRule (if response is empty) child business object in the Request business object's Protocol Config MO The request message MimeType, but only if the request and response ContentType match.
3 The request message Charset, but only if the request and response ContentType match. MimeType property in TLO
4 Charset property in TLO. Default to ContentType
5 If the Content-Type is text/*, default to ISO-8859-1. Otherwise, Charset is not used.

As shown in Table 32:

The handler processes the HTTP Protocol Config MO. It is the responsibility of the collaboration to ensure that the header values passed in the HTTP Protocol Config MO are correct in the context of the request-response event. The handler populates standard headers and custom properties according to the following rules:

  1. The handler will investigate each item of the HTTP Protocol Config MO in order to ignore special attributes (such as ObjectEventId).
  2. Each non-empty header will be put on the outgoing message and additional processing (for example, the Content-Type header) may take place.
  3. Please note that with the above approach, the handler may set non-standard headers on the message, but will not guarantee that the message is logically or semantically correct.
  4. If there are one or more custom properties in the HTTP Protocol Config MO UserDefinedProperties attribute, the handler will add them in the Entity Headers Section (the last headers section). For more on custom properties, see User-defined properties for request processing.

Note:
Specifying any of the following headers in the HTTP Protocol Config MO is very likely to result in incorrect HTTP messages: Connection, Trailer, Transfer-Encoding, Content-Encoding, Content-Length, Content-MD5, Content-Range.

Copyright IBM Corporation 2003, 2005. All Rights Reserved.