In a BPEL process service component, most pieces of data are in XML format. This includes the messages passed to and from the BPEL process service component, the messages exchanged with external services, and the local variables used by the process. You define the types for these messages and variables with the XML schema, usually in one of the following:

• Web Services Description Language (WSDL) file for the flow

• WSDL files for the services it invokes

• XSD file referenced by those WSDL files

Therefore, most variables in BPEL are XML data, and any BPEL process service component uses much of its code to manipulate these XML variables. This typically includes performing data transformation between representations required for different services, and local manipulation of data (for example, to combine the results from several service invocations).

BPEL also supports service data object (SDO) variables, which are not in an XML format, but rather in a memory structure format.

The starting point for data manipulation in BPEL is the assign activity, which builds on the XPath standard. XPath queries, expressions, and functions play a large part in this type of manipulation.

In addition, more advanced methods are available that involve using XQuery, XSLT, or Java, usually to do more complex data transformation or manipulation.

This section provides a general overview of how to manipulate XML data in BPEL. It summarizes the key building blocks used in various combinations and provides examples. The remaining sections in this chapter discuss and illustrate how to apply these building blocks to perform specific tasks.

You use the assign activity to copy data from one XML variable to another, or to calculate the value of an expression and store it in a variable. A copy element within the activity specifies the source and target of the assignment (what to copy from and to), which must be of compatible types.

The following example shows the formal syntax for BPEL version 1.1, as described in the Business Process Execution Language for Web Services Specification:

<assign standard-attributes>
   standard-elements
   <copy>
      from-spec
      to-spec
   </copy>
</assign>

The next example shows the formal syntax for BPEL version 2.0, as described in the Web Services Business Process Execution Language Specification Version 2.0. The keepSrcElementName attribute specifies whether the element name of the destination (as selected by the to-spec) is replaced by the element name of the source (as selected by the from-spec) during the copy operation. When keepSrcElementName is set to no (the default value), the name (that is, the namespace name and local name properties) of the original destination element is used as the name of the resulting element. When keepSrcElementName is set to yes, the source element name is used as the name of the resulting destination element.

