Process Developer > Part II: Creating and Modifying Processes > Data Manipulation > Selecting XPath or XQuery for Expression Building

Selecting XPath or XQuery for Expression Building

The default language is XQuery, which is a superset of XPath. Process Developer projects contain an XQuery nature, including an XQuery editor for writing custom function XQuery modules.

The following table provides a brief comparison between XPath and XQuery as used in BPEL data mapping:

XPath	XQuery
Recommended if portability is an issue. Language is supported by WS-BPEL 2.0	Process Developer extension for BPEL
May be more suitable for multiple-part message variables	Builds large documents easily from a single-part variable
Limited to expression evaluation of one document node at a time	Allows manipulation of data from an entire XML document
	Better at date handling, with many date functions
Location path expressions resolve to a string	Queries generate an XML result
Location path expressions resolve to a string	Similar to a SQL-like query language. Easier to iterate over repeating elements with "FLWOR expressions" (FOR, LET, WHERE, ORDER BY, and RETURN) for performing joins

Example XQuery Expressions

If you select the XQuery expression language, you can use the many functions that are supported by XQuery in addition to all XPath expression building. The additional XQuery function categories include Date, QName, Misc, and Constructor.

You can then create expressions for the document, as the following example shows:

Note the syntax used to generate the contents of an element, such as the following from the example above:

<aem:replyTo>{$runtimeParameters/param:emailAddress/text()}</aem:replyTo>

You must add the text() function to the end of the path. Any time an XQuery expression results in an element, you must add text() to get the contents of the element.

The path without /text() would result in the following:

<aem:replyTo>
<emailAddress>reply@example.org</emailAddress>
</aem:replyTo>

instead of the desired result:

<aem:replyTo>reply@example.org</aem:replyTo>

If the expression contains just a simple value and not an XML element, the expression results to the contents. For example, the following expression results in a string:

Please use the Claim #: {$refNumber}

Example XPath Expressions

The following are example expressions for message, element and complex schema type variables.

•Element type variable:

Example: $AStatus/e:statusDescription

Selects the statusDescription child node of AStatus element

•Message type variable:

Example: $StatusVariable.StatusPart2/e:statusDescription

Selects the statusDescription child node of the StatusPart2 part of StatusVariable

•Schema complex type variable:

Example: $Results/e:AuctionResult[2]/@AuctionID

Selects the AuctionID attribute of the second AuctionResult child node

•Expression statement itemsShipped = itemsShipped + itemsCount:

$itemsShipped + $shipnotice.props/itemsCount

•Convert a variable and part to a string:

string($input.parameters)

•Referencing a child node by localname only

This can be useful when a schema has an xsd:any element in it, such as:

<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/>

The Expression Builder doesn't show the structure in the variable tree view. To use the element, the namespace prefix can be ignored as in this example:

$creditInformation/*[local-name()=
"previousLoanApplicationAttempts"][1]
/*[local-name()="applicationDate"]

Selects the date of the first previous loan application, if information about previous loan applications is supplied as additional content for the creditInformation message.