Message Sender - Context

Used to construct the URL of the target HTTP server.

Since the URL may be long and complex, you can break it into smaller parts, each defined by a separate context record. The full URL is built by concatenating the values in URL1 through URL9.

You may use substitution variables when entering values for URL parts. Note that the substitution string @XMLMSG@ may be used for GET calls if an XSL has been applied to convert the message into HTTP GET parameters. It is useful if the HTTP Form is not applicable to the type of message.

Refer to Support for Dynamic URLs for configuration needed to support dynamic URLs when sending an outbound message.

Used when the message is in the format of an HTML Form (Content-Type: application/x-www-form-urlencoded).

This context specifies the form parameters (data) that should be passed in the HTTP message. Since a form may have multiple parameters, you should add a context record for each form parameter.

The value of a form parameter takes the format of x=y where x is the form parameter name and y is its value.

If y contains the string @XMLMSG@ (case sensitive) then this string is replaced by the content of the service response XML message. The @XMLMSG@ string can be used in the HTTP Form Data or in the HTTP URL, but not in both.

If a context record of this type is defined for a sender, the sender uses the HTML Form message format to send the message even if @XMLMSG@ is not specified in one of the context records.

If a context record of this type is not defined for a sender, then the XML is sent with Content-Type: text/plain. When using POST it is put in the HTTP message body.

Always required when using the GET method. If you are using the GET method and do not specify a Form Data context record, no message is transferred to the HTTP server.

You may use substitution variables when entering values for Form Data.

Sometimes the HTTP server on the other side may require the addition of HTTP headers to the message.

For each HTTP header that has to be specified you should add a context record with a value having the following format x:y where x is the header name and y is the value for the header

Applicable only if the Sender Security Type is OWSM. Defines the policy set to apply.

Applicable only if the Sender Security Type is OAUTH . Defines the OAuth specification method for acquiring an access token.

Used to construct the URL of the target authorization server. You may use substitution variables to construct the URL.

The generated identifier for the current application in the external system’s authorization server.

The secret paired with the OAuth Client ID as provided by the external system’s authorization server.

Defines the key ring used to store the OAuth Client ID and secret provided by the external system’s authorization server. If a key ring is specified, the OAuth Client ID and OAuth Client Secret context entries are not allowed.

The authorization level granted by the end point.

By default, the authorization token request includes the Client ID and Secret information in the message header. This context type may be used to indicate that this information should be sent in the body of the request instead.

Set this to ‘Y’ to send the Client ID and Secret information as part of the body of the authorization token request.

If JMS header values are required for the message, use this context type.

For each JMS header that has to be specified, add a context record with a value having the following format x:y where x is the header name and y is the value.