<assign validate="yes|no"? standard-attributes>
   standard-elements
   (
   <copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>
      from-spec 
      to-spec
   </copy>
   . . .
   . . .
</assign>

This syntax is described in detail in both specifications. The from-spec and to-spec typically specify a variable or variable part, as shown in the following example:

<assign>
   <copy>
      <from variable="c1" part="address"/>
      <to variable="c3"/>
   </copy>
</assign>

When you use Oracle JDeveloper, you supply assign activity details in a Copy Rules dialog that includes a From section and a To section. This reflects the preceding BPEL source code syntax.

XPath standards play a key role in the assign activity. Brief examples are shown here as an introduction. Examples with more context and explanation are provided in the sections that follow.

• XPath queries

  An XPath query selects a field within a source or target variable part. The from or to clause can include a query attribute whose value is an XPath query string. The following code provides an example:

  <from variable="input" part="payload"
        query="/p:CreditFlowRequest/p:ssn"/>
  

  The value of the query attribute must be a location path that selects exactly one node. You can find further details about the query attribute and XPath standards syntax in the Business Process Execution Language for Web Services Specification (section 14.3) or Web Services Business Process Execution Language Specification Version 2.0 (section 8.4), and the XML Path Language (XPath) Specification, respectively.

• XPath expressions

  You use an XPath expression (specified in an expression attribute in the from clause) to indicate a value to be stored in a variable. For example:

  <from expression="100"/>
  

  The expression can be any general expression (that is, an XPath expression that evaluates to any XPath value type). Similarly, the value of an expression attribute must return exactly one node or one object only when it is used in the from clause within a copy operation. For more information about XPath expressions, see section 9.1.4 of the XML Path Language (XPath) Specification.

Within XPath expressions, you can call the following types of functions:

• Core XPath functions

  XPath supports a large number of built-in functions, including functions for string manipulation (such as concat), numeric functions (such as sum), and others.

  <from expression="concat('string one', 'string two')"/>
  

  For a complete list of the functions built into XPath standards, see section 4 of the XML Path Language (XPath) Specification.

• BPEL XPath extension functions

  BPEL adds several extension functions to the core XPath core functions, enabling XPath expressions to access information from a process.

  • For BPEL 1.1, the extensions are defined in the standard BPEL namespace http://schemas.xmlsoap.org/ws/2003/03/business-process/ and indicated by the prefix bpws:

    <from expression= "bpws:getVariableData('input', 'payload', '/p:value') + 1"/>
    

    For more information, see sections 9.1 and 14.1 of the Business Process Execution Language for Web Services Specification. For more information about getVariableData, see getVariableData.

  • For BPEL 2.0, the extensions are also defined in the standard BPEL namespace http://schemas.xmlsoap.org/ws/2003/03/business-process/. However, the prefix is bpel:

    <from>bpel:getVariableProperty('input', 'propertyName')</from>
    

    For more information, see section 8.3 of the Web Services Business Process Execution Language Specification Version 2.0. For more information about getVariableProperty, see getVariableProperty (For BPEL 2.0).

• Oracle BPEL XPath extension functions

  Oracle provides some additional XPath functions that use the capabilities built into BPEL and XPath standards for adding new functions.

  These functions are defined in the namespace http://schemas.oracle.com/xpath/extension and indicated by the prefix ora:.

• Custom functions

  Oracle BPEL Process Manager functions are defined in the bpel-xpath-functions-config.xml file and placed inside the orabpel.jar file. For more information, see Creating User-Defined XPath Extension Functions.

Sophisticated data manipulation can be difficult to perform with the BPEL assign activity and the core XPath functions. However, you can perform complex data manipulation and transformation by using XSLT, Java, or a bpelx operation under an assign activity (See Manipulating XML Data with bpelx Extensions) or as a web service. For XSLT, Oracle BPEL Process Manager and Oracle Mediator includes XPath functions that execute these transformations.

For more information about XPath and XQuery transformation code examples, see Creating Transformations with the XSLT Map Editor and Creating Transformations with the XQuery Mapper.

For more information about the assign activity, see Assign Activity.

This section describes how to create an entity variable and a binding key in Oracle JDeveloper.

In Release 10.1.x of Oracle BPEL Process Manager, all variable data was in DOM format. Starting with Release 11g and continuing with Release 12c, variable data in SDO format is also supported. DOM and SDO variables in BPEL process service components are implicitly converted to the required forms. For example, an Oracle BPEL process service component using DOM-based variables can automatically convert these variables as required to SDO-based variables in an assign activity, and vice versa. Both form types are defined in the XSD schema file. No user intervention is required.

Entity variables also support SDO-formed data. However, unlike the DOM and SDO variables, the entity variable with SDO-based data enables you to bind a unique key value to data (for example, a purchase order). Only the key is stored in the dehydration store; the data requiring conversion is stored with the service of the Oracle ADF Business Component application. The key points to the data stored in the service. When the data is required, it is fetched from the data provider service and placed into memory. The process occurs in two places: the bind entity activity and the dehydration store. For example, when Oracle BPEL Process Manager rehydrates, it stores only the key for the entity variable; when it wakes up, it does an implicit bind to get the current data.

1. Create a synchronous BPEL process.
2. In the Input field of the Create BPEL Process dialog, accept the default input XSD schema or click the Search icon to select a different XSD. For this example, the schema created with the Native Format Builder in How to Translate Native Data to XML Data is selected. Figure 6-17 provides details.

   Figure 6-17 Input Schema Selection

   
   Description of "Figure 6-17 Input Schema Selection"
3. Right-click the BPEL process in the SOA Composite Editor, and select Edit.

   Oracle BPEL Designer is displayed.

4. Expand the Oracle Extensions section of the Components window and drag a Translate activity into the BPEL process.
5. Right-click the translate activity, and select Edit.

   The Translate dialog is displayed for editing.

6. Select XML to Native to translate outbound XML data into native XSD format.
7. To the right of the Input field, click the Browse (first) icon.
8. Select the input variable. Figure 6-18 provides details.

   Figure 6-18 Input Variable Selection

   
   Description of "Figure 6-18 Input Variable Selection"
9. To the right of the NXSD Schema field, select the Search (first) icon to invoke the Type Chooser dialog.
10. Select the schema file, and click OK. This example uses the same schema file as How to Translate Native Data to XML Data. Figure 6-19 provides details.

    Figure 6-19 Schema File Selection

    
    Description of "Figure 6-19 Schema File Selection"
11. From the Output Type list, select STRING.

    If you instead select ATTACHMENT, the dialog is refreshed to display the Location field for specifying the directory location for the attachment. Selecting ATTACHMENT is useful for scenarios in which XML data is very large.

12. To the right of the Output field, click the Search (first) icon or click the Create Variable icon to automatically create a new output variable of type string.
13. Select the output variable, and click OK. Figure 6-20 provides details.

    Figure 6-20 Output Variable Selection

    
    Description of "Figure 6-20 Output Variable Selection"

    The Translate dialog looks as shown in Figure 6-21.

    Figure 6-21 Translate Dialog Configured for Outbound Translations

    
    Description of "Figure 6-21 Translate Dialog Configured for Outbound Translations"

    Design is now complete.

1. Create a BPEL process (for this example, a one-way BPEL process is created).
2. Right-click the BPEL process in the SOA Composite Editor, and select Edit.

   Oracle BPEL Designer is displayed.

3. Expand the Oracle Extensions section of the Components window and drag a Translate activity into the BPEL process.
4. Right-click the translate activity, and select Edit.

   The Translate dialog is displayed for editing.

5. Select Native to XML to translate inbound native data into an attachment.
6. To the right of the Input field, click the Browse (first) icon.
7. Select the input variable (for this example, a very large string). Figure 6-22 provides details.

   Figure 6-22 Input Variable Selection

   
   Description of "Figure 6-22 Input Variable Selection"
8. To the right of the NXSD Schema field, select the Search (first) icon to invoke the Type Chooser dialog.
9. Select the schema file, and click OK. This example uses the same schema file as How to Translate Native Data to XML Data. Figure 6-23 provides details.

   Figure 6-23 Schema File Selection

   
   Description of "Figure 6-23 Schema File Selection"
10. From the Output Type list, select ATTACHMENT.

    The dialog is refreshed to display the Location field.

11. In the Location field, enter the directory path to the attachment. If this field is left blank, the attachment is stored in the database.
12. To the right of the Output field, click the Add (second) icon to invoke the Create Variable dialog.
13. Click OK to create the output variable. The output variable is of type attachment.

    The Translate dialog looks as shown in Figure 6-24.

    Figure 6-24 Translate Dialog for an Attachment

    
    Description of "Figure 6-24 Translate Dialog for an Attachment"
14. Click OK.
15. In the Applications window, select the BPEL process file.
16. Click Source.
17. Note that the location you specified for the attachment is copied to an href attribute. The href attribute is part of the variable of type attachment that was created in Step 12.

    . . .
    <copy>
      <from> '/scratch/sbandyop/tmp/out/dhqa_addr_att.xml'</from>
      <to> $Translate1_OutputVar_1/@href</to>
    </copy>
    . . .
    

18. In the Applications window, select the BPEL process WSDL file.
19. Click Source.
20. Note the attachment code added to the WSDL definitions section of the file and the href attribute that is pointed to by the variable created in Step 12.

    . . .
    xmlns:attach="http://xmlns.oracle.com/DHQATranslateApp/DHQATranslateToAttach/BPELProcess1/attachment"
    . . .
    . . .
    . . .
       <element name="attachmentElement">
          <complexType>
             <attribute name="href" type="string"/>
          </complexType>
       </element>
    . . .
    . . .
    

    Design is now complete.

The syntax for declaring an SDO-based variable is similar to that for declaring BPEL variables. The following example provides details.

<variable name="deptVar_s" element="hrtypes:dept" />
<variable name="deptVar_v" element="hrtypes:dept" bpelx:sdoCapable="false" />

If you want to override the automatic detection, use the bpelx:sdoCapable="true|false" switch. For example, variable deptVar_v described in the preceding sample is a regular DOM-based variable. The following example shows an XSD sample:

<xsd:element name="dept" type="Dept"/>
   <xsd:complexType name="Dept"
    sdoJava:instanceClass="sdo.sample.service.types.Dept">
      <xsd:annotation>
         <xsd:appinfo source="Key"
          xmlns="http://xmlns.oracle.com/bc4j/service/metadata/">
            <key>
               <attribute>Deptno</attribute>
            </key>
            <fetchMode>minimal</fetchMode>
         </xsd:appinfo>
      </xsd:annotation>
      <xsd:sequence>
         <xsd:element name="Deptno" type="xsd:integer" minOccurs="0"/>
         <xsd:element name="Dname" type="xsd:string" minOccurs="0"
 nillable="true"/>
         <xsd:element name="Loc" type="xsd:string" minOccurs="0" nillable="true"/>
         <xsd:element name="Emp" type="Emp" minOccurs="0" maxOccurs="unbounded"
 nillable="true"/>
      </xsd:sequence>
   </xsd:complexType>

Oracle BPEL Process Manager supports dual data forms: DOM and SDO. You can interchange the usage of DOM-based and SDO-based variables within the same business process, even within the same expression. The Oracle BPEL Process Manager data framework automatically converts back and forth between DOM and SDO forms.

By using the entity variable XPath rewrite capabilities, Oracle BPEL Process Manager enables some XPath features (for example, variable reference and function calls) that the basic SDO specification does not support. However, there are other limitations on the XPath used with SDO-based variables (for example, there is no support for and, or, and not).

The following example shows XML-to-SDO conversion:

<assign>
        <copy>
            <from>
   <ns0:dept xmlns:ns0="http://sdo.sample.service/types/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <ns0:Deptno>10</ns0:Deptno>
      <ns0:Dname>ACCOUNTING</ns0:Dname>
      <ns0:Loc>NEW YORK</ns0:Loc>
      <ns0:Emp>
         <ns0:Empno>7782</ns0:Empno>
         <ns0:Ename>CLARK</ns0:Ename>
         <ns0:Job>MANAGER</ns0:Job>
         <ns0:Mgr>7839</ns0:Mgr>
         <ns0:Hiredate>1981-06-09</ns0:Hiredate>
         <ns0:Sal>2450</ns0:Sal>
         <ns0:Deptno>10</ns0:Deptno>
      </ns0:Emp>
      <ns0:Emp>
         <ns0:Empno>7839</ns0:Empno>
         <ns0:Ename>KING</ns0:Ename>
         <ns0:Job>PRESIDENT</ns0:Job>
         <ns0:Hiredate>1981-11-17</ns0:Hiredate>
         <ns0:Sal>5000</ns0:Sal>
         <ns0:Deptno>10</ns0:Deptno>
      </ns0:Emp>
      <ns0:Emp>
         <ns0:Empno>7934</ns0:Empno>
         <ns0:Ename>MILLER</ns0:Ename>
         <ns0:Job>CLERK</ns0:Job>
         <ns0:Mgr>7782</ns0:Mgr>
         <ns0:Hiredate>1982-01-23</ns0:Hiredate>
         <ns0:Sal>1300</ns0:Sal>
         <ns0:Deptno>10</ns0:Deptno>
      </ns0:Emp>
   </ns0:dept>
            </from>
            <to variable="deptVar_s" />
        </copy>
</assign>

The following example illustrates copying from an XPath expression of an SDO variable to a DOM variable:

<assign>
        <!-- copy from an XPath expression of an SDO variable to DOM variable -->
        <copy>
            <from expression="$deptVar_s/hrtypes:Emp[2]" />
            <to variable="empVar_v" />
        </copy>
        <!-- copy from an XPath expression of an DOM variable to SDO variable -->
        <copy>
            <from expression="$deptVar_v/hrtypes:Emp[2]" />
            <to variable="empVar_s" />
        </copy>
        <!-- insert a DOM based data into an SDO variable -->
        <bpelx:insertAfter>
            <bpelx:from variable="empVar_v" />
            <bpelx:to variable="deptVar_s" query="hrtypes:Emp" />
        </bpelx:insertAfter>
        <!-- insert a SDO based data into an SDO variable at particular location,
              no XML conversion is needed  -->
        <bpelx:insertBefore>
            <bpelx:from expression="$deptVar_s/hrtypes:Emp[hrtypes:Sal = 1300]" />
            <bpelx:to variable="deptVar_s" query="hrtypes:Emp[6]" />
         </bpelx:insertBefore>
</assign>

The following example shows SDO Data Removal:

<assign>
         <bpelx:remove>
            <bpelx:target variable="deptVar_s" query="hrtypes:Emp[2]" />
        </bpelx:remove>
</assign>

The following example assigns a literal result element to the payload part of the output variable:

<assign>
   <!-- copy from literal xml to the variable -->
   <copy>
      <from>
         <result xmlns="http://samples.otn.com">
            <name/>
            <symbol/>
            <price>12.3</price>
            <quantity>0</quantity>
            <approved/>
            <message/>
         </result>
      </from>
      <to variable="output" part="payload"/>
   </copy>
</assign>

The following example shows two assignments being performed, first copying between two variables of the same type and then copying a variable part to another variable with the same type as that part.

<assign>
   <copy>
      <from variable="c1"/>
      <to variable="c2"/>
   </copy>
   <copy>
      <from variable="c1" part = "address"/>
      <to variable="c3"/>
   </copy>
</assign>

The BPEL file defines the variables, as shown in the following example:

<variable name="c1" messageType="x:person"/>
<variable name="c2" messageType="x:person"/>
<variable name="c3" element="y:address"/>

The WSDL file defines the person message type, as shown in the following example:

<message name="person" xmlns:x="http://tempuri.org/bpws/example">
   <part name="full-name" type="xsd:string"/>
   <part name="address" element="x:address"/>
</message>

For more information about this code example, see Section 9.3.2 of the Business Process Execution Language for Web Services Specification. For BPEL 2.0, see Section 8.4.4 of Web Services Business Process Execution Language Specification Version 2.0 for a similar example.

For more information, see Assign Activity.

A variable can optionally be initialized by using an inline from-spec. Click the Initialize tab in the Create Variable dialog in a BPEL 2.0 project to create this type of variable. Figure 6-26 provides details.

Inline variable initializations are conceptually designed as a virtual sequence activity that includes a series of virtual assign activities, one for each variable being initialized, in the order in which they appear in the variable declarations. Each virtual assign activity contains a single virtual copy operation whose from-spec is as given in the variable initialization. The to-spec points to the variable being created. The following example provides details.

<variables>
   <variable name="tmp" element="tns:output">
     <from>
       <literal>
         <output xmlns="http://samples.otn.com/bpel2.0/ch8.1">
           <value>1000</value>
         </output>
       </literal>
     </from>
   </variable>
</variables> 

For more information, see section 8.1 of Web Services Business Process Execution Language Specification Version 2.0.

1. In the Structure window, select the variable to move to a scope activity. Figure 6-27 provides details.

   Figure 6-27 Variable to Move in the Structure Window

   
   Description of "Figure 6-27 Variable to Move in the Structure Window"

2. Drag the variable to the Variables folder of the scope activity.

   The variable is displayed in the Variables folder of the scope activity, as shown in Figure 6-28.

   Figure 6-28 Variable Moved to the Scope Activity in the Structure Window

   
   Description of "Figure 6-28 Variable Moved to the Scope Activity in the Structure Window"

3. In the BPEL process, click the Variables icon of the scope activity.

   The variable you moved is displayed, as shown in Figure 6-29.

   Figure 6-29 Moved Variable in Variables Dialog of the Scope Activity

   
   Description of "Figure 6-29 Moved Variable in Variables Dialog of the Scope Activity"

1. In the Structure window, select the variable to move to the scope activity.

2. Hold down the Ctrl key.

3. Drag the variable to the Variables folder of the scope activity.

   The variable is displayed in both Variables folders, as shown in Figure 6-30.

   Figure 6-30 Variable Copied to the Scope Activity in the Structure Window

   
   Description of "Figure 6-30 Variable Copied to the Scope Activity in the Structure Window"

In the following example, the ssn field is copied from the CreditFlow process's input message into the ssn field of the credit rating service's input message.

<assign>
   <copy>
      <from variable="input" part="payload"
         query="/tns:CreditFlowRequest/tns:ssn"/>
      <to variable="crInput" part="payload" query="/tns:ssn"/>
   </copy>
</assign>

The following example shows how the BPEL file defines message type-based variables involved in this assignment:

<variable name="input" messageType="tns:CreditFlowRequestMessage"/>
<variable name="crInput"
          messageType="services:CreditRatingServiceRequestMessage"/>

The crInput variable is used as an input message to a credit rating service. Its message type, CreditFlowRequestMessage, is defined in the CreditFlowService.wsdl file, as shown in the following example:

<message name="CreditFlowRequestMessage">
<part name="payload" element="tns:CreditFlowRequest"/>
</message>

CreditFlowRequest is defined with a field named ssn. The message type CreditRatingServiceRequestMessage is defined in the CreditRatingService.wsdl file, as shown in the following example:

<message name="CreditRatingServiceRequestMessage">
   <part name="payload" element="tns:ssn"/>
</message>

The following example shows the BPEL 2.0 syntax for how the BPEL file defines message type-based variables involved in the assignment in the first assignment example. Note that /tns:CreditFlowRequest is not required.

<copy>
   <from>$input.payload/tns:ssn</from>
   <to>$crInput.payload</to>
</copy>

A BPEL process can also use element-based variables. The following example shows how to use element-based variables in BPEL 1.1. The autoloan field is copied from the loan application process's input message into the customer field of a web service's input message.

 <assign>  
      <copy>
        <from variable="input" part="payload" 
           query="/tns:invalidLoanApplication/autoloan:
            application/autoloan:customer"/>
        <to variable="customer"/>
      </copy>
</assign>

The following example shows how to use element-based variables in BPEL 2.0.

<assign>
   <copy>
      <from>$input.payload/autoloan:application/autoloan:customer</from>
      <to>$customer</to>
   </copy>
</assign>

The following example shows how the BPEL file defines element-based variables involved in an assignment:

    <variable name="customer" element="tns:customerProfile"/>

The following example shows how to assign an XPath expression with the integer value of 100.

<assign>
   <!-- copy from integer expression to the variable -->
   <copy>
      <from expression="100"/>
      <to variable="output" part="payload" query="/p:result/p:quantity"/>
   </copy>
</assign>

In the following example, the BPEL XPath function getVariableData retrieves the value being incremented. The arguments to getVariableData are equivalent to the variable, part, and query attributes of the from clause (including the last two arguments, which are optional).

<assign>
   <copy>
      <from expression="bpws:getVariableData('input', 'payload',
          '/p:value') + 1"/>
      <to variable="output" part="payload" query="/p:result"/>
   </copy>
