WS-Addressing with the SOAPInput node

Various options are available when you use WS-Addressing with the SOAPInput node.

The SOAPInput node has a property for processing WS-Addressing information present in the incoming message called Use WS-Addressing.

If you select this property, the WS-Addressing information is processed and the process itself is called engaging WS-Addressing. The default is that WS-Addressing is not engaged.

You can also specify this property in the WSDL, and this property is configurable from the WSDL, automatically by the IBM® App Connect Enterprise Toolkit, when the WSDL is dropped onto the node. The behavior of the node when WS-Addressing is engaged or not engaged is as follows:
Addressing not engaged
No WS-Addressing processing is performed. If a message is received that contains any WS-Addressing headers they are ignored, and no WS-Addressing processing of any kind is performed, unless they are marked as MustUnderstand.

The inbound WS-Addressing headers in this case are visible in the message when it leaves the SOAPInput node under the Header folder of the SOAP parser in the message tree.

A fault is returned to the client if WS-Addressing headers exist in the incoming message, and they meet both of the following criteria:
  • Marked as MustUnderstand
  • Targeted at the role the SOAPInput node is operating in

Engaging WS-Addressing is how you instruct the node to 'understand' the WS-Addressing headers. In this case the WS-Addressing headers remain in the SOAP Header section of the SOAP parser, and no other SOAP node acts upon them. In all cases, they are treated as a SOAP header with no special meaning assigned to the WS-Addressing headers.

Addressing engaged:
WS-Addressing processing is performed as stated in the WS-Addressing specification. This processing means that messages that contain either submission addressing headers or final addressing headers are accepted.
A fault is returned if both submission addressing headers and final headers are present, and either of the following conditions is met:
  • Neither is marked with a role.
  • They are both marked with same role and the SOAPInput node is acting in that role.

Assuming that the WS-Addressing headers are valid and the Place WS-Addressing Headers into LocalEnvironment check box is selected on the SOAPInput node, all headers (including detectable inbound reference parameters) are removed from the inbound message tree and are placed into the local environment tree under the SOAP.Input.WSA folder. Moving the WS-Addressing headers to the local environment indicates that they have been processed by the integration node. The headers are removed from the message tree because they have been processed on input; otherwise they would not be valid if the message tree was sent out without further changes. They are stored in the local environment to allow you to inspect them.

Only reference parameters from the final specification are detectable because they have an attribute called IsReferenceParameter that allows them to be detected. Submission reference parameter headers do not have this attribute, therefore they are not detectable, and they are not moved into the local environment tree from the message tree.

You can change WS-Addressing reply headers before the SOAPReply node is reached. For more information about changing WS-Addressing information in the local environment, see WS-Addressing information in the local environment.