The connector can process the following business object:
For event processing the connector allows two kinds of TLOs--synchronous and asynchronous. This section discusses synchronous event processing TLOs.
Figure 4 shows the business object hierarchy for synchronous event processing. Request and response objects are required, fault objects are optional.
Figure 4. Business object hierarchy for synchronous event processing
The TLO contains object-level ASI as well as attributes with attribute-level ASI. Both kinds of ASI are discussed below.
Object-level ASI provides fundamental information about the nature of a TLO and the objects it contains. Figure 5 shows the object-level ASI for SERVICE_SYNCH_OrderStatus, a sample TLO for synchronous event processing.
Figure 5. Top-level business object for synchronous event processing
Table 4 below describes the object-level ASI for a synchronous event
processing TLO.
Table 4. Synchronous event processing TLO object ASI
Object-level ASI | Description |
---|---|
ws_eventtlo=true |
If this ASI property is set to true, the connector treats this
object as a TLO enabled for event processing.
|
ws_collab=collabname |
This ASI tells the connector which collaboration to invoke. Its
value is the name of the collaboration. In the sample shown inFigure 5, the collaboration name is SERVICE_SYNCH_OrderStatus_Collab)
|
ws_verb=verb |
Before delivering the TLO to the collaboration, the connector uses this ASI
to set the verb on the TLO. In the sample shown inFigure 5, the verb is Retrieve.
|
ws_mode=synch |
During event notification, the connector uses this ASI property to determine whether to invoke the collaboration synchronously (synch) or asynchronously (asynch). For synchronous processing, this ASI must be set to synch. The default is asynch.
|
Each synchronous event processing TLO has attributes and attribute-level ASI. Figure 6 shows the attributes of SERVICE_SYNCH_OrderStatus, a sample TLO. It also shows the attribute-level ASI in the App Spec Info column.
Figure 6. TLO attributes for synchronous event processing
Table 5 summarizes the attribute-level ASI for the request,
response, fault, MimeType, and Charset attributes of an synchronous event
processing TLO.
Table 5. Synchronous event processing TLO attribute ASI
TLO attribute | Attribute-level ASI | Description |
---|---|---|
MimeType |
| Optional attribute; if specified, its value is used as the mime type of the data handler to invoke for the synchronous response. |
Charset |
| This optional parameter of type String specifies the charset to be set on the data handler when transforming an outgoing business object to the message. NOTE: the charset value specified in this attribute will not be propagated in the Content-Type protocol header of the response message. |
Request
| ws_botype=request |
This attribute corresponds to an HTTP service request. The connector uses its ASI to determine whether this TLO attribute is of type request BO. This ASI, not the attribute name, determines the attribute type. If there is more than one request attribute, the connector uses the ASI of the first one. This attribute is required for synchronous event processing TLOs.
|
Response
| ws_botype=response |
This attribute corresponds to the response returned by an HTTP service. The connector uses this ASI to determine whether this TLO attribute is of type response BO. This ASI, not the attribute name, determines the attribute type. If there is more than one response attribute, the connector uses the ASI of the first one. This attribute is required for synchronous event processing TLOs.
|
Fault | ws_botype=fault
ws_botype=defaultfault |
This attribute, optional for synchronous event processing, corresponds to a
fault message returned by a collaboration when it cannot successfully populate
a response. The connector uses this ASI, not the attribute name, to
determine if the attribute is of type Fault BO.If
|
A request business object is a child of a TLO and is required for synchronous event processing. A request business object has object-level ASI. The object-level ASI for a request business object for synchronous event processing is described in Table 6.. You can specify a default verb for the request business object. You do so by specifying:
DefaultVerb=true;
in the ASI field for the verb in the Supported Verbs list at the
top-level of the request business object. If DefaultVerb ASI
is not specified and the data handler processes a business object with no verb
set, the business object is returned without a verb.
Table 6. Synchronous event processing: object-level ASI for request business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. The ASI designates the HTTP or HTTPS protocol listener. Both the ASI and the Protocol Config MO are optional. For further information, see Protocol Config MO. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
ws_tloname=tloname | This ASI specifies the name of the TLO that this object belongs to. During event processing, the connector uses this ASI to determine whether the request business object delivered by the data handler is a child of the TLO. If so, the connector creates the specified TLO, sets the request business object as its child, and uses the TLOs object-level ASI to deliver it to the subscribing collaboration. |
A response business object is a child of a TLO and is required for
synchronous event processing. The object-level ASI for a response
business object for synchronous event processing is described in Table 7.
Table 7. Synchronous event processing: object-level ASI for response business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. The ASI designates the HTTP or HTTPS protocol listener. Both the ASI and the Protocol Config MO are optional. For further information, see Protocol Config MO. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
A fault business object is a child of a TLO and is optional for synchronous
event processing. The object-level ASI for a fault business object for
synchronous event processing is described in Table 8..
Table 8. Synchronous event processing: object-level ASI for fault business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. The ASI designates the HTTP or HTTPS protocol listener. Both the ASI and the Protocol Config MO are optional. For further information, see Protocol Config MO. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
The Protocol Config MO is optionally included as a child of the request, response, or fault business objects for event processing. Typically you specify it when you need to read (from request messages) or propagate (to response or fault messages) the protocol headers and custom properties. As noted above, the request business object optionally declares the name of the Protocol Config MO as business-object-level ASI:
During event processing, the connector uses protocol listeners (HTTP or HTTPS) to retrieve events from the transport. These events are messages from internal or external clients requesting service from collaborations. Each transport has its own header requirements. The connector uses the Protocol Config MO to convey the protocol-specific header information from the protocol listener to the collaboration. The Protocol Config MO attributes correspond to headers in the inbound message. The connector sets the value of these attributes in the business object using inbound message content.
For HTTP(S) protocol, the Protocol Config MO attributes are as
follows:
Table 9. HTTP/HTTPS Protocol Config MO Attributes for event processing
Attribute | Required | Type | Description |
---|---|---|---|
Content-Type | No | String | The value of this attribute defines the Content-Type header of the outgoing message (which includes message ContentType and 0 or more parameters --the charset-- for the outgoing message). The syntax is the same as that for the Content-Type header in the HTTP Protocol, for example: text/xml; charset=ISO-8859-4. If there is no Content-Type attribute defined, the connector uses the ContentType of the request as the ContentType of the response/fault message. |
UserDefinedProperties | No | Business object | This attribute holds the user-defined protocol properties business object. |
One or more HTTP headers | No | String | This attribute allows the handler to pass or retrieve the value for the specified HTTP header. |
Authorization_UserId | No | String | This attribute corresponds to the userID of the HTTP basic authentication. |
Authorization_Password | No | String | This attribute corresponds to the password of the HTTP basic authentication |
These attributes are described in:
For further information on protocol listeners, see Protocol listeners.(For information describing the Protocol Config MO for request processing, see Synchronous request processing TLOs).
You can optionally specify custom properties in the HTTP(S) Protocol Config MO. You do so by including the UserDefinedProperties attribute. This attribute corresponds to a business object that has one or more child attributes with property values. Every attribute in this business object must define a single property to be read (or, for synchronous responses, written) in the variable portion of the message header as follows:
Table 10summarizes the application-specific information for these
attributes.
Name | Value | Description |
---|---|---|
ws_prop_name (case-insensitive; if not specified the attribute name will be used as the property name | Any valid protocol property name | This is the name of the protocol property. Some vendors reserve certain properties to provide extended functionality. |
If the given custom property ASI (the ws_prop_name) is invalid and there is no logical way to process this header, the connector logs a warning and ignores this property. If the value of the custom property can neither be set nor retrieved after the necessary check against ws_prop_name has been performed, the connector logs the error and fails the event.
If the UserDefinedProperties attribute is specified, the connector will create an instance of a UserDefinedProperties business object. The connector then attempts to extract property values from the message and store them in the business object. If at least one property value is successfully retrieved, the connector will set a modified UserDefinedProperties attribute in the Protocol Config MO.
For synchronous event processing, if a UserDefinedProperties attribute is specified and its business object is instantiated, the connector will process each attribute of this child business object and set the message property value accordingly.
For the purpose of credential propagation, the connector supports the Authorization_UserId and Authorization_Password attributes in the HTTP Protocol Config MO. The support is limited to the propagation of these credentials as part of the HTTP Basic authentication scheme.
If an HTTP or HTTPS protocol listener processes an HTTP service request that includes an authorization header, the listener will parse the header to determine whether it conforms to HTTP Basic authentication. If so, the listener extracts and decodes (using Base64) the username and password. This decoded string consists of a username and password separated by a colon. If the protocol listener finds the Authorization_UserId and Authorization_Password attributes in the Protocol Config MO, the listener sets these values with those extracted from the event authorization header.
Figure 7 shows the business object hierarchy for asynchronous event processing. A request object only is required.
Figure 7. Business object hierarchy for asynchronous event processing
The TLO contains object-level ASI as well as attributes with attribute-level ASI. Both kinds of ASI are discussed below.
Object-level ASI provides fundamental information about the nature of a TLO and the objects it contains. Figure 8 shows the object-level ASI for SERVICE_ASYNCH_TLO_Order, a sample TLO for asynchronous event processing.
Figure 8. Top-level business object for asynchronous event processing
Table 4 below describes the object-level ASI for an asynchronous
event processing TLO.
Table 11. Asynchronous event processing TLO object ASI
Object-level ASI | Description |
---|---|
ws_eventtlo=true |
If this ASI property is set to true, the connector treats this
object as a TLO for event processing.
|
ws_verb=verb |
Before delivering the TLO to the collaboration, the connector uses this ASI
to set the verb on the TLO. In the sample shown inFigure 8, the verb is Create.
|
ws_mode=asynch |
During event notification, the connector uses this ASI property to determine whether to invoke the collaboration synchronously (synch) or asynchronously (asynch). For asynchronous processing, this ASI must be set to asynch. The default is asynch.
|
Each asynchronous event processing TLO has a single attribute that corresponds to a request business object. Figure 9 shows the request attribute of SERVICE_ASYNCH_TLO_Order, a sample TLO, and the attribute's ASI.
Figure 9. TLO attribute for asynchronous event processing
Table 12 summarizes the attribute-level ASI for the request attribute
of an asynchronous event processing TLO.
Table 12. Asynchronous event processing TLO attribute ASI
TLO attribute | Attribute-level ASI | Description |
---|---|---|
Request
| ws_botype=request |
This attribute corresponds to a request. The connector uses its ASI to determine whether this TLO attribute is of type request BO. This ASI, not the attribute name, determines the attribute type. If there is more than one request attribute, the connector uses the ASI of the first one. This attribute is required for synchronous event processing TLOs.
|
A request business object is a child of a TLO and is required for asynchronous event processing. You can specify a default verb for the request business object. You do so by specifying:
DefaultVerb=true;
in the ASI field for the verb in the Supported Verbs list at the
top-level of the Request business object. If DefaultVerb ASI
is not specified and the data handler processes a business object with no verb
set, the business object is returned without a verb. The object-level
ASI for a Request business object for asynchronous event processing is
described in Table 13.
Table 13. Asynchronous event processing: object-level ASI for Request business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. The ASI designates the HTTP or HTTPS protocol listener. Both the ASI and the Protocol Config MO are optional. For further information, see Protocol Config MO. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
ws_tloname=tloname | This ASI specifies the name of the TLO that this object belongs to. During event processing, the connector uses this ASI to determine whether the request business object delivered by the data handler is a child of the TLO. If so, the connector creates the specified TLO, sets the request business object as its child, and uses the TLOs object-level ASI to deliver it to the subscribing collaboration. |
For request processing the connector allows two kinds of TLOs--synchronous and asynchronous. This section discusses synchronous request processing TLOs.
Figure 10 shows the TLO business object hierarchy for synchronous request processing. Request, response, and handler objects are required, fault objects are optional. Unlike event processing, a Protocol Config MO is required for the request objects, and optional for the response and fault objects.
Figure 10. Business object hierarchy for synchronous request processing
Object-level ASI provides important information about the nature of a TLO and the objects it contains. Figure 11 shows CLIENT_SYNCH_TLO_OrderStatus, a sample TLO for synchronous request processing.
Figure 11. Top-level business object for synchronous request processing
Table 14 describes the object-level ASI for a synchronous request
processing TLO. Unlike the ASI for synchronous event processing TLOs,
no ws_collab, ws_verb or ws_eventtlo ASI is
required at this level for request processing.
Table 14. Synchronous request processing TLO object ASI
Object-level ASI | Description |
---|---|
ws_mode=synch |
During request processing, the connector uses this ASI property to determine whether to invoke the HTTP service synchronously (synch) or asynchronously (asynch). If synch is indicated, then the connector expects a response, and the TLO must include request and response business objects and, optionally, one or more fault objects. The default is asynch.
|
Table 15 describes the attributes and ASI for synchronous request
processing TLOs.
Table 15. Request processing TLO attributes
TLO attribute | Attribute-level ASI | Description |
---|---|---|
MimeType | None |
This attribute specifies the mime type of the data handler that the
connector invokes for transforming a Request business object into a request
message. This value may be used for transforming synchronous
response/fault messages into business objects, depending on the Message
Transformation Rules configuration.
|
BOPrefix | None | This attribute of type String is passed to the data handler. |
Handler | None | This attribute specifies the protocol handler to use to process the request and is for request processing only. It takes the valuehttp, which designates the HTTP- HTTPS protocol handler. The default is http |
Charset |
| This optional parameter of type String specifies the charset to be set on the data handler when transforming the Request business object to a message. NOTE: the charset value specified in this attribute will not be propagated in the Content-Type protocol header of the request message. |
Request
| ws_botype=request |
This attribute corresponds to a request business object. The
connector uses this attribute ASI to determine whether this TLO attribute is
of type request BO. This ASI, not the attribute name, determines the
attribute type. If there is more than one request attribute, the
connector uses the ASI of the first populated attribute.
|
Response
| ws_botype=response |
This attribute corresponds to the response returned to a collaboration and
is required for synchronous request processing. The connector uses this
attribute ASI to determine whether this TLO attribute is of type response
BO. This ASI, not the attribute name, determines the attribute
type.
|
Fault
| ws_botype=fault
or ws_botype=defaultfault | This attribute, optional for synchronous request processing, corresponds
to a fault message returned by an HTTP service when it cannot successfully
populate a response.
The connector uses this ASI to determine if the attribute of TLO is of type fault BO. This ASI, not the attribute name, determines the attribute type. A defaultfault business object is returned if the fault message is a detail element. defaultfault is used in default business object resolution. |
A request business object is a child of a TLO and is required for synchronous request processing. A request business object has object-level ASI.
Table 16 describes the object-level ASI for a request business object for synchronous request processing.
Table 16. Synchronous request processing: object-level ASI for request business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this optional ASI must match the name of the attribute that corresponds to the Protocol Config MO. This Protocol Config MO specifies the destination for the HTTP-HTTPS protocol handler. This ASI is used by the HTTP-HTTPS Protocol Handler. Note that the TLO request attribute must have an HTTP Protocol Config MO for request processing. For further information, see HTTP Protocol Config MO for request processing. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted.The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
A response business object is a child of a TLO and is required for
synchronous request processing. The object-level ASI for a response
business object for synchronous request processing is described in Table 17.
Table 17. Synchronous request processing: object-level ASI for response business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. This Protocol Config MO, optional for a response business object, specifies the headers in the response message for the HTTP(s) protocol handler. For further information, see HTTP Protocol Config MO for request processing. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
You can specify a default verb for the response business object. You do so by specifying:
DefaultVerb=true;
in the ASI field for the verb in the Supported Verbs list at the top-level of the Response business object. If DefaultVerb ASI is not specified and the data handler processes a business object with no verb set, the response business object is returned without a verb.
A fault business object is a child of a TLO and is optional for synchronous
request processing. The object-level ASI for a fault business object
for synchronous request processing is described in Table 8.
Table 18. Synchronous request processing: object-level ASI for Fault business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. This Protocol Config MO, optional for a fault business object, specifies the headers in the response message for the HTTP-HTTPS protocol handler. For further information, see Protocol Config MO. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
During request processing, the HTTP-HTTPS protocol handlers use the HTTP
Protocol Config MO to determine the destination of the target HTTP
service. This Protocol Config MO is required for a request business
object. The HTTP-HTTPS protocol handlers support HTTP 1.0 POST
request only. As shown in Table 19 the sole required attribute (Destination) is the full URL of
the target HTTP service. The optional authorization attributes are
described in the sections below.
Table 19. HTTP Protocol Config MO Attributes for Request Processing
Attribute | Required | Type | Description |
---|---|---|---|
Destination | Yes | String | The destination URL of the target HTTP service. The HTTP-HTTPS protocol handler uses this attribute to determine the destination of the HTTP service. |
Content-Type | Required for the Request business object, otherwise optional. | String | The value of this attribute defines the Content-Type header of the outgoing message (which includes message ContentType and optionally charset for the outgoing message). The syntax is the same as that for the Content-Type header in the HTTP Protocol, for example: text/xml; charset=ISO-8859-4. |
Authorization_UserId | No | String | This attribute corresponds to the userID of the HTTP basic authentication. For further information, see HTTP credential propagation for request processing |
Authorization_Password | No | String | This attribute corresponds to the password of the HTTP basic authentication. For further information, see HTTP credential propagation for request processing |
One or more HTTP headers | No | String | This attribute allows the handler to pass or retrieve the value for the specified HTTP header. |
UserDefinedProperties | No | Business object | This attribute holds the user-defined protocol properties business object. For further information, see User-defined properties for request processing. |
MessageTransformationMap | No | Single cardinality business object | This is the attribute that points to business object holding 0 or more message transformation rules. The rules hold information regarding the mime type and charset to apply to the incoming message that is specified in the rule. For further information, see Message transformation maps. |
The HTTP Protocol Config MO attributes are described in:
You can optionally specify custom properties in the HTTP Protocol Config MO. You do so by including the UserDefinedProperties attribute. This attribute corresponds to a business object that has one or more child attributes with property values. Every attribute in this business object must define a single property to be read (or, for synchronous responses, written) in the variable portion of the message header as follows:
Table 20 summarizes the application-specific information for these
attributes.
Name | Value | Description |
---|---|---|
ws_prop_name (case-insensitive; if not specified the attribute name will be used as the property name | Any valid protocol property name | This is the name of the protocol property. Some vendors reserve certain properties to provide extended functionality. |
If the given custom property ASI (the ws_prop_name) is invalid and there is no logical way to process this header, the connector logs a warning and ignores this property. If the value of the custom property can neither be set nor retrieved after the necessary check against ws_prop_name has been performed, the connector logs the error and fails the event.
If the UserDefinedProperties attribute is specified and its business object is instantiated, the connector processes each attribute of this child business object and sets the message properties values accordingly.
For synchronous request processing, upon receipt of a response message, if the UserDefinedProperties attribute is specified, the connector creates an instance of a UserDefinedProperties business object and attempts to extract property values from the message and then stores them in the new business object. If at least one property value was successfully retrieved, the connector will set modified UserDefinedProperties business object in the Protocol Config MO.
The Message Transformation Map (MTM) feature is supported for request processing HTTP(S) protocol handlers only. MessageTransformationMap is an optional attribute in the Protocol Config MO that points to a business object. The business object contains rules for transforming messages with mime types and charsets that are specified in the rules. If it finds the (case-sensitive) attribute name MessageTransformationMap and this attribute is of the business object type, the connector uses the rules in that object to transform a message.
The MTM attribute must have one cardinality N child business object attribute that is named TransformationRule. When trying to find TransformationRule for a message, the HTTP-HTTPS Protocol Handler first attempts to match the message exactly by the ContentType specified in all TransFormationRules. If unsuccessful, the connector attempts to find the rule that applies to multiple types of messages. For further information on protocol handler processing, see HTTP-HTTPS protocol handler processing.
Each instance of a TransformationRule business object must have attributes
specified as shown in Table 21.
Table 21. TransformationRule attributes for MessageTransformationMaps in HTTP Protocol Config MO
Attribute name | Required | Type | Default value | Description |
---|---|---|---|---|
TransformationRule | No | Business object, cardinality N |
| This is the attribute that holds 1 rule for message transformation. There can be 0 or more instances of this attribute under the MessageTranformationMap attribute. |
+ContentType | Yes | String | */* | The value of this property specifies the HTTP ContentType of the message for which this transformation rule applies. The default value */* for this attribute enables the connector to apply this rule to any ContentType. For further information on protocol handler processing, see HTTP-HTTPS protocol handler processing. Note that if the Protocol Handler finds more than one rule that has the same ContentType as the other rule, Protocol Handler will log the warning and ignore all duplicate rules, but will use unique rules |
+MimeType | No |
|
| The mime type to use when calling a data handler while processing messages of the ContentType specified in this business object. |
+Charset | No |
|
| The charset to use when transforming a request of the ContentType specified in this business object. |
For the purpose of credential propagation, the connector supports the Authorization_UserId and Authorization_Password attributes in the HTTP Protocol Config MO. The support is limited to the propagation of these credentials as part of the HTTP Basic authentication scheme.
The collaboration sets the values of the Authorization_UserId and Authorization_Password attributes in the Protocol Config MO. If these attributes are neither null nor empty, the connector creates an authorization header on the request its sends to the to the target HTTP service. The HTTP/HTTPS protocol handler follows HTTP Authentication: Basic and Digest Access Authentication (RFC 2617) when creating the authorization header.
Figure 12 shows the business object hierarchy for asynchronous request processing. A request and handler object are required. The request object contains a Protocol Config MO for the HTTP-HTTPS protocol handler. These are described in the sections below.
Figure 12. Business object hierarchy for asynchronous request processing
The TLO contains object-level ASI as well as attributes with attribute-level ASI. Both kinds of ASI are discussed below.
Figure 13 shows CLIENT_ASYNCH_Order_TLO, a sample TLO for asynchronous request processing.
Figure 13. Top-level business object for asynchronous request processing
Table 22 below describes the object-level ASI for an asynchronous
request processing TLO.
Table 22. Asynchronous request processing TLO object ASI
Object-level ASI | Description |
---|---|
ws_mode=asynch |
During request processing, the connector uses this ASI property to determine whether to invoke the collaboration synchronously (synch) or asynchronously (asynch). For asynchronous request processing, this ASI must be set to asynch. The default is asynch.
|
Table 23 summarizes the attribute-level ASI for the request attribute
of an asynchronous request processing TLO.
Table 23. Asynchronous request processing TLO attributes
TLO attribute | Attribute-level ASI | Description |
---|---|---|
MimeType | None |
This attribute specifies the mime type of the data handler that the
connector invokes. Note that this attribute is used only for request
processing only.
|
BOPrefix | None | The value of this attribute is passed to the data handler. |
Handler | None | This attribute specifies the protocol handler to use to process the request and is for request processing only. It takes the value http, which designates the HTTP-HTTPS protocol handler to process the request. The default is http |
Charset |
| This optional parameter of type String specifies the charset to be set on the data handler when transforming the Request business object to a message. NOTE: the charset value specified in this attribute will not be propagated in the Content-Type protocol header of the request message. |
Request
| ws_botype=request |
This attribute corresponds to an HTTP service request business
object. The connector uses this attribute ASI to determine whether this
TLO attribute is of type request BO. This ASI, not the attribute name,
determines the attribute type. If there is more than one request
attribute, the connector uses the ASI of the first one.
|
A request business object is a child of a TLO and is required for asynchronous request processing. The object-level ASI for a request business object for asynchronous request processing is described inTable 24.
Table 24. Asynchronous request processing: object-level ASI for Request business objects
Object-level ASI | Description |
---|---|
cw_mo_http=HTTPCfgMO | The value of this ASI must match the name of the attribute that corresponds to the Protocol Config MO. This Protocol Config MO specifies the destination for the HTTP-HTTPS protocol handler. This ASI is used by the HTTP-HTTPS Protocol Handler. Note that the TLO request attribute must have an HTTP Protocol Config MO for request processing. For further information, see HTTP Protocol Config MO for request processing. Note: The data handler that you configure for business object transformations should be capable of reading any ASI that begins with cw_mo as metadata and not as part of the busisenss data to be converted. The XML data handler has the capability to detect cw_mo metadata, ignoring the attributes that such values point to. |
During request processing, the HTTP-HTTPS protocol handler uses the HTTP Protocol Config MO to determine the destination of the target HTTP service. This Protocol Config MO is required for a request business object. For further information, see HTTP Protocol Config MO for request processing.