</assign>

You can also use $variable syntax in BPEL 1.1, as shown in the following example:

<assign>
  <copy>
    <from expression="$input.payload + 1"/>
    <to variable="output" part="payload" query="/p:result"/>
  </copy>
</assign>

The following example shows how to use $variable syntax in BPEL 2.0.

<assign>
   <copy>
      <from>$input.payload + 1</from>
      <to>$output.payload</to>
   </copy>
</assign>

The code in the following example copies a BPEL 1.1 expression evaluating from the string literal 'GE' to the symbol field within the indicated variable part. (Note the use of the double and single quotes.)

<assign>
   <!-- copy from string expression to the variable -->
   <copy>
      <from expression="'GE'"/>
      <to variable="output" part="payload" query="/p:result/p:symbol"/>
   </copy>
</assign>

The following example shows how to perform this expression in BPEL 2.0.

<assign>
   <copy>
      <from>'GE'</from>
      <to>$output.payload/p:symbol</from>
   </copy>
</assign>

For more information, see Assign Activity.

The concatenation is accomplished with the core XPath function named concat. In addition, the variable value involved in the concatenation is retrieved with the BPEL XPath function getVariableData. In the following example, getVariableData fetches the value of the name field from the input variable's payload part. The string literal 'Hello ' is then concatenated to the beginning of this value.

