E Propagating Normalized Message Properties Through Message Headers

This appendix describes how to set normalized message properties that enable you to propagate these properties through message headers.

This appendix includes the following sections:

• Introduction to Normalized Messages

• Manipulating Normalized Message Properties with bpelx Extensions

E.1 Introduction to Normalized Messages

Header manipulation and propagation is a key business integration messaging requirement. Components such as Oracle BPEL Process Manager, Oracle Mediator, Oracle JCA adapters, REST adapters, and Oracle B2B rely extensively on header support to solve customers' integration needs. For example, you can preserve a file name from the source directory to the target directory by propagating it through message headers. In Oracle BPEL Process Manager and Oracle Mediator, you can access, manipulate, and set headers with varying degrees of user interface support.

A normalized message is simplified to have only two parts, properties and payload.

Typically, properties are name-value pairs of scalar types. To fit the existing complex headers into properties, properties are flattened into scalar types.

The user experience is simplified while manipulating headers in design time, because the complex properties are predetermined. In the Mediator Editor or Oracle BPEL Designer, you can manipulate the headers with some reserved key words.

However, this method does not address the properties that are dynamically generated based on your input. Based on your choice, the header definitions are defined. These definitions are not predetermined and therefore cannot be accounted for in the list of predetermined property definitions. You cannot design header manipulation of the dynamic properties before they are defined. To address this limitation, you must generate all the necessary services (composite entry points) and references. This restriction applies to services that are expected to generate dynamic properties. Once dynamic properties are generated, they must be stored for each composite. Only then can you manipulate the dynamic properties in the Mediator Editor or Oracle BPEL Designer.

For information about normalized message properties in JCA adapters and Oracle B2B, see Understanding Technology Adapters and User's Guide for Oracle B2B.

E.1.1 Oracle Web Services Addressing Properties

Table E-1 lists the predetermined properties of a normalized message for Web Services Addressing (WS-Addressing). The WS-Addressing headers from incoming SOAP requests are propagated within Oracle SOA Suite through the normalized message properties. However, overriding of WS-Addressing headers in the outbound SOAP message through use of these normalized message properties is not supported.

Table E-1 Properties for Oracle Web Services Addressing

Property Name	Propagatable (Yes/No)	Direction (Inbound /Outbound)	Data Type	Range of Valid Values	Description
wsa.messageId	No	Inbound	String	URI format	This property specifies the identifier for the message and the endpoint to which replies to this message should be sent as an endpoint reference.
wsa.relatesTo	No	Inbound	String	URI format	This optional (repeating) element information item contributes one abstract relationship property value, in the form of an (IRI, IRI) pair. The content of this element (of type xs:anyURI) conveys the message ID of the related message.
wsa.replyToAddress	No	Inbound	String	URI format	Represents a contract between two components communicating asynchronously.
wsa.replyToPortType	No	Inbound	QName	Any QName	This value is passed to the web service to configure the portType on the service's callback. It is translated to the WS-Addressing callback endpoint reference's PortType element.
wsa.replyToService	No	Inbound	QName	Any QName	This value is passed to the web service to configure service on the service's callback. It is translated to the WS-Addressing callback endpoint reference's ServiceName element.
wsa.action	No	Inbound	String	URI format	This required element (whose content is of type xs:anyURI) conveys the value of the action property.
wsa.to	No	Inbound	String	URI format	This optional element (whose content is of type xs:anyURI) provides the value for the destination property. If this element is not present, then the value of the (destination) property is http://www.w3.org/2005/08/addressing/anonymous.

E.1.2 How to Set Normalized Message Properties in Message Headers

To set normalized message properties in message headers:

1. In the dialog of the selected activity, click the Properties tab.

2. For BPEL 2.0 projects, perform the following tasks:

   1. Click the Add icon.

   2. From the Name list, select the property. Figure E-1 provides details.

      Figure E-1 Properties Tab for Normalized Messages Header Properties

      
      Description of "Figure E-1 Properties Tab for Normalized Messages Header Properties"

   3. Select the value of the property:

      If You Select...	Perform the Following Steps...
      Expression	Click Search to invoke the XPath Expression Builder dialog. Create the XPath expression, and click OK. Click OK.
      Variable	Click Search to invoke the Variable XPath Builder dialog. Select the variable, and click OK. Click OK.

   The defined property is displayed.

3. For BPEL 1.1 projects, perform the following tasks:

   1. Scroll down and select the property.

   2. In the Value column, double-click to display the ellipses.

   3. Click the ellipses.

      The Adapter Property Value dialog is displayed.

   4. Enter the variable name as the value, and click OK.

   5. For activities with a Type column (for example, invoke activities), click the row of the property.

   6. From the list that is displayed, select input or output for the message direction.

   7. Click Apply, then OK.

E.2 Manipulating Normalized Message Properties with bpelx Extensions

Oracle BPEL Process Manager uses bpelx extensions to manipulate normalized message properties in message exchange operations. The syntax is different based on whether your BPEL project supports BPEL version 1.1 or 2.0.

E.2.1 BPEL 2.0 bpelx Extensions Syntax

The following example shows bpelx extensions syntax in BPEL 2.0:

<invoke ...>
  <bpelx:fromProperties>?
    <bpelx:fromProperty name="NCName" .../>+
  </bpelx:fromProperties>
  <bpelx:toProperties>?
    <bpelx:toProperty name="NCName" .../>+
  </bpelx:toProperties>
</invoke>

<receive ...>
  <bpelx:fromProperties>?
    <bpelx:fromProperty name="NCName" .../>+
  </bpelx:toProperties>
</receive>

<onEvent ...>
  <bpelx:fromProperties>?
    <bpelx:fromProperty name="NCName" .../>+
  </bpelx:fromProperties>
</onEvent>

<reply...>
  <bpelx:toProperties>?
    <bpelx:toProperty name="NCName" .../>+
  </bpelx:toProperties>
</reply>

<reply ...>
  <bpelx:toProperties>
    <bpelx:toProperty name="NCName" .../>
  </bpelx:toProperties>
</reply>

Note the following details:

• The toProperty is a from-spec. This copies a value from the from-spec to the property of the given name.

• The fromProperty is a to-spec. This copies a value from the property to the to-spec.

E.2.2 BPEL 1.1 bpelx Extensions Syntax

The following example shows bpelx extensions syntax in BPEL 1.1:

<invoke ...>
  <bpelx:inputProperty name="NCName" expression="string" variable="NCName"
 part="NCName" query="string"/>*
  <bpelx:outputProperty name="NCName" expression="string" variable="NCName"
 part="NCName" query="string"/>*
</invoke>

<receive ...>
  <bpelx:property name="NCName" expression="string" variable="NCName"
 part="NCName" query="string"/>*
</receive>

<onMessage...>
  <bpelx:property name="NCName" expression="string" variable="NCName"
 part="NCName" query="string"/>*
</onMessage>

<reply ...>
  <bpelx:property name="NCName" expression="string" variable="NCName"
 part="NCName" query="string"/>*
</reply>