H Normalized Message Properties

This appendix describes normalized message properties.

This appendix includes the following sections:

Section H.1, "Introduction to Normalized Messages"
Section H.2, "Oracle BPEL Process Manager Properties"
Section H.3, "Oracle Web Services Addressing Properties"
Section H.4, "Manipulating Normalized Message Properties with bpelx Extensions"

H.1 Introduction to Normalized Messages

Header manipulation and propagation is a key business integration messaging requirement. Oracle BPEL Process Manager, Oracle Mediator, Oracle JCA 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.

Figure H-1 provides details.

Figure H-1 Properties Tab for Normalized Messages Header Properties

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

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 more information on normalized message properties, see Oracle Fusion Middleware User's Guide for Technology Adapters and Oracle Fusion Middleware User's Guide for Oracle B2B.

H.2 Oracle BPEL Process Manager Properties

Table H-1 lists all the predetermined properties of a normalized message for Oracle BPEL Process Manager.

Table H-1 Properties for Oracle BPEL Process Manager

Property Name	Propagatable (Yes/No)	Direction (Inbound /Outbound)	Data Type	Range of Valid Values	Description
`bpel.metadata`	Yes	Both	String	Any string, size limit: 1000	This contains extra information with which you want to associate the BPEL instance. Whatever was passed in is stored in the metadata column of the `cube_instance` table.
`bpel.priority`	Yes	Inbound	String that can be read into an integer	(1-10). 1 being the highest priority	Goes into the `cube_instance` priority column. Used by the system to prioritize.
`bpel.title`	No	Inbound	String	Any string, size limit: 100	Goes into the `title` column of `cube_instance` table.
`bpel.instanceIndex1`	No	Inbound	String	Any string, size limit: 100	This goes into the `ci_indexes` table (extra index for the `cube_instance`).
`bpel.instanceIndex2`	No	Inbound	String	Any string, size limit: 100	This goes into the `ci_indexes` table (extra index for `cube_instance`).
`bpel.instanceIndex3`	No	Inbound	String	Any string, size limit: 100	This goes into the `ci_indexes` table (extra index for the `cube_instance`).

H.3 Oracle Web Services Addressing Properties

Table H-2 lists all the predetermined properties of a normalized message for Web Services Addressing (WS-Addressing).

Table H-2 Properties for Oracle Web Services Addressing

Property Name	Propagatable (Yes/No)	Direction (Inbound /Outbound)	Data Type	Range of Valid Values	Description
`wsa.messageId`	No	Both	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	Both	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.replyToAddres`s	No	Both	String	URI format	Is a contract between two components communicating asynchronously.
`wsa.replyToPortType`	No	Both	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	Both	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	Both	String	URI format	This required element (whose content is of type `xs:anyURI`) conveys the value of the action property.
`wsa.to`	No	Both	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`.

H.4 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.

H.4.1 BPEL 1.1 bpelx Extensions Syntax

Example H-1 shows bpelx extensions syntax in BPEL 1.1.

Example H-1 bpelx Extensions Syntax in Normalized Message Headers 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>

H.4.2 BPEL 2.0 bpelx Extensions Syntax

Example H-2 shows bpelx extensions syntax in BPEL 2.0.

Example H-2 bpelx Extensions Syntax in Normalized Message Headers 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.