<assign>
   <!-- copy from XPath expression to the variable -->
   <copy>
      <from expression="concat('Hello ',
         bpws:getVariableData('input', 'payload', '/p:name'))"/>
      <to variable="output" part="payload" query="/p:result/p:message"/>
   </copy>
</assign>

Other string manipulation functions available in XPath are listed in section 4.2 of the XML Path Language (XPath) Specification.

The following example provides an example of assigning boolean values in BPEL 1.1. The XPath expression in the from clause is a call to XPath's boolean function true, and the specified approved field is set to true. The function false is also available.

<assign>
   <!-- copy from boolean expression function to the variable -->
   <copy>
      <from expression="true()"/>
      <to variable="output" part="payload" query="/result/approved"/>
   </copy>
</assign>

The following example provides an example of assigning boolean values in BPEL 2.0.

<assign>
   <copy>
      <from>true()</from> 
      <to>$output.payload/approved</to>
   </copy>
</assign>

The XPath specification recommends that you use the "true()" and "false()" functions as a method for returning boolean constant values.

If you instead use "boolean(true)" or "boolean(false)", the true or false inside the boolean function is interpreted as a relative element step, and not as any true or false constant. It attempts to select a child node named true under the current XPath context node. In most cases, the true node does not exist. Therefore, an empty result node set is returned and the boolean() function in XPath 1.0 converts an empty node set into a false result. This result can be potentially confusing.

The following example shows an example that uses the function getCurrentDate in BPEL 1.1.

<!-- execute the XPath extension function getCurrentDate() -->
<assign>
   <copy>
      <from expression="xpath20:getCurrentDate()"/>
      <to variable="output" part="payload"
         query="ns1:invoice/invoiceDate"/>
   </copy>
</assign>

The following example shows an example that uses the function getCurrentDate in BPEL 2.0.

<assign>
   <copy>
      <from>xpath20:getCurrentDate()</from>
      <to>$output.payload/invoiceDate</to>
   </copy>
</assign>

In the following example, the formatDate function converts the date-time value provided in XSD format to the string 'Jun 10, 2005' (and assigns it to the string field formattedDate).

<!-- execute the XPath extension function formatDate() -->
<assign>
   <copy>
      <from expression="ora:formatDate('2005-06-10T15:56:00',
         'MMM dd, yyyy')"/>
      <to variable="output" part="payload"
         query="ns1:invoice/formattedDate"/>
   </copy>
</assign>

The following example shows how the formatDate function works in BPEL 2.0.

<assign>
   <copy>
      <from>ora:formatDate('2005-06-10T15:56:00','MMM dd, yyyy')</from>
      <to>$output.payload/formattedDate</to>
   </copy>
</assign>

The code in the following example fetches and copies the custId attribute from this XML data:

   <invalidLoanApplication xmlns="http://samples.otn.com">
      <application xmlns = "http://samples.otn.com/XPath/autoloan">
         <customer custId = "111" >
            <name>
               Mike Olive
            </name>
            ...
         </customer>
         ...
      </application>
   </invalidLoanApplication>

The BPEL 1.1 code in the following example selects the custId attribute of the customer field and assigns it to the variable custId:

<assign>
   <!-- get the custId attribute and assign to variable custId -->
   <copy>
      <from variable="input" part="payload"
         query="/tns:invalidLoanApplication/autoloan:application
                /autoloan:customer/@custId"/>
      <to variable="custId"/>
   </copy>
