This appendix describes the Service Bus message context model and the predefined context variables that are used in message flows.
This chapter includes the following sections:
The Service Bus message context is a set of properties that hold message content as well as information about messages as they are routed through Service Bus.
These properties are referred to as context variables; for example, service endpoints are represented by predefined context variables. Service Bus also supports user-defined context variables.
The message context is defined by an XML schema. You typically use XQuery expressions to manipulate the context variables in the pipeline service.
The predefined context variables can be grouped into the following types: message-related variables, inbound and outbound variables, the $operation variable, and the fault variable.
Table A-1 describes the predefined context variables.
Note:
The Message Context Schema specifies the element types for the message context variables.
For information about the element types in message context variables, see Message Context Schema.
Table A-1 Predefined Context Variables in Service Bus
| Context Variable | Description | See Also |
|---|---|---|
|
header |
For SOAP messages, For message types other than SOAP, |
|
|
body |
This varies depending on the message type, as described below:
|
|
|
attachments |
The MIME attachments for a given message. |
|
|
inbound |
The inbound transport headers along with information about the proxy service that received a message. |
|
|
outbound |
The outbound transport headers along with information about the target service to which a message is to be sent. |
|
|
operation |
The operation being invoked on a pipeline. |
|
|
fault |
Information about errors that have occurred during the processing of a message. |
|
|
messageId |
The transport provider-specific message identifier. This ID should uniquely identify the message among other messages going through the Service Bus runtime, but it is not required that this value be unique. |
Together, the message-related variables $header, $body, and $attachments represent the canonical format of a message as it flows through Service Bus.
These variables are initialized using the message content received by a pipeline and are used to construct the outgoing messages that are routed or published to other services. If you want to modify a message as part of processing it, you must modify these variables.
The message payload (that is, a message content exclusive of headers or attachments) is contained in the $body variable. The decision about which variable's content to include in an outgoing message is made at the point at which a message is dispatched (published or routed) from Service Bus. That determination is dependent upon whether the target endpoint is expecting a SOAP or a non-SOAP message:
When a SOAP message is expected, the $header and $body variables are combined in a SOAP envelope to create the message.
When a non-SOAP message is expected, the contents of the Body element in the $body variable constitutes the entire message.
In either case, if the service expects attachments, a MIME package is created from the resulting message and the $attachments variable.
The $header variable contains SOAP headers associated with a message. The $header variable points to a <SOAP:Header> element with headers as sub-elements. Note that if the proxy service is SOAP 1.2, the $header variable contains a SOAP 1.2 Header element. In the case of non-SOAP messages or SOAP messages with no headers, the <SOAP:Header> element is empty, with no sub-elements.
The $body variable represents the core message payload and always points to a <SOAP:Body> element. Note that if the proxy service is SOAP 1.2, $body contains a SOAP 1.2 Body element. The core payload for both SOAP and non-SOAP messages is available in the same variable and with the same packaging; that is, wrapped in a <SOAP:Body> element:
In the case of SOAP messages, the SOAP body is extracted from the envelope and assigned to the $body variable.
In the case of non-SOAP, non-binary, messages, the full message contents are placed within a newly created <SOAP:Body> element.
In the case of binary messages, rather than inserting the message content into the $body variable, a <binary-content/> reference element is created and inserted into the <SOAP:Body> element. To learn how binary content is handled, see Binary Content in the Body and Attachments Variables.
In the case of Java objects, a <java-content/> reference element is created and inserted into the <SOAP:Body> element. To learn how Java content is handled, see Java Content in the Body Variable.
The $attachments variable holds the attachments associated with a message. The attachments variable is defined by an XML schema. It consists of a single root node, <ctx:attachments>, with a <ctx:attachment> sub-element for each attachment. The sub-elements contain information about the attachment (derived from MIME headers) as well as the attachment content and any custom headers for the attachment.
As with most of the other message-related variables, $attachments is always set, but if there are no attachments, the $attachments variable consists of an empty <ctx:attachments> element. The $attachments variable contains the following for each attachment:
The attachment, if the attachment is XML.
A reference XML, if the attachment is binary.
Text, if the attachment is text.
Note:
The Message Context Schema specifies the element types for the message context variables.
Each attachment element includes the set of sub-elements described in Table A-2.
Table A-2 Sub-Elements of the Attachments Variable
| Elements of the Attachments Variable | Description |
|---|---|
|
Content-ID |
A globally-unique reference that identifies the attachment.The type is |
|
Content-Type |
The media type and sub-type of the attachment. The type is |
|
Content-Transfer-Encoding |
An indicator of how the attachment is encoded. The type is |
|
Content-Description |
A textual description of the content. The type is |
|
Content-Location |
A locally-unique URI-based reference that identifies the attachment. The type is |
|
Content-Disposition |
An indicator of how the attachment should be handled by the recipient. The type is |
|
user-headers |
A list of custom MIME headers for the attachment. This element can contain one or more |
|
user-header |
A custom MIME header. Specify the header's name in the |
|
body |
Holds the attachment data. The type is |
With the exception of the untyped body element, all other elements contain string values that are interpreted in the same way as they are interpreted in MIME. For example, valid values for the Content-Type element include text/xml and text/xml; charset=utf-8.
The parsing of attachments is not recursive. If an attachment has a Content-Type of multipart/..., the body element holds the original unpacked MIME content as a stream of bytes and does not contain attachment sub-elements. Because the MIME stream may contain binary data, it is represented by a <binary-content> reference element. To learn how binary content is handled, see Binary Content in the Body and Attachments Variables.
Messages whose Content-Type is multipart/form-data are constructed at runtime as follows:
Inbound: All parts of a received inbound multipart/form-data type message are assigned to the $attachments variable. The $body variable is left empty.
Outbound: The content of an outbound multipart/form-data type message is built from the content of the $attachments variable. Nothing from $header or $body is included.
Note:
If the inbound message is of a different multipart type than multipart/form-data (for example, multipart/related) and the outbound message is multipart/form-data, you must explicitly preserve the headers and content of the inbound root part, because they will not otherwise be passed through.
Service Bus does not support sending attachments to EJB, Tuxedo, and DSP services.
The context variables are wrapper variables that contain the SOAP header elements, the SOAP body element, and the MIME attachments, respectively. The context gives the impression that all messages are SOAP messages, and non-SOAP messages are mapped to this paradigm. The following table lists the mappings for different message types. For information about Java content, see Java Content in the Body Variable.
Table A-3 Message Mappings
| Message Type | Mapping |
|---|---|
|
XML |
The |
|
binary |
The |
|
MFL |
The document is transparently converted from and to XML, and appears as an XML document in the |
|
text |
The |
|
File, FTP, and Email |
In the case of pass-by-reference documents, a reference XML document in the |
|
SOAP |
The |
In the case of both the $body and $attachments variables, text, XML, and MFL content is placed directly inside an XML element. For binary data, which can contain byte values that are illegal in XML, Service Bus does not place the binary content in the XML element. Consequently, the binary content cannot be manipulated, but it is handled efficiently.
When binary content is received, the Service Bus runtime stores it in an in-memory hash table and a reference to that content is inserted into the XML (body or attachments) element. This reference is represented by the following XML snippet:
<binary-content ref="..."/>
where the ref attribute contains a URI or URN that uniquely identifies the binary content. This XML can be manipulated in a pipeline pair, branch, or route node in the same way any other content can be manipulated, but only the reference and not the underlying binary content is affected.
For example:
Binary content in the $body variable can be copied to an attachment by copying the reference XML to the body sub-element of an attachment element.
Binary content in two different attachments can be swapped by swapping the snippets of reference XML or by swapping the values of the ref attributes.
When messages are dispatched from Service Bus, the URI in the reference XML is used to restore the relevant binary content in the outgoing message. For information about how outbound messages are constructed, see Constructing Messages to Dispatch.
Clients and certain transports, notably email, file, and FTP can use this same reference XML to implement pass-by-reference. In this case, the transport or client creates the reference XML rather than the proxy service runtime. Also, the value of the URI in the ref attribute is specified by the user who creates the reference XML. For these cases in which the reference XML is not created by the proxy service runtime—specifically, when the URI is not recognized as one referring to internally managed binary content—Service Bus does not de-reference the URI, and the content is not substituted into an outgoing message.
When you send a SOAP with Attachments (SwA) document from Service Bus to a BPEL business process and use the XPath function ora:getAttachmentContent('inputVariable','bin','/bin') to retrieve the multipart attachments in BPEL, make sure to do the following:
Set the Content-ID attachment variable for the multipart attachments.
Refer to the attachments in the primary soap envelope using an href attribute.
Note that in some cases, the cid: information might be absent from the href attribute.
Below is an example:
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<rootpart@example.com>"
Content-Description: This is the optional message description.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@example.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<m:SendClaim xmlns:m="http://example.com/mimewsdl“>
<ClaimDetail>
<Name>...</Name>
<!-- additional claim details -->
</ClaimDetail>
<ClaimPhoto href="cid:4d7a5fa2-14af-451c-961b5c3abf786796@example.com"/>
</m:SendClaim>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <4d7a5fa2-14af-451c-961b5c3abf786796@example.com>
...MIME attachment of binary photograph...
--MIME_boundary—
The Service Bus pipeline supports Java objects as inputs and outputs to Java callout actions. A POJO returned by a Java callout is cached in the pipeline, and its key is returned wrapped in an XML message of the form <java-content ref="cid:kkkkeeeeyyyy"/>, where cid:kkkkeeeeyyyy is a key automatically generated by the producing action and used to index the object in the pipeline's POJO repository. Any subsequent action then passes that XML unmodified as an argument.
The content of a POJO variable is not directly accessible by pipeline actions at configuration time. Rather, the content can be handled in the following ways:
The content's metadata (that is, its key) can be handled as any other XML, for example in an XQuery such as $pojo/java-content/@ref. This may be useful for logging or debugging, but the content of the object cannot be directly accessed.
The content can be assigned to a new variable that automatically becomes typed (in the pipeline) as a POJO. The object itself is not touched. The <java-content.../> XML snippet is copied from the source variable to the target variable.
The content can be passed to another appropriate action (like Java callout) as a variable (for example, $pojo). The object itself is not touched. The argument is automatically de-referenced to the actual object.
The Java object is removed from the pipeline's POJO repository when you delete all variables holding the object's key (in <java-content />) or when you delete all XPaths pointing to the <java-content /> snippet.
For processing message content, you can specify that the pipeline streams the content rather than loading it into memory. When you enable content streaming for a pipeline, you specify whether to buffer the streamed content to memory or a disk file as an intermediate step during the processing of the message. The creation of these temporary files might affect performance. For information about protecting temporary files, see "Protection of Temporary Files With Streaming body Content" in Administering Oracle Service Bus.
When you enable the streaming option, content streaming applies only to the $body variable.
In general, use content streaming:
When processing large content messages. See the guidelines in Best Practices for Using Content Streaming.
In use cases where Service Bus accesses the payload a small number of times.
For content-based routing without transformations; content streaming results in better performance due to the benefits from partial parsing.
Use the following guidelines and recommendations for enabling streaming content:
When you enable streaming for large message processing, you cannot use the insert, replace, rename, for each, validate, and delete actions with respect to the $body message context variable, because these actions require the input variable to be fully materialized in memory and full materialization is incompatible with the content streaming option.
You can use the results of an XQuery or XSL transformation from a very large $body with the following pipeline actions:
Assign, insert, and replace actions: Use the results to update the value of another context variable (not $body). However, you must ensure that the result of the expression is small enough to be fully materialized and stored in the message context.
Java callouts: Use the results to pass input arguments. All input to Java callouts is fully materialized, therefore, the results of expressions used as input must be small enough to be fully materialized.
MFL transformations: Use the results to transform very large payloads without first materializing the input as an XML Bean. When using a very large $body as an input to an MFL transformation, declare a messaging service, binary message type pipeline. If you declare a messaging service, text message type pipeline, $body will get fully materialized to obtain an input stream for the transformation.
Alert, log, and report actions: Use the results to report the result of an XQuery or XSL transformation on a very large $body.
Service callouts
For XSL transformations, all input is fully materialized in order to perform the transformation, therefore, you must ensure that the input is small enough so that it can be fully materialized and processed by the XSLT processor.
With very large MFL input, you should use an MFL service instead of an MFL stage action to perform a MFL-to-XML transformation.
Do not use the Test Console to test pipelines with very large content messages because the content will be fully materialized, potentially causing an out-of-memory exception, and displayed, causing a slowdown in the Test Console window.
When writing XQueries, use proper indexing to achieve partial parsing.
For example, instead of using $body/*:DateTimeStruct, which would consume the entire input stream, use one of the following:
($body/*:DateTimeStruct)[1]
or
$body[1]/*:DateTimeStruct[1]
By using indexing, only content up to and including the first DateTimeStruct element will be parsed.
Because each variable that is accessed by two or more consumers (expressions) is materialized, when writing XQueries, avoid statements such as the following:
let $labdata1 := $body/*
return <HEADER>{ $labdata1/HEADER/@*, $labdata1/HEADER/node() }</HEADER>
In this case, $labdata1 is bound to the whole document without the root element so the XQuery engine runs out of memory when trying to materialize it.
One way of changing this query to avoid excessive materialization would be to move the /HEADER path expression inside the let clause.
let $labdata1 := $body/*/HEADER ...
In this case, the XQuery engine will only materialize the HEADER element or elements.
At runtime, processing large messages is subjected to the limitations and restrictions of the underlying transport; for example, the message size handling limitations of the transport. Be aware of the JVM and RMI settings that limit the capacity of the transport to accept large messages.
For processing message attachments, you can specify that Service Bus page MIME attachments to disk and then stream the contents rather than buffering the attachments in memory and parsing them into XML. This is particularly advantageous when working with large attachments. Using this approach, Service Bus buffers only the headers and exposes the rest of the message payload as a stream from which smaller portions can be read at a time. Streamed transfers can improve the scalability of a service by eliminating the need for large memory buffers.
Note:
Service Bus does not support streaming attachments for email or WS transports.
When enabled for pipelines, the setting applies to the handling of inbound request messages. For HTTP business services, the setting applies in the handling of outbound response messages. The following actions allow outbound messages to be dispatched and support streaming attachments:
Route, Dynamic Route, and Route Table
Publish, Dynamic Publish, and Publish Table
When streaming is enabled, all attachments, including binary, text, and XML, are processed as opaque data, which means you cannot run XQueries or XPath expressions based on the XML content of the attachment.
When Service Bus receives an inbound message and is configured to stream attachments, the contents of each MIME attachment is saved to a separate file on disk. The value of the $attachments variable is then set such that standard MIME headers for each attachment, including Content-ID, Content-Type, Content-Transfer-Encoding, Content-Description, Content-Location, and Content-Disposition, when present, are added under the attachment element.
The body child element then has a single binary-content child element that refers to the corresponding source in the source repository.
For example, an $attachments variable might appear as follows:
<con:attachments xmlns:con="http://www.oracle.com/wli/sb/context/">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID>
<1.urn:uuid:BFB7D745CBAF21BA5B12023554608963@apache.org>
</con:Content-ID>
<con:Content-Transfer-Encoding>
binary
</con:Content-Transfer-Encoding>
<con:body>
<con:binary-content ref="cid:23976580:1183dd6aab9:-7fe0"/>
</con:body>
</con:attachment>
</con:attachments>
This is done regardless of the attachment content type. This means that text/xml attachments, for example, are treated identically to image/jpeg attachments, namely as opaque binary data with a binary content element.
This style of message handling differs from when attachments are not streamed, in which case certain types, such as text/xml or text/plain are recognized and used to initialize the body XML element (to contain the XML contents) or the text contents of the attachment respectively.
When Service Bus processes an outbound message and is configured to stream attachments, the contents of each MIME attachment is saved to a separate file on disk. Service Bus then initializes the $attachments message context variable in a manner similar to inbound requests (see Inbound Message Handling).
Service Bus enables you to configure pipelines to decode and parse inbound messages in XOP/MTOM format and to send responses using the XOP/MTOM format, when appropriate. Oracle also enables you to configure business services to encode outbound messages in XOP/MTOM format.
Service Bus supports pipelines with the following binding types to accept and decode incoming XOP/MTOM payloads:
Any XML
Messaging (XML)
Any SOAP
WSDL-based
Pipelines of any other service binding type that receive XOP/MTOM payloads treat them the same as any other MIME multipart request without MTOM-specific handling.
In addition, the following Service Bus transports support XOP/MTOM:
HTTP/S
Local
SB (when applicable, such as with chained Service Bus domains)
Service Bus supports all existing actions that allow outbound messages to be dispatched, including the following:
Route, Dynamic Route and Route Table
Publish, Dynamic Publish and Publish Table
Service Callout
Service Bus does not support combining MTOM and SOAP with Attachments (SwA).
You can enable pipelines to decode and parse inbound messages in XOP/MTOM format and to send responses using the XOP/MTOM format, when appropriate. When XOP/MTOM support is enabled, you can further select how to handle binary data in the $body message context variables from among the following options:
Include Binary Data by Reference: (Default) See Binary by Reference Option.
Include Binary Data by Value: See Binary by Value Option.
Note that if XOP/MTOM Support is enabled for a pipeline, it is not required that every inbound message be in the MTOM format. Instead, this setting specifies that when an MTOM-formatted message arrives, the pipeline should handle it accordingly. Note also that when pipelines that are not enabled for XOP/MTOM support receive an MTOM-formatted message, the service rejects the message and issues a runtime error.
Use Include Binary Data by Reference when you need direct access to binary data, for example to pass data to a Java callout or Message Format Language (MFL) transformation.
When the Binary by Reference option is selected, Service Bus parses the root of the inbound message checking for the presence of xop:Include tags. These tags, when found, are converted to ctx:binary-content elements with a reference pointing to the corresponding source in binary repository. The resulting document is represented by the $body message context variable. The $attachments message context variable, in contrast, does not contain any information (is null).
This means that when pipeline actions access the contents of the $body message context variable, the actions do not encounter xop:Include elements, but instead work with ctx:binary-content elements.
When the pipeline needs to send a response back, the binding layer creates an XOP/MTOM package response by replacing ctx:binary-content references with xop:Include tags in the root of the message and adding a separate MIME part for each corresponding binary content reference.
Use Include Binary Data by Value in the following cases:
To bridge between MTOM and non-MTOM services. For example, consider an MTOM-enabled pipeline that receives a request that is then routed to a non-MTOM-enabled service. You could use this option to comply with existing standards for sending binary data in XML in Base64-encoded form.
To validate the contents of the message against an XML schema that requires a base64binary element to be used in place of binary data.
When the Include Binary Data by Value option is selected, Service Bus parses the root of the inbound MIME message checking for the presence of xop:Include tags. When found, the body of the corresponding MIME parts (the binary data) are Base64 encoded and the resulting text replaces the xop:Include tags in the $body message context variable.
The $attachments message context variable, in contrast, does not contain any information (is null).
You can enable business services to encode outbound messages in XOP/MTOM format. When XOP/MTOM Support is enabled, you can further select how to handle binary data in the $header and $body message context variables from among the following options:
Include Binary Data by Reference: (Default) In an outbound response message, replace xop:Include elements with ctx:binary-content elements when setting up the $body message context variable.
Include Binary Data by Value: In an outbound response message, replace xop:Include elements with Base64-encoded text versions of corresponding binary data when setting up the $body message context variable.
Note that if XOP/MTOM support is enabled for a business service, it is not required that every outbound message be in the MTOM format. Instead, this setting specifies that the business service is capable of handling an MTOM payload.
When XOP/MTOM support is enabled for a business service, Service Bus examines the contents of $body message context variable searching for ctx:binary-content elements. If any are present, Service Bus creates an XOP/MTOM MIME package replacing ctx:binary-content with xop:Include elements and with the corresponding MIME part in the payload.
Service Bus always uses XOP/MTOM when it is enabled and the body has binary content, regardless of the size of the content (for example, even when it is smaller than 1KB). Since Service Bus does not support the combination of MTOM and SwA, the system throws a runtime exception when Service Bus needs to dispatch an outbound request to a business service and the following conditions are met:
The business service is XOP/MTOM enabled
The $attachments message context variable is not null
With XOP/MTOM enabled on a service, Service Bus automatically modifies elements in the $header and $body of a message, as described in the previous sections. Because of the need to modify XOP/MTOM message content, Service Bus does not support streaming the message $header and $body.
However, there may be situations in which you need to stream the binary attachments of XOP/MTOM messages directly to disk rather than to the Service Bus heap (the default), such as when attachments are large and cause out-of-memory errors.
Note:
XOP/MTOM attachments are not sent in the $attachments variable of the message. They are included or referenced in the message $body as previously described.
To stream XOP/MTOM message attachments directly to disk, use the following settings on your service configuration:
Use the XOP/MTOM Include Binary Data by Reference option. This option puts the binary data directly in the $body, which cannot be streamed for XOP/MTOM support.)
With Include Binary Data by Reference selected, you can also select the Page Attachments to Disk option (HTTP transport only). With Page Attachments to Disk selected, Service Bus generates the XOP/MTOM message to reference the binary attachment on disk rather than in memory.
Note:
Referencing attachments in memory is recommended for optimum performance, so use the Page Attachments to Disk option only when you have a specific need for doing so, such as when sending large attachments whose size could cause out-of-memory errors.
Service Bus supports custom MIME headers for both inbound request/outbound response and outbound request/inbound response message patterns. When an inbound message includes a custom header and the message is read in the pipeline, the custom header information appears in the user-headers element in the XML, as shown in the example below.
<con:user-headers>
<con:user-header name="MyCustomHeader" value="Custom Header Value" />
</con:user-headers>
For an outbound request with an inbound response, Service Bus converts any user-header elements to custom headers in the corresponding MIME part when Service Bus constructs the outbound request message. user-header elements can be the result of the (unpacked) inbound request or can be added manually in an explicit pipeline action, such as insert, replace or assign actions.
The $inbound and $outbound context variables contain information about the inbound and outbound endpoints.
The $inbound variable contains information about the proxy service that received the request message; the $outbound variable contains information about the target business service to which a message is sent.
The $outbound variable is set in the route action in route nodes and publish actions. You can modify $outbound by configuring request and response actions in route nodes and by configuring request actions in publish actions.
Caution:
Some modifications that you can make for the $inbound and $outbound context variables are not honored at runtime. That is, the values of certain headers and metadata can be overwritten or ignored by the Service Bus runtime. The same limitations are true when you set the transport headers and metadata using the transport headers and service callout actions, and when you use the Test Console to test your services.
For information about the headers and metadata for which there are limitations, see How the Runtime Uses the Transport Settings in the Test Console. Note also that any modifications you make to $outbound in the message flow outside of the request or response actions in route nodes and publish actions are ignored. In other words, those modifications are overwritten when $outbound is initialized in the route nodes and publish actions.
You cannot modify the $outbound variable in service callout actions.
The $inbound and $outbound variables have the following characteristics:
Have the same XML schema. The $inbound and $outbound context variables are instances of the endpoint element as described in Message Context Schema.
Contain a single name attribute that identifies the name of the endpoint as it is registered in the service directory. The name attribute should be considered read-only for both $inbound and $outbound.
Caution:
The read-only rule is not enforced. Changing read-only elements can result in unpredictable behavior.
Contain the service, transport and security sub-elements described in Sub-Elements of the Inbound and Outbound Variables..
This section describes the sub-elements of the $inbound and $outbound context variables, including information about whether a given sub-element is initialized at runtime. To learn about how context variables are initialized, see Initializing Context Variables. The sub-elements include the following:
The service element is read-only for both $inbound and $outbound. Sub-elements include providerName and operation.
Note:
The Message Context Schema specifies the element types for the message context variables.
Table A-4 Sub-Elements of the service Element
| Sub-Elements | Description... |
|---|---|
|
providerName |
The name of the service key provider. This is initialized based on the configuration of publish and routing actions. |
|
operation (outbound only) |
The name of the operation to be invoked on the target business service. This is initialized based on the Note: This element is used for the |
The transport element is read-only on inbound, except for the response element, which you can modify to set the response transport headers. The sub-elements of the transport element are described in Table A-5.
Note:
The Message Context Schema specifies the element types for the message context variables.
Table A-5 Sub-Elements of the Transport Element
| Sub-Elements | Description... |
|---|---|
|
uri |
The URI of the endpoint:
Initialization The URI element is initialized as described below:
|
|
request |
Transport-specific metadata about the request (including transport headers). The value for this element is defined by the transport protocol (specifically, the This element is read-only in the To learn about the transport-specific types for this element, see the appropriate transport schema, which are available in the following directory in your Service Bus installation:
service_bus-home/config/plugins/
Initialization The URI element is initialized as described below:
To set a filename for an outbound message using the File transport protocol, configure
|
|
response |
Transport-specific metadata about the response (including transport headers). The value for this element is defined by the transport protocol (specifically, the This element is read-only in the To learn about the transport-specific types for this element, see the appropriate transport schema, which are available in the following directory in your Service Bus installation:
service_bus-home/config/plugins/
Initialization The
For a description of the standard HTTP headers, see For a description of the standard JMS headers, see "Value-Added Public JMS API Extensions" in Developing JMS Applications for Oracle WebLogic Server. Note: The following MQ headers do not have equivalents in Oracle JMS: |
|
mode |
An indicator of whether the communication style is Initialization Initialized on the |
|
qualityOfService This element is read only for inbound. You can modify it for the outbound case— in the outbound request actions of a publish or routing action. |
The quality of service expected when sending or receiving a message. Valid values include
Initialization The
|
|
retryCount (outbound only) |
The number of retries to attempt when sending a message from Service Bus. If |
security element are described in Table A-6.
Note:
The Message Context Schema specifies the element types for the message context variables.
Table A-6 Sub-Elements of the Security Element
| Sub-Elements | Description... |
|---|---|
|
transportClient inbound only) |
Authenticated transport-level user information. The user information includes a user name and any optional principals. The principals can themselves include zero or more groups, one for each group the subject belongs to. This variable is initialized by Service Bus. The inbound |
|
messageLevelClient inbound only) |
Specifies authenticated message-level user information. The user information includes a user name and any optional principals. The principals can themselves include zero or more groups, one for each group the subject belongs to. This variable is initialized by Service Bus. The inbound |
|
doOutboundWss (outbound only) |
Service Bus sets the value of this element during routing or publishing. Some infrequently used design patterns set the value to For more information, see under Disabling Outbound WS-Security. Note: When one proxy service invokes another proxy service (such as a local proxy) that contains Oracle Web Services Manager service policies, outbound WS-Security processing does not occur. cService Bus handles that behavior automatically and does not use the |
Working with Pipeline Actions in Oracle Service Bus Console
How to Add Route Nodes to Pipelines in the Console
For a description of the standard HTTP headers, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
For a description of the standard JMS headers, see "Understanding WebLogic JMS" in Developing JMS Applications for Oracle WebLogic Server.
The $operation variable is a read-only variable. It contains a string that identifies the operation to be invoked on a pipeline.
If no operations are defined, the $operation variable is not set and returns the equivalent of null.
Service Bus provides the $operation variable as a stand-alone variable, rather than as a sub-element of the $inbound variable to optimize performance. The computation of the operation may be deferred until the $operation variable is explicitly accessed rather than anytime the $inbound variable is accessed.
The fault variable holds information about any error that has occurred during message processing.
When an error occurs, this variable is populated with information before the appropriate error handler is invoked. This variable is defined only in error handler pipelines and is not set in request and response pipelines or in route or branch nodes.
The fault variable includes the sub-elements described in Table A-7.
Note:
The Message Context Schema specifies the element types for the message context variables.
Table A-7 Sub-Elements of the Fault Variable
| Elements of the Fault Variables | Description |
|---|---|
|
errorCode |
The error code as a string value. |
|
reason |
A text description of the error. |
|
details |
User-defined XML content related to the error. For more information see Error Codes and Error Details. |
|
location |
Identifies the node, pipeline and stage in which the error occurred. Also identifies if the error occurred in an error handler. The sub-elements include the following:
|
|
java-exception |
Information about the exception instance references. This can contain multiple |
|
stack-trace |
Any stack traces to add to the fault. |
The contents of the fault variable are modeled after SOAP faults to facilitate fault generation when replying from a SOAP-based service. The values for error codes generated by Service Bus correspond to system error codes and are prefixed with an "OSB" string, unless configured otherwise. The error codes associated with the errors surface inside the element of the fault context variable. To access the value, use the following XQuery statement:
$fault/ctx:errorCode/text()
Service Bus defines generic error codes for the four classes of possible errors. The format of the generic codes is OSB-xxx000, where xxx represents a generic category as follows:
380 Transport and Proxy
382 Pipeline
386 Security
394 UDDI
This yields the generic codes as follows:
OSB–380000—OSB–380999
Indicates a transport or proxy service error (for example, failure to dispatch a message).
OSB–382000—OSB–382499
Indicates a pipeline runtime error (for example, a stage exception).
OSB–382500—OSB–382999
Indicates an error in a pipeline action.
OSB–386000—OSB–386999
Indicates a WS-Security error (for example, authorization failure).
OSB–394500—OSB–394999
Indicates an error in the UDDI sub system.
Service Bus defines unique codes for specific errors. For example:
OSB-382030: Indicates a message parsing error (for example, a SOAP service received a non-SOAP message).
OSB-382500: Reserved for the case in which a service callout action receives a SOAP Fault response.
The details element of the fault variable displays the type of fault, along with relevant information to the fault type. It can include any of the following elements indicating the error type:
ErrorResponseDetail: Indicates that a service callout action received an error response from a transport provider.
InvalidEnvelope: Indicates that a SOAP service received a well-formed XML document that was not an expected SOAP envelope.
PayloadDetail: Indicates that an error occurred when parsing all or parts of the payload as XML.
ReceivedFaultDetail: Indicates that a service callout action received a SOAP fault.
UnrecognizedResponseDetail: Indicates that a service callout action received an unrecognized response from a transport provider.
ValidatonFailureDetail: Indicates that an error occurred in a validation action.
WebServiceSecurityFault: Indicates that a Web Services Security processing-related error occurred.
StackTrace: The exception stack trace for cases not covered above.
You can view the errors schema file in Errors Schema.
When an error is an XML parsing error, the malformed XML text is included in the PayloadDetail element in the error schema, as described in Error Details. Parsing errors are only detected when parsing inbound request messages to the pipeline and outbound response messages to the business services. Actions that explicitly change the payload, such as an assign action, that result in malformed XML are not included in this error detail.
Only the part of the payload that was read by the XML parser is included in the fault variable, so the PayloadDetail element might not include the entire XML text. By default, there is no limit to the number of characters that can be included in the error detail. To limit the size of the XML text included in the payload detail of the fault variable, set the system property com.bea.wli.sb.FaultPayloadDetailMaxSize to the size of the text you want to include (in bytes). Setting this property to 0 (zero) disables the feature, which means faults will not include the PayloadDetail element.
If the pipeline has content streaming enabled, the text placed in the PayloadDetail element is truncated to either 10KB or to the max size you set, if it is less than 10KB. If the payload contains binary characters, the payload is base64-encoded and placed in the base64 child element of the PayloadDetail element (up to the maximum payload detail size).
messageID is a transport provider-specific identifier associated with the message.
It can be accessed via the $messageID system variable.
The message context and its variables are initialized in the binding layer when a message is received and before message processi
ng begins. Table A-8 summarizes how context variables are initialized.
Table A-8 Initializing Context Variables
| Context Variable | How Initialized |
|---|---|
|
outbound |
Initialized to null because no routing or errors have yet occurred. |
|
fault |
The For information about the initialization of sub-elements of |
|
inbound |
Initialized with service, transport and security information that is obtained from Service Bus metadata about the registered proxy service and transport-level metadata (transport headers, authenticated user information, and so on) about the specific incoming request. For information about the initialization of sub-elements of |
|
header body attachments operation |
Initialized using the content of the inbound message. How the initialization is performed depends on the type of service, as described in the subsequent topics in this section: The |
The $attachments context variable is initialized with any MIME attachments that accompany the message, but does not include the part representing the main message (whether it is SOAP, XML, MFL, and so on). Each <attachment> element is initialized using the MIME headers that accompany each part in the MIME package.
The contents of the <body> element in the <attachment> can be one of the following depending on the attachment's Content-Type:
XML
text
A snippet of reference XML that refers to the attachment content (see Binary Content in the Body and Attachments Variables.)
This section describes how the initialization of $header and $body context variables is performed depending on the type of service: SOAP Services, XML Services (Non SOAP), Messaging Services.
Messages to SOAP-based services are SOAP messages containing XML that is contained in a <soap:Envelope> element. In the case that messages include attachments, the content of the inbound message is a MIME package that includes the SOAP envelope as one of the parts, typically the first part or one identified by the top-level Content-Type header. The context variables are initialized as follows:
$header: Initialized with the <soap:Header> element from the SOAP message
$body: Initialized with the <soap:Body> element from the SOAP message
The messages to XML-based services are XML, but can be of any type allowed by the service configuration. In the case that messages include attachments, the content of the inbound messages is a MIME package that includes the primary XML payload as one of the parts, typically the first part or one identified by the top-level Content-Type header.
The context variables are initialized as follows:
$header: Initialized with an empty <soap:Header/> element.
$body: Initialized with a <soap:Body> element that wraps the entire XML payload.
Messaging services are those that can receive messages of one data type and respond with messages of a different data type. The supported data types include XML, MFL, text, untyped binary. The context variables are initialized as follows:
$header: Initialized with an empty <soap:Header/> element.
$body: Initialized with a <soap:Body> element that wraps the entire payload.
In the case of XML, MFL, and text content, it is placed directly within the <soap:Body> element.
In the case of binary content, a piece of reference XML is created and inserted inside the <soap:Body> element (see Binary Content in the Body and Attachments Variables). The binary content cannot be accessed or modified, but the reference XML can be examined, modified, and replaced with inline content.
You interact with and manipulate the message context through actions in the pipeline pair, branch, or route nodes that define the pipeline.
Most actions expose the XQuery language to do so. Each context variable is represented as an XQuery variable of the same name. For example, the $header variable is accessible in XQuery as $header, the $body variable is accessible as $body, and so on. The examples in this section show the use of XQuery to examine and manipulate context variables.
The $body variable includes the <soap-env:Body>...</soap-env:Body> element. (If the service is SOAP 1.2, the $body variable contains a SOAP 1.2 Body element.) For example, if you assign data to the $body context variable using the Assign action, you must wrap it with the <soap-env:Body> element. In other words, you build the SOAP package by including the <soap-env:Body> element in the context variable.
There is an exception to this behavior for the case in which you build the Request Document Variable for the service callout action. Service callout actions work with the core payload (RPC parameters, documents, and so on) and Service Bus builds the SOAP package around the core payload. In other words, when you configure the Request Document Variable for a service callout action, you do not wrap the input document with <soap-env:Body>...</soap-env:Body>.
For information about configuring the service callout action, see Adding Service Callout Actions in the Console.
The $header variable includes the <soap-env:Header>...</soap-env:Header> element. (If the proxy service is SOAP 1.2, the $header variable contains a SOAP 1.2 Header element.) For example, if you assign data to the $header context variable using the Assign action, you must wrap it with the <soap-env:Header> element. In other words, you build the SOAP package by including the <soap-env:Header> element in the context variable. This is true for all manipulations of $header, including the case in which you can set one or more SOAP headers for a service callout request. For information about configuring SOAP headers for a service callout action, see Adding Service Callout Actions in the Console.
Extract the WS-Addressing Header—From: $header/wsa:From
Extract the Payload From a Non-SOAP Message: $body/*
Extract the user-header From an Outbound Response Message: $outbound/ctx:transport/ctx:response/tp:user-header[@name='myheader']/@value
When creating a $body input variable that is used for the request parameter in a service callout to a SOAP Service, you would define that variable's contents using $body/* (to remove the wrapper soap-env:Body), not $body (which results in keeping the soap-env:Body wrapper).
Assign Variable Contents for Request Parameter in a Service Callout: $body/*
When Service Bus publishes or routes a message, the content of the message is constructed using the values of variables in the message context.
For example, transport headers and other transport-specific metadata are taken from $outbound/transport/request. As is the case with initialization of the context, the message content for outbound messages is handled differently depending upon the type of the target service. How the outbound message content is created depends on the type of the target service, as described in the following topics:
An outgoing SOAP message is constructed by wrapping the contents of the $header and $body variables inside a <soap:Envelope> element. If the invoked service is a SOAP 1.2 service, the envelope created is a SOAP 1.2 envelope. If the invoked service is a SOAP 1.1 service, the envelope created is a SOAP 1.1 envelope. If the $body variable contains a piece of reference XML, it is sent as is; in other words, the referenced content is not substituted into the message.
If attachments are defined in the $attachments variable, a MIME package is created from the main message and the attachment data. The handling of the content for each attachment part is similar to how content is handled for messaging services.
The messages to XML-based services from Service Bus are constructed from the contents of the $body variable:
If the $body variable is empty, then a zero-size message is sent.
If the $body variable contains multiple XML snippets, then only the first snippet is used in the outbound message. For example, if <soap:Body> contains <abc/><xyz/>, only <abc/> is sent.
If the content of the $body variable is text and not XML, an error is thrown.
If the $body variable contains a piece of reference XML, it is sent as is; in other words, the referenced content is not substituted into the message.
If attachments are defined in the $attachments variable, a MIME package is created from the XML message and the attachment data. In the case of a null XML message, the corresponding MIME body part is empty. The handling of the content for each attachment part is similar to how content is handled for messaging services.
Regardless of any data it contains, the $header variable does not contribute any content to the outbound message. For examples of how messages are constructed for service callout actions, see Working with Pipeline Actions in Oracle Service Bus Console.
The messages to messaging services from Service Bus are constructed from the contents of the $body variable.
If the $body variable is empty, then a zero-size message is sent, regardless of the outgoing message type.
If the outgoing message type is XML, then the message is constructed in the same way as it is for XML Services (Non SOAP).
If the outgoing message type is MFL, then the behavior is similar to that for XML message types except that the extracted XML is converted to MFL. An error occurs if the XML > MFL conversion cannot be performed.
If the target service requires text messages, the contents of the $body variable are interpreted as text and sent. In this way, it is possible for Service Bus to handle incoming XML messages that must be delivered to a target service as text. In other words, you do not need to configure the message flow to handle such messages.
For target services that expect binary messages, the $body variable must contain a piece of reference XML—the reference URI references the binary data stored in the Service Bus in-memory hash table. The referenced content is sent to the target service.
For cases in which a client, a transport, or the designer of a service specifies the reference URI, the referenced data is not stored in Service Bus and thus cannot be de referenced to populate the outbound message. Consequently, the reference XML is sent in the message.
If the $body variable contains a piece of reference XML, and the target service requires a message type other than binary, the reference XML inside the $body variable is treated as content. In other words, it is sent as XML, converted to text, or converted to MFL. This is true regardless of the URI in the reference XML.
Regardless of any data it contains, the $header variable does not contribute any content to the outbound message.
For examples of how messages are constructed for service callout actions, see Working with Pipeline Actions in Oracle Service Bus Console.
For binary messages, Service Bus does not insert the message content into the $body variable. Instead, a <binary-content/> reference element is created and inserted into the <SOAP:Body> element (see Message-Related Variables). However, the email standard does not support sending binary content type as the main part of a message. If you want to send binary messages by email to a messaging service that accepts text or XML documents and optional attachments, you can do so as follows:
Transfer the binary-content reference XML from $body to $attachments.
Replace the content of $body with text or XML wrapped in a <SOAP:Body> element.
For the case in which the outgoing message type is MFL, the contents of $body is converted from XML to text or binary based on the MFL transformation:
If the target service expects to receive text message, you can set the content-type (the default is binary for MFL message type) as text/plain in $outbound
If the target service expects to receive binary messages, it is not possible to send MFL content using the email transport.
To learn more about how binary content is handled, see Binary Content in the Body and Attachments Variables.
This example shows the message context schema (MessageContext.xsd), which specifies the types for the message context variables.
When working with the message context variables, you need to reference MessageContext.xsd which is available in a JAR file, OSB_ORACLE_HOME/lib/servicebus-schemas.jar, and the transport-specific schemas, which are available at OSB_ORACLE_HOME/config/plugins/.
Example - MessageContext.xsd
<schema targetNamespace="http://www.bea.com/wli/sb/context"
xmlns:mc="http://www.bea.com/wli/sb/context"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- =========================================================================== -->
<!-- The context variable 'fault' is an instance of this element -->
<element name="fault" type="mc:FaultType"/>
<!-- The context variables 'inbound' and 'outbound' are instances of this
element -->
<element name="endpoint" type="mc:EndpointType"/>
<!-- The three sub-elements within the 'inbound' and 'outbound' variables -->
<element name="service" type="mc:ServiceType"/>
<element name="transport" type="mc:TransportType"/>
<element name="security" type="mc:SecurityType"/>
<!-- The context variable 'attachments' is an instance of this element -->
<element name="attachments" type="mc:AttachmentsType"/>
<!-- Each attachment in the 'attachments' variable is represented by an
instance of this element -->
<element name="attachment" type="mc:AttachmentType"/>
<!-- Used to represent binary payloads and pass-by reference content -->
<element name="binary-content" type="mc:BinaryContentType"/>
<!-- Element used to represent POJOs stored in object repository -->
<element name="java-content" type="mc:JavaContentType"/>
<!-- =========================================================================== -->
<!-- The schema type for -->
<complexType name="AttachmentsType">
<sequence>
<!-- the 'attachments' variable is just a series of attachment
elements -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="AttachmentType">
<all>
<!-- Set of MIME headers associated with attachment -->
<element name="Content-ID" type="string" minOccurs="0"/>
<element name="Content-Type" type="string" minOccurs="0"/>
<element name="Content-Transfer-Encoding" type="string"
minOccurs="0"/>
<element name="Content-Description" type="string" minOccurs="0"/>
<element name="Content-Location" type="string" minOccurs="0"/>
<element name="Content-Disposition" type="string" minOccurs="0"/>
<!-- any (custom) headers not specified above will be here -->
<element name="user-headers" minOccurs="0">
<complexType>
<sequence>
<element name="user-header" maxOccurs="unbounded">
<complexType>
<attribute name="name" type="string"/>
<attribute name="value" type="string"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
<!-- Contains the attachment content itself, either in-lined or as <binary-content/> -->
<element name="body" type="anyType"/>
</all>
</complexType>
<complexType name="BinaryContentType">
<!-- URI reference to the binary or pass-by-reference payload -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
<complexType name="JavaContentType">
<!-- URI reference to POJOs in object repository -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
<!-- =========================================================================== -->
<complexType name="EndpointType">
<all>
<!-- Sub-elements holding service, transport and security details for
the endpoint -->
<element ref="mc:service" minOccurs="0" />
<element ref="mc:transport" minOccurs="0" />
<element ref="mc:security" minOccurs="0" />
</all>
<!-- Fully-qualified name of the service represented by this endpoint -->
<attribute name="name" type="string" use="required"/>
</complexType>
<!-- =========================================================================== -->
<complexType name="ServiceType">
<all >
<!-- name of service provider -->
<element name="providerName" type="string" minOccurs="0"/>
<!-- the service operation being invoked -->
<element name="operation" type="string" minOccurs="0"/>
</all>
</complexType>
<!-- =========================================================================== -->
<complexType name="TransportType">
<all>
<!-- URI of endpoint -->
<element name="uri" type="anyURI" minOccurs="0" />
<!-- Transport-specific metadata for request and response (includes
transport headers) -->
<element name="request" type="anyType" minOccurs="0"/>
<element name="response" type="anyType" minOccurs="0" />
<!-- Indicates one-way (request only) or bi-directional
(request/response) communication -->
<element name="mode" type="mc:ModeType" minOccurs="0" />
<!-- Specifies the quality of service -->
<element name="qualityOfService" type="mc:QoSType" minOccurs="0" />
<!-- Retry values (outbound only) -->
<element name="retryInterval" type="integer" minOccurs="0" />
<element name="retryCount" type="integer" minOccurs="0" />
<!-- Throttling priority (outbound only) -->
<element name="priority" type="positiveInteger" minOccurs="0" />
</all>
</complexType>
<simpleType name="ModeType">
<restriction base="string">
<enumeration value="request"/>
<enumeration value="request-response"/>
</restriction>
</simpleType>
<simpleType name="QoSType">
<restriction base="string">
<enumeration value="best-effort"/>
<enumeration value="exactly-once"/>
</restriction>
</simpleType>
<!-- =========================================================================== -->
<complexType name="SecurityType">
<all>
<!-- Transport-level client information (inbound only) -->
<element name="transportClient" type="mc:SubjectType" minOccurs="0"/>
<!-- Message-level client information (inbound only) -->
<element name="messageLevelClient" type="mc:SubjectType"
minOccurs="0"/>
<!-- Boolean flag used to disable outbound WSS processing (outbound
only) -->
<element name="doOutboundWss" type="boolean" minOccurs="0"/>
</all>
</complexType>
<complexType name="SubjectType">
<sequence>
<!-- User name associated with this tranport- or message-level subject -->
<element name="username" type="string"/>
<element name="principals" minOccurs="0">
<complexType>
<sequence>
<!-- There is an element for each group this subject
belongs to, as determined by the authentication
providers -->
<element name="group" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="subject-properties" minOccurs="0" maxOccurs="1">
<complexType>
<sequence>
<element name="property" minOccurs="0"
maxOccurs="unbounded"
type="mc:SubjectPropertyType"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="SubjectPropertyType" mixed="true">
<sequence>
<any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</sequence>
<attribute name="name" type="string" use="required"/>
<anyAttribute processContents="lax"/>
</complexType>
<!-- =========================================================================== -->
<complexType name="FaultType">
<all>
<!-- A short string identifying the error (e.g. BEA38229) -->
<element name="errorCode" type="string"/>
<!-- Descriptive text explaining the reason for the error -->
<element name="reason" type="string" minOccurs="0" />
<!-- Any additional details about the error -->
<element name="details" type="anyType" minOccurs="0" />
<!-- Information about where the error occured in the proxy -->
<element name="location" type="mc:LocationType" minOccurs="0" />
<!-- Information about the exception instance reference stored in the
object repository -->
<element name="java-exception" minOccurs="0">
<complexType>
<sequence>
<element ref="mc:java-content" />
</sequence>
</complexType>
</element>
</all>
</complexType>
<simpleType name="PipelinePathType">
<restriction base="string">
<enumeration value="request-pipeline"/>
<enumeration value="response-pipeline"/>
</restriction>
</simpleType>
<complexType name="LocationType">
<all>
<!-- Name of the Pipeline/Branch/Route node where error occured -->
<element name="node" type="string" minOccurs="0" />
<!-- Name of the Pipeline where error occured (if applicable) -->
<element name="pipeline" type="string" minOccurs="0" />
<!-- Name of the Stage where error occured (if applicable) -->
<element name="stage" type="string" minOccurs="0" />
<!-- Indicates if error occured from inside an error handler -->
<element name="error-handler" type="boolean" minOccurs="0" />
<!-- Indicates whether or not error occured in request or
response path -->
<element name="path" type="mc:PipelinePathType" minOccurs="0" />
</all>
</complexType>
<!-- Encapsulates any stack-traces that may be added to a fault <details> -->
<element name="stack-trace" type="string"/>
</schema>
This example shows the error schema (Errors.xsd), which specifies the structure for errors.
This file is available in a JAR file, OSB_ORACLE_HOME/lib/servicebus-schemas.jar.
Example - Errors.xsd
<schema targetNamespace="http://www.bea.com/wli/sb/errors"
xmlns:err="http://www.bea.com/wli/sb/errors"
xmlns:tc="http://www.bea.com/wli/sb/transports"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<import namespace="http://www.bea.com/wli/sb/transports"
schemaLocation="TransportCommon.xsd" />
<element name="InvalidEnvelope">
<complexType>
<sequence>
<element name="localpart" type="NCName"/>
<element name="namespace" type="anyURI" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="WebServiceSecurityFault">
<complexType>
<sequence>
<element name="faultcode" type="QName"/>
<element name="faultstring" type="string"/>
<element name="detail" minOccurs="0">
<complexType mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</sequence>
<anyAttribute namespace="##any" processContents="lax"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
<!-- Publish error details -->
<element name="ErrorResponseDetail" type="err:ErrorResponseDetail"/>
<complexType name="ErrorResponseDetail">
<sequence>
<!-- Response metadata -->
<element name="response-metadata" type="tc:ResponseMetaDataXML" minOccurs="0" />
</sequence>
</complexType>
<!-- payload information in $fault details when parsing message into XML raises an error -->
<element name="PayloadDetail" type="err:PayloadDetail"/>
<complexType name="PayloadDetail">
<choice>
<element name="text" minOccurs="0" type="string" />
<element name="base64" minOccurs="0" type="base64Binary" />
</choice>
</complexType>
<!-- REST default (system) faults -->
<element name="RestError" type="err:RestErrorType"/>
<complexType name="RestErrorType">
<sequence>
<element name="errorMessage" minOccurs="0" type="string" />
<element name="errorCode" minOccurs="0" type="string" />
</sequence>
</complexType>
</schema>