The following topics provide reference information about order recognition rule XQuery expressions:
This topic describes how to use the Order Recognition Rule editor Recognition Rule area XQuery tab to write an expression that specifies a customer order and associates it with an OSM target order type. The XQuery has the following characteristics:
Context: The input document for the Recognition Rule XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: You can declare the namespace for the customer order if you want to use the contents of the order as part of the recognition rule or you can omit the declaration if you only want to check the incoming customer order namespace. For example:
declare namespace im="http://xmlns.oracle.com/InputMessage";
Body: You must match the namespace you want to select for order processing with the namespace of the incoming customer order. For example, the following expression retrieves the namespace URI from the incoming customer order (fn:namespace-uri(.)) and compares it with this URI: 'http://xmlns.oracle.com/InputMessage':
fn:namespace-uri(.) = 'http://xmlns.oracle.com/InputMessage'
If you have declared a namespace in the prolog, you can also check to see if specific values exist in the order. For example, you can use the fn:exists function to check that an element exists. Or you can use a comparison expression such as = (equal to) or != (not equal to) to compare a value in the customer order with a value in the XQuery.
Tip:
Recognition rules are global entities within OSM, meaning that they can apply to any CreateOrder operation. Configure the relevancy settings and the recognition rule carefully to avoid having an incoming customer order recognized by a recognition rule that you do not intend. For more information about relevancy, see OSM Modeling Guide.For example, in a simple scenario, the XQuery is based on a namespace:
fn:namespace-uri(.) = 'http://xmlns.oracle.com/InputMessage'
The input message XML file includes the following line, which matches the namespace specified in the recognition rule:
<im:order xmlns:im="http://xmlns.oracle.com/InputMessage"
The XQuery expression returns a Boolean expression, for example, fn:true() or fn:false()
The following example searches in a specific type of order:
fn:namespace-uri(.) = 'http://xmlns.oracle.com/communications/sce/dictionary/CentralOMManagedServices-Orchestration/CustomerSalesOrder'
In a more complicated scenario, you might create an XQuery expression that looks for a specific namespace and also interrogates the data within the incoming customer order. The following example shows a recognition rule that recognizes an order based on the following criteria:
Namespace
Value of the typeCode data element in the incoming customer order. In this case, the value must be OSM-BDB. This indicates an OSM business-to-business order.
The value of the FulfillmentModeCode data element in the incoming customer order. In this case, the value can be DELIVER, CANCEL, or TSQ.
declare namespace provord=";http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/ProvisioningOrder/V1";; declare namespace corecom=";http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2";; fn:namespace-uri(.) = 'http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/ProvisioningOrder/V1' and fn:exists(../provord:ProcessProvisioningOrderEBM/provord:DataArea/provord:ProcessProvisioningOrder/corecom:Identification/corecom:BusinessComponentID) and ../provord:ProcessProvisioningOrderEBM/provord:DataArea/provord:ProcessProvisioningOrder/provord:TypeCode/text() = 'OSM-BDB' and ( ../provord:ProcessProvisioningOrderEBM/provord:DataArea/provord:ProcessProvisioningOrder/provord:FulfillmentModeCode/text() = 'DELIVER' or ../provord:ProcessProvisioningOrderEBM/provord:DataArea/provord:ProcessProvisioningOrder/provord:FulfillmentModeCode/text() = 'CANCEL' or ../provord:ProcessProvisioningOrderEBM/provord:DataArea/provord:ProcessProvisioningOrder/provord:FulfillmentModeCode/text() = 'TSQ' )
For more information about order recognition rules see OSM Modeling Guide.
This topic describes how to use the Order Recognition Rule editor Validation Rule area XQuery tab to write an expression that specifies nodes in the incoming customer order that must evaluate to true to accept the customer order into the system. The XQuery has the following characteristics:
Context: The input document for the Validation Rule XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: The input document for the Validation Rule XQuery is the customer order. You can declare the customer order namespace in the XQuery prolog. For example:
declare namespace im="http://xmlns.oracle.com/InputMessage";
Body: The validation rule must specify customer order parameters or parameter values to evaluate to true for the validation to be successful. If the validation fails, the expression should return an error message.
In addition, if the Validation Rule fails, OSM automatically creates the order and sets the order state to Failed. The inbound message and validation failure output are attached to the order for reference. You can display and manage the order failure in the Order Management Web client.
The following sample XQuery checks for the existence of a sender ID:
if (fn:exists(./header/c:Sender/c:ID) and ./header/c:Sender/c:ID != '')
then (true())
else concat("SEVERE", "Message Header should contain Sender ID", header/Sender/ID")
The following sample XQuery checks for correct values in the typeCode data element in the incoming customer order:
if (fn:exists($orderLine/im:ItemReference/im:TypeCode)
and
$orderLine/im:ItemReference/im:TypeCode != '')
then
(
if ($orderLine/im:ItemReference/im:TypeCode = "PRODUCT" or
$orderLine/im:ItemReference/im:TypeCode = "OFFER" or
$orderLine/im:ItemReference/im:TypeCode = "BUNDLE") then ()
else
local:reportIssue("ERROR", "Product Type should be one of: PRODUCT, OFFER, BUNDLE",
$lineNum, "ProcessProvisioningOrderEBM/DataArea/ProcessProvisioningOrder/
ProvisioningOrderLine/ItemReference/TypeCode")
)
Given this XQuery sample, the following part of a customer order would evaluate to true because the typeCode element value is BUNDLE.
<!-- FIXED BUNDLE - BUNDLE -->
<im:salesOrderLine>
<im:lineId>2</im:lineId>
<im:promotionalSalesOrderLineReference>1</im:promotionalSalesOrderLineReference>
<im:serviceId></im:serviceId>
<im:requestedDeliveryDate>2001-12-31T12:00:00</im:requestedDeliveryDate>
<im:serviceActionCode>Add</im:serviceActionCode>
<im:itemReference>
<im:name>Fixed Bundle</im:name>
<im:typeCode>BUNDLE</im:typeCode>
<im:specificationGroup />
</im:itemReference>
</im:salesOrderLine>
For more information about validation rules see OSM Modeling Guide.
This topic describes how to use the Order Recognition Rule editor Order Priority area XQuery tab to write an expression that specifies an element value in the incoming customer order that identifies the order priority. The XQuery has the following characteristics:
Context: The input document for the Order Priority XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: You can declare the customer order namespace in the XQuery prolog. For example:
declare namespace im="http://xmlns.oracle.com/InputMessage";
Body: The Order Priority body must specify the node that contains the order priority value.
For more information about creating order priority XQuery expressions in the order recognition rule and about creating order priority ranges for an order type, see OSM Modeling Guide.
This topic describes how to use the Order Recognition Rule editor Order Reference area XQuery tab to write an expression that specifies an element value in the incoming customer order that identifies the order reference. The XQuery has the following characteristics:
Context: The input document for the Order Reference XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: You can declare the customer order namespace in the XQuery prolog. For example:
declare namespace im="http://xmlns.oracle.com/InputMessage";
Body: The Order Reference body must specify the node that contains the order reference value.
The following example shows a transformation rule XQuery expression that retrieves the order reference number (as a string) from the numSalesOrder field in the incoming customer order:
declare namespace im="http://xmlns.oracle.com/InputMessage"; let $order := ../im:order return $order/im:numSalesOrder/text()
For more information about order reference, see OSM Modeling Guide.
This topic describes how to use the Order Recognition Rule editor Order Data Rule area XQuery tab to write an expression that specifies nodes in the incoming customer order that must be used in the creation task. The XQuery has the following characteristics:
Context: The input document for the Order Data Rule XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: You can declare the customer order namespace in the XQuery prolog. For example:
declare namespace im="http://xmlns.oracle.com/InputMessage";
Body: The Order Data Rule body must map the customer order element values to the corresponding creation task Task Data values.
The following example shows the fields in an incoming customer order:
<im:customerAddress>
<im:locationType>Street</im:locationType>
<im:nameLocation>Jangadeiros</im:nameLocation>
<im:number>48</im:number>
<im:typeCompl>floor</im:typeCompl>
<im:numCompl>6</im:numCompl>
<im:district>Ipanema</im:district>
<im:codeLocation>5000</im:codeLocation>
<im:city>Rio de Janeiro</im:city>
<im:state>RJ</im:state>
<im:referencePoint>Gen. Osorio Square</im:referencePoint>
<im:areaCode>22420-010</im:areaCode>
<im:typeAddress>Building</im:typeAddress>
</im:customerAddress>
Following is a sample order data in a creation task. In the example, the following data is contained in a CustomerDetails element:
locationType
nameLocation
number
typeCompl
numCompl
district
codeLocation
city
state
referencePoint
areaCode
typeAddress
The following XQuery expression specifies a variable for the location of the customerAddress node in the customer order that can then be used to map customerAddress child element values to CustomerDetails task data elements:
let $details := $customer/mes:customerAddress
The following XQuery expression performs this mapping:
return<_root>
<CustomerDetails>
<locationType>{$details/im:locationType/text()}</locationType>
<nameLocation>{$details/im:nameLocation/text()}</nameLocation>
<number>{$details/im:number/text()}</number>
<typeCompl>{$details/im:typeCompl/text()}</typeCompl>
<numCompl>{$details/im:numCompl/text()}</numCompl>
<district>{$details/im:district/text()}</district>
<codeLocation>{$details/im:codeLocation/text()}</codeLocation>
<city>{$details/im:city/text()}</city>
<state>{$details/im:state/text()}</state>
<referencePoint>{$details/im:referencePoint/text()}</referencePoint>
<areaCode>{$details/im:areaCode/text()}</areaCode>
<typeAddress>{$details/im:typeAddress/text()}</typeAddress>
</CustomerDetails>
</_root>
In the following example, the XQuery expression returns the <_root> portion of the order. The ControlData portion of the order is populated by the system during the generation of the orchestration plan.
declare namespace cso="http://xmlns.oracle.com/communications/sce/dictionary/CentralOMManagedServices-Orchestration/CustomerSalesOrder";
let $customer := //cso:CustomerAccount
return
<_root>
<OrderHeader>
<AccountIdentifier>{$customer/cso:AccountID/text()}</AccountIdentifier>
</OrderHeader>
</_root>
For more information about order data rules, see OSM Modeling Guide.