</assign>

The following example shows the equivalent syntax in BPEL 2.0 for selecting the custId attribute of the customer field and assigning it to the variable custId:

<assign>
<copy>
<from>$input.payload/autoloan:application/autoloan:customer/@custId</from>
<to>$custId</to>
</copy>
</assign>

The namespace prefixes in this example are not integral to the example.The WSDL file defines a customer to have a type in which custId is defined as an attribute, as shown in the following example:

<complexType name="CustomerProfileType">
   <sequence>
      <element name="name" type="string"/>
      ...
   </sequence>
   <attribute name="custId" type="string"/>
</complexType>

The bpelx:append extension in an assign activity enables a BPEL process service component to append the contents of one variable, expression, or XML fragment to another variable's contents. To use this extension, perform one of the following steps at the bottom of the Copy Rules tab:

• For BPEL 1.1, select a copy rule, then select Append from the dropdown list, as shown in Figure 6-31.

• For BPEL 2.0, right-click a copy rule, select Change rule type, and then select Append, as shown in Figure 6-32.

<bpel:assign> 
   <bpelx:append>
      <bpelx:from ... /> 
      <bpelx:to ... /> 
   </bpelx:append> 
</bpel:assign> 

<bpel:assign>
    <bpelx:append>
          <bpelx:from variable="billOfMaterialVar" 
                query="/b:bom/b:parts/b:part" />
          <bpelx:to variable="consolidatedBillOfMaterialVar"
                query="/b:bom/b:parts" />
    </bpelx:append> 
</bpel:assign>

<bpel:assign>
   <bpelx:append>
      <bpelx:from>$billOfMaterialVar/b:parts/b:part</bpelx:from>
      <bpelx:to>$consolidatedBillOfMaterialVar/b:parts</bpelx:from>
   </bpelx:append>
</bpel:assign>

The bpelx:insertBefore extension in an assign activity enables a BPEL process service component to insert the contents of one variable, expression, or XML fragment before another variable's contents. To use this extension, perform one of the following steps at the bottom of the Copy Rules tab:

• For BPEL 1.1, select a copy rule, then select InsertBefore from the dropdown list, as shown in Figure 6-31.

• For BPEL 2.0, right-click a copy rule, select Change rule type, and then select InsertBefore, as shown in Figure 6-32.

<bpel:assign> 
   <bpelx:insertBefore>
      <bpelx:from ... /> 
      <bpelx:to ... /> 
   </bpelx:insertBefore> 
</bpel:assign>

<a:usAddress>
       <a:state>CA</a:state>
       <a:zipcode>94065</a:zipcode> 
</a:usAddress> 

<bpel:assign>
    <bpelx:insertBefore>
        <bpelx:from>
             <a:city>Redwood Shore></a:city>
        </bpelx:from> 
        <bpelx:to "addrVar" query="/a:usAddress/a:state" /> 
    </bpelx:insertBefore> 
</bpel:assign> 

<a:usAddress>
       <a:city>Redwood Shore</a:city>
       <a:state>CA</a:state>
       <a:zipcode>94065</a:zipcode> 
</a:usAddress> 

<assign>
   <extensionAssignOperation>
      <bpelx:insertBefore>
         <bpelx:from>
            <bpelx:literal>
               <a:city>Redwood Shore></a:city>
            </bpelx:literal>
         </bpelx:from>
         <bpelx:to>$addrVar/a:state</bpelx:to>
         </bpelx:insertBefore>
   </extensionAssignOperation>
</assign>

The bpelx:insertAfter extension in an assign activity enables a BPEL process service component to insert the contents of one variable, expression, or XML fragment after another variable's contents. To use this extension, perform one of the following steps at the bottom of the Copy Rules tab:

• For BPEL 1.1, select a copy rule, then select InsertAfter from the dropdown list, as shown in Figure 6-31.

• For BPEL 2.0, right-click a copy rule, select Change rule type, and then select InsertAfter, as shown in Figure 6-32.

<bpel:assign> 
    <bpelx:insertAfter>
       <bpelx:from ... /> 
       <bpelx:to ... /> 
    </bpelx:insertAfter> 
</bpel:assign>

<a:usAddress>
       <a:addressLine>500 Oracle Parkway</a:addressLine> 
       <a:state>CA</a:state>
       <a:zipcode>94065</a:zipcode> 
</a:usAddress>

<bpel:assign>
    <bpelx:insertAfter>
        <bpelx:from>
             <a:addressLine>Mailstop 1op6</a:addressLine>
        </bpelx:from> 
        <bpelx:to "addrVar" query="/a:usAddress/a:addressLine[1]" /> 
    </bpelx:insertAfter> 
</bpel:assign> 

<a:usAddress>
       <a:addressLine>500 Oracle Parkway</a:addressLine> 
       <a:addressLine>Mailstop 1op6</a:addressLine>
       <a:state>CA</a:state>
       <a:zipcode>94065</a:zipcode> 
</a:usAddress>

<assign>
   <extensionAssignOperation>
      <bpelx:insertAfter>
         <bpelx:from>
            <bpelx:literal>
               <a:addressLine>Mailstop 1op6</a:addressLine>
            </bpelx:literal>
         </bpelx:from>
<bpelx:to>$addrVar/a:addressLine[1]</bpelx:to>
      </bpelx:insertAfter>
   </extensionAssignOperation>
</assign>

The bpelx:remove extension in an assign activity enables a BPEL process service component to remove a variable. In Oracle BPEL Designer, you add the bpelx:remove extension by dragging the remove icon in the upper right corner of the Copy Rules tab to the target variable you want to remove, and releasing the cursor. You can also drag this icon to the center canvas to invoke a dialog, specify the rule, save and close the dialog, and then drag the icon to the target node. Figure 6-33 provides details.

After releasing the cursor, the bpelx:remove extension is applied to the target variable. Figure 6-34 provides details.

<bpel:assign> 
    <bpelx:remove>
       <bpelx:target variable="ncname" part="ncname"? query="xpath_str" />
    </bpelx:remove> 
</bpel:assign>

<a:usAddress>
       <a:addressLine>500 Oracle Parkway</a:addressLine> 
       <a:addressLine>Mailstop 1op6</a:addressLine>
       <a:state>CA</a:state>
       <a:zipcode>94065</a:zipcode> 
</a:usAddress>

<bpel:assign>
    <bpelx:remove>
        <target variable="addrVar" 
            query="/a:usAddress/a:addressLine[2]" />
    </bpelx:remove> 
</bpel:assign> 

<bpel:assign>
    <bpelx:remove>
        <target variable="addrVar" 
            query="/a:usAddress/a:addressLine" />
    </bpelx:remove> 
</bpel:assign>

<assign>
   <extensionAssignOperation>
      <bpelx:remove>
         <bpelx:target>$ncname.ncname/xpath_str</bpelx:target>
      </bpelx:remove>
   </extensionAssignOperation>
</assign>

The bpelx:rename extension in an assign activity enables a BPEL process service component to rename an element through use of XSD type casting. In Oracle BPEL Designer, you add the bpelx:rename extension by dragging the rename icon in the upper right corner of the Copy Rules tab to the target variable you want to rename, and releasing the cursor. The rename icon displays to the right of the remove icon shown in Figure 6-33. After releasing the cursor, the Rename dialog is displayed for renaming the target variable. You can also drag this icon to the center canvas to invoke this dialog, specify the name, save and close the dialog, and then drag the icon to the target node.

<bpel:assign>
    <bpelx:rename elementTo="QName1"? typeCastTo="QName2"?>
       <bpelx:target variable="ncname" part="ncname"? query="xpath_str" />
    </bpelx:rename> 
</bpel:assign>

<e:empList>
    <e:emp>
        <e:firstName>John</e:firstName><e:lastName>Dole</e:lastName>
    <e:emp>
    <e:emp xsi:type="e:ManagerType">
        <e:firstName>Jane</e:firstName><e:lastName>Dole</e:lastName>
        <e:approvalLimit>3000</e:approvalLimit>
        <e:managing /> 
    <e:emp>
    <e:emp>
        <e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
    <e:emp>
    <e:emp>
        <e:firstName>Mary</e:firstName><e:lastName>Smith</e:lastName>
    <e:emp>
</e:empList>

<bpel:assign>
    <bpelx:rename typeCastTo="e:ManagerType">
       <bpelx:target variable="empListVar" 
            query="/e:empList/e:emp[./e:firstName='Peter' and
 ./e:lastName='Smith'" />
    </bpelx:rename> 
</bpel:assign>

<e:empList>
    <e:emp>
        <e:firstName>John</e:firstName><e:lastName>Dole</e:lastName>
    <e:emp>
    <e:emp xsi:type="e:ManagerType">
        <e:firstName>Jane</e:firstName><e:lastName>Dole</e:lastName>
        <e:approvalLimit>3000</e:approvalLimit>
        <e:managing /> 
    <e:emp>
    <e:emp xsi:type="e:ManagerType">
        <e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
    <e:emp>
    <e:emp>
        <e:firstName>Mary</e:firstName><e:lastName>Smith</e:lastName>
    <e:emp>
</e:empList>

<bpel:assign>
    <bpelx:rename typeCastTo="e:ManagerType">
       <bpelx:target variable="empListVar" 
            query="/e:empList/e:emp[./e:firstName='Peter' and
 ./e:lastName='Smith'" />
    </bpelx:rename> 
    <bpelx:append>
       <bpelx:from>
          <e:approvalLimit>2500</e:approvalLimit>
          <e:managing /> 
       </bpelx:from>
       <bpelx:to variable="empListVar" 
            query="/e:empList/e:emp[./e:firstName='Peter' and
 ./e:lastName='Smith'" />
    </bpelx:append> 
</bpel:assign>

<e:emp xsi:type="e:ManagerType">
     <e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
     <e:approvalLimit>2500</e:approvalLimit>
     <e:managing /> 
<e:emp>

 <bpel:assign>
   <extensionAssignOperation>
      <bpelx:rename elementTo="QName1"? typeCastTo="QName2"?>
         <bpelx:target>$ncname[.ncname][/xpath_str]</bpelx:target>
      </bpelx:rename>
   </extensionAssignOperation>
</bpel:assign>

The bpelx:copyList extension in an assign activity enables a BPEL process service component to perform a copyList operation of the contents of one variable, expression, or XML fragment to another variable. To use this extension, perform one of the following steps at the bottom of the Copy Rules tab:

• For BPEL 1.1, select a copy rule, then select CopyList from the dropdown list, as shown in Figure 6-31.

• For BPEL 2.0, right-click a copy rule, select Change rule type, and then select CopyList, as shown in Figure 6-32.

<bpel:assign> 
    <bpelx:copyList>
       <bpelx:from ... />
       <bpelx:to ... /> 
    </bpelx:copyList>
</bpel:assign>

<schema attributeFormDefault="unqualified"
        elementFormDefault="qualified"
        targetNamespace="http://xmlns.oracle.com/Event_jws/Event/EventTest"
        xmlns="http://www.w3.org/2001/XMLSchema">
        <element name="process">
                <complexType>
                        <sequence>
                                <element name="payload" type="string"
                                  maxOccurs="unbounded"/>
                        </sequence>
                </complexType>
        </element>
        <element name="processResponse">
                <complexType>
                        <sequence>
                                <element name="payload" type="string"
                                   maxOccurs="unbounded"/>
                        </sequence>
                </complexType>
        </element>
</schema> 

<ns1:process xmlns:ns1="http://xmlns.oracle.com/Event_jws/Event/EventTest">
            <ns1: payload >a</ns1: payload >
            <ns1: payload >b</ns1: payload >
</ns1:process> 

<ns1:processResponse xmlns:ns1="http://xmlns.oracle.com/Event_
 jws/Event/EventTest">
            <ns1: payload >c</ns1: payload >
</ns1:process>

<assign>
      <bpelx:copyList>
        <bpelx:from variable="inputVariable" part="payload"
              query="/client:process/client:payload"/>
        <bpelx:to variable="outputVariable" part="payload"
            query="/client:processResponse/client:payload"/>
      </bpelx:copyList>
</assign>

<ns1:processResponse xmlns:ns1="http://xmlns.oracle.com/Event_
 jws/Event/EventTest">
            <ns1: payload >a</ns1: payload >
            <ns1: payload >b</ns1: payload >
</ns1:process> 

<assign>
   <extensionAssignOperation>
      <bpelx:copyList>
         <bpelx:from>$inputVariable.payload/client:payload</bpelx:from>
         <bpelx:to>$outputVariable.payload/client:payload</bpelx:to>
      </bpelx:copyList>
   </extensionAssignOperation>
</assign>

You can assign the following attributes to copy rules in an assign activity.

• ignoreMissingFromData

• insertMissingToData

• keepSrcElementName

At the bottom of the Copy Rules tab of an assign activity, you right-click a selected copy rule to display a menu for choosing the appropriate attribute. Figure 6-35 provides details.

<copy bpelx:ignoreMissingFromData="yes|no"/>

<copy ignoreMissingFromData="yes|no"/>

<copy bpelx:insertMissingToData="yes|no"/>

<copy bpelx:insertMissingToData="yes|no"/>

<copy keepSrcElementName="yes|no"/>

This section discusses validating XML data in BPEL 2.0.

This section describes validating xml data in BPEL 1.1.

1. Note that the receive activity in Figure 6-36 includes a standard inputVariable variable from the client.

   Figure 6-36 Receive Activity

   
   Description of "Figure 6-36 Receive Activity"
2. Note the Arguments Mapping button at the bottom of the reply activity in Figure 6-37. You can set the value for each message part by clicking an entry in the table.

   Figure 6-37 Arguments Mapping Section Defined at Bottom of a Reply Activity

   
   Description of "Figure 6-37 Arguments Mapping Section Defined at Bottom of a Reply Activity"

The following two examples illustrate how to use XPath functionality to select a data sequence element when the index of the element you want is known at design time. In these cases, it is the first element.

In the following example, addresses[1] selects the first element of the addresses data sequence:

<assign>
   <!-- get the first address and assign to variable address -->
   <copy>
      <from variable="input" part="payload"
         query="/tns:invalidLoanApplication/autoloan:application
                /autoloan:customer/autoloan:addresses[1]"/>
      <to variable="address"/>
   </copy>
</assign>

In this query, addresses[1] is equivalent to addresses[position()=1], where position is one of the core XPath functions (see sections 2.4 and 4.1 of the XML Path Language (XPath) Specification). The query in the following example calls the position function explicitly to select the first element of the address's data sequence. It then selects that address's street element (which the activity assigns to the variable street1).

<assign>
   <!-- get the first address's street and assign to street1 -->
   <copy>
      <from variable="input" part="payload"
         query="/tns:invalidLoanApplication/autoloan:application
                /autoloan:customer/autoloan:addresses[position()=1]
                /autoloan:street"/>
      <to variable="street1"/>
   </copy>
</assign>

If you review the definition of the input variable and its payload part in the WSDL file, you go several levels down before coming to the definition of the addresses field. There you see the maxOccurs="unbounded" attribute. The two XPath indexing methods are functionally identical; you can use whichever method you prefer.

Oracle SOA Suite provides support for SOAP RPC-encoded arrays. This support enables Oracle BPEL Process Manager to operate as a client calling a SOAP web service (RPC-encoded) that uses a SOAP 1.1 array.

The following example provides an example of a SOAP array payload named myFavoriteNumbers.

<myFavoriteNumbers SOAP-ENC:arrayType="xsd:int2">
<number>3</number>
<number>4</number>
</myFavoriteNumbers>

In addition, ensure that the schema element attributes attributeFormDefault and elementFormDefault are set to "unqualified" in your schema. The following example provides details:

attributeFormDefault="unqualified" elementFormDefault="unqualified"
targetNamespace="java:services" xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

The following features are not supported:

• A service published by BPEL that uses a SOAP array

• Partially-transmitted arrays

• Sparse arrays

• Multidimensional arrays

<assign name="Assign_1">
   <copy>
      <from>$inputVariable.payload</from>
      <to>$Invoke_1_echoArray_InputVariable.strArray/JavaLangstring[1]</to>
   </copy>
   <extensionAssignOperation>
      <bpelx:append>
         <bpelx:from variable="Invoke_1_echoArray_InputVariable"
            part="strArray">
            <bpelx:query>
               JavaLangstring[1]
            </bpelx:query>
         </bpelx:from>
         <bpelx:to variable="Invoke_1_echoArray_InputVariable"
            part="strArray">
         </bpelx:to>
         </bpelx:append>
    </extensionAssignOperation>
   </assign>

<invoke name="Invoke1" partnerLink="FileOut"
   portType="ns3:Write_ptt" operation="Write"
   bpelx:invokeAsDetail="no">
   <toParts>
      <toPart part="body" fromVariable="ArrayVariable"/>
   </toParts>
</invoke>

<xsd:complexType name="UserObject">
    <xsd:sequence>
        <xsd:element name="userInformation" nillable="true"
          type="n5:ArrayOfKeyValuePair"/>
        <xsd:element name="username" nillable="true" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ArrayOfKeyValuePair">
    <xsd:complexContent>
        <xsd:restriction base="soapenc:Array">
            <xsd:attribute ref="soapenc:arrayType"
             wsdl:arrayType="n5:KeyValuePair[]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>
   
<xsd:complexType name="KeyValuePair">
    <xsd:sequence>
        <xsd:element name="key" nillable="true" type="xsd:string"/>
        <xsd:element name="value" nillable="true" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

<bpws:copy>
    <bpws:from>
       <ns1:userInformation soapenc:arrayType="com1:KeyValuePair[1]"
       xmlns:ns1="http://www.schematargetnamespace.com/wsdl/Impl/"
         xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"/>
         <ns1:KeyValuePair
            xmlns:ns1="http://www.schematargetnamespace.com/wsdl/Impl/">
            <key>testkey</key>
            <value>testval1</value>
          </ns1:KeyValuePair>
       </ns1:userInformation>
    </bpws:from>
    <bpws:to variable="Inputvar" part="userObject"
             query="/userObject/userInformation"/>

</bpws:copy>
<!--Update elements with SOAPENC Array-->
<bpws:copy>
    <bpws:from variable="KeyValueVar" part="KeyValuePair"
                query="/KeyValuePair/ns2:key"/>
    <bpws:to variable="Inputvar" part="userObject'
 query="//*[local-name()='KeyValuePair'][1]/*[local-name()='key']"/>
</bpws:copy>

<bpws:copy>
    <bpws:from variable="KeyValueVar" part="KeyValuePair"
                query="/KeyValuePair/client:value"/>
    <bpws:to variable="Inputvar" part="userObject"
   query="//*[local-name()='KeyValuePair'][1]/*[local-name()='value']"/>

</bpws:copy>
<!-- Append elements within SOAPENC Array -->
<bpelx:append>
    <bpelx:from variable="Inputvar" part="userObject"
                query="//*[local-name()='KeyValuePair'][1]"/>
    <bpelx:to variable="Inputvar" part="userObject"
              query="/userObject/userInformation"/>
</bpelx:append>

If you must know the runtime size of a data sequence (that is, the number of nodes or data items in the sequence), you can get it by using the combination of the XPath built-in count() function and the BPEL built-in getVariableData() function.

The code in the following example calculates the number of elements in the item sequence and assigns it to the integer variable lineItemSize.

<assign>
   <copy>
      <from expression="count(bpws:getVariableData('outpoint', 'payload',
                        '/p:invoice/p:lineItems/p:item')"/>
      <to variable="lineItemSize"/>
   </copy>
</assign>

Often a dynamic value is needed to index into a data sequence; that is, you must get the nth node out of a sequence, where the value of n is defined at runtime. This section covers the methods for dynamically indexing by applying a trailing XPath into expressions.

<variable name="idx" type="xsd:integer"/>
...
<assign>
  <copy>
    <from expression="bpws:getVariableData('input','payload'
       )/p:line-item[bpws:getVariableData('idx')]/p:line-total" />
    <to variable="lineTotalVar" />
  </copy>
</assign> 

<from expression="bpws:getVariableData('input','payload'
       )/p:line-item[2]/p:line-total" />

bpws:getVariableData('input', 'payload','/p:invoice/p:line-item[2]/p:line-total')

bpws:getVariableData('input', 'payload')/p:line-item[2]/p:line-total

    <assign name="assign-3">
        <copy>
            <from expression="bpws:getVariableData('idx')+1" />
            <to variable="idx"/>
        </copy>
        <bpelx:append>
            <bpelx:from variable="partInfoResultVar" part="payload" />
            <bpelx:to variable="output" part="payload" />
        </bpelx:append>
        ...
    </assign>

<assign>
    <!-- initialize "mergedLineItems" variable
         to an empty element -->
    <copy>
        <from> <p:lineItems /> </from>
        <to variable="mergedLineItems" />
    </copy>
    <bpelx:append>
          <bpelx:from variable="input" part="payload"
                query="/p:invoice/p:lineItems/p:lineitem" />
          <bpelx:to variable="mergedLineItems" />
    </bpelx:append>
    <bpelx:append>
          <bpelx:from variable="literalLineItems"
                query="/p:lineItems/p:lineitem" />
          <bpelx:to variable="mergedLineItems" />
    </bpelx:append>
</assign>

genEmptyElem('ElemQName',int?, 'TypeQName'?, boolean?)

<bpelx:assign> 
    <bpelx:append>
        <bpelx:from expression="ora:genEmptyElem('p:lineItem',10)" />
        <bpelx:to variable="poVar" query="/p:po" /> 
    </bpelx:append>
</bpelx:assign>

ora:genEmptyElem('p:lineItem',10) 
== for $i in (1 to 10) return <p:lineItem />

For processing in Native Format Builder array identifier environments, information is required about the parent node of a node. Because the reportSAXEvents API is used, this information is typically not available for outbound message scenarios. Setting nxsd:useArrayIdentifiers to true in the native schema enables DOM-parsing to be used for outbound message scenarios. Use this setting cautiously, as it can lead to slower performance for very large payloads. The following example provides details.

<?xml version="1.0" ?> 

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
            targetNamespace="http://xmlns.oracle.com/pcbpel/demoSchema/csv" 
            xmlns:tns="http://xmlns.oracle.com/pcbpel/demoSchema/csv" 
            elementFormDefault="qualified" 
            attributeFormDefault="unqualified" nxsd:encoding="US-ASCII"   
nxsd:stream="chars" nxsd:version="NXSD" nxsd:useArrayIdentifiers="true"> 
  <xsd:element name="Root-Element"> 
  .... 
  </xsd:element> 
</xsd:schema> 

The parseEscapedXML function takes XML data, parses it through DOM, and returns structured XML data that can be assigned to a typed BPEL variable. The following provides an example:

<!-- execute the XPath extension function
parseEscapedXML('&lt;item&gt;') and assign to a variable
-->
<assign>
   <copy>
      <from expression="oratext:parseEscapedXML(
         '&lt;item xmlns=&quot;http://samples.otn.com&quot;
                   sku=&quot;006&quot;&gt;
          &lt;description&gt;sun ultra sparc VI server
          &lt;/description&gt;
          &lt;price&gt;1000
          &lt;/price&gt;
          &lt;quantity&gt;2
          &lt;/quantity&gt;
          &lt;lineTotal&gt;2000
          &lt;/lineTotal&gt;
          &lt;/item&gt;')"/>
      <to variable="escapedLineItem"/>
   </copy>
</assign>

This differs from the previous information in this chapter because there is a difference in how XPath queries are constructed for the two WSDL message styles. For an RPC-style message, the top-level element (and therefore the first node in an XPath query string) is the part name (payload in the previous example). In document-style messages, the top-level node is the element name (for example, loanApplication).

The following examples (WSDL file and BPEL file) show what an XPath query string looks like if an application named LoanServices were in RPC style.

<message name="LoanServiceResultMessage">
   <part name="payload" type="s1:LoanOfferType"/>
</message>

<complexType name="LoanOfferType">
   <sequence>
      <element name="providerName" type="string"/>
      <element name="selected" type="boolean"/>
      <element name="approved" type="boolean"/>
      <element name="APR" type="double"/>
   </sequence>
</complexType>

<variable name="output"
          messageType="tns:LoanServiceResultMessage"/>
...
<assign>
   <copy>
      <from expression="9.9"/>
      <to variable="output" part="payload" query="/payload/APR"/>
   </copy>
</assign>

1. Create a WSDL file that declares header messages and the SOAP binding that binds them to the SOAP request. The following provides an example:

     <!-- custom header -->
     <message name="CustomHeaderMessage">
       <part name="header1" element="tns:header1"/>
       <part name="header2" element="tns:header2"/>
     </message>
   
     <binding name="HeaderServiceBinding" type="tns:HeaderService">
       <soap:binding style="document"
         transport="http://schemas.xmlsoap.org/soap/http"/>
       <operation name="initiate">
         <soap:operation style="document" soapAction="initiate"/>
           <input>
             <soap:header message="tns:CustomHeaderMessage"
               part="header1" use="literal"/>
             <soap:header message="tns:CustomHeaderMessage"
               part="header2" use="literal"/>
             <soap:body use="literal"/>
           </input>
       </operation>
     </binding>
   

2. Create a BPEL source file that declares the header message variables and uses bpelx:headerVariable to receive the headers, as shown in the following example:

   <variables>  <variable name="input"
                messageType="tns:HeaderServiceRequestMessage"/>
     <variable name="event"
                messageType="tns:HeaderServiceEventMessage"/>
     <variable name="output"
                messageType="tns:HeaderServiceResultMessage"/>
     <variable name="customHeader"
                messageType="tns:CustomHeaderMessage"/>
   </variables>
   
   <sequence>
     <!-- receive input from requester -->
     <receive name="receiveInput" partnerLink="client" 
       portType="tns:HeaderService" operation="initiate" 
       variable="input"
       bpelx:headerVariable="customHeader"
    createInstance="yes"/>

1. Define a reference in the composite.xml file to refer to the HeaderService.
2. Define the custom header variable, manipulate it, and send it using bpelx:inputHeaderVariable, as shown in the following example:

   <variables>
     <variable name="input" messageType="tns:HeaderTestRequestMessage"/>
     <variable name="output" messageType="tns:HeaderTestResultMessage"/>
     <variable name="request" messageType="services:HeaderServiceRequestMessage"/>
     <variable name="response" messageType="services:HeaderServiceResultMessage"/>
     <variable name="customHeader"messageType="services:CustomHeaderMessage"/>
       </variables>
   ...
   <!-- initiate the remote process -->
     <invoke name="invokeAsyncService"
       partnerLink="HeaderService"
       portType="services:HeaderService" 
       bpelx:inputHeaderVariable="customHeader"
       operation="initiate"
       inputVariable="request"/>

1. In a BPEL 2.0 process, click the Extensions icon above Oracle BPEL Designer.

   The Extensions dialog is displayed.

2. Select the Extensions folder, then click the Add icon.

   The Extension dialog is displayed.

3. In the Namespace field, enter the extension namespace to declare. This namespace must be different from the standard BPEL namespace.
4. If you want the extensions to be recognized by the BPEL process, select the Must Understand check box.
5. Click OK.
6. Click Close.

After you complete your design, the .bpel process looks as shown in the following example:

<extensions>
   <extension namespace="http://xmlns.mycompany.com/myNamespace"
    mustUnderstand="yes"/>
</extensions>