This topic includes information about order recognition rule XQuery expressions related to order decomposition:
About Fulfillment Pattern Order Component XQuery Expressions
About Component Specification Custom Component ID XQuery Expressions
About Fulfillment Pattern Duration XQuery Expressions (deprecated)
About Fulfillment Pattern Component Duration XQuery Expressions
The Orchestration Sequence editor provides the following areas to define XQuery expressions related to order decomposition:
This topic describes how to use the Orchestration Sequence editor Order Item Selector area XQuery tab to write an expression that specifies which node-set to use from the customer order as order items and has the following characteristics:
Context: The input document for the Order Item Selector 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.
Body: The XQuery body must specify the customer order node-sets that OSM then uses as order items.
The following example shows an order item selector XQuery where the <salesOrderLine> node-set is specified. OSM can now use the data in the <salesOrderLine> node-set in the incoming customer order in the order items. There can only be one node-set selected per sequence.
declare namespace im="http://xmlns.oracle.com/InputMessage"; .//im:salesOrderLine
This topic describes how to use the Orchestration Sequence editor Fulfillment Mode area XQuery tab to write an expression that specifies the fulfillment mode for the orchestration sequence from a customer order element and has the following characteristics:
Context: The input document for the Fulfillment Mode Expression area XQuery is the customer order. For more information about typical customer order structures, see OSM Modeling Guide.
Prolog: The input document for the Fulfillment Mode Expression area XQuery is the incoming customer order. You must declare the customer order namespace in the XQuery prolog.
Body: The XQuery body must specify the fulfillment mode.
Typically, the fulfillment mode is specified in the order header. For example:
<im:FulfillmentModeCode>Deliver</im:FulfillmentModeCode>
In the following example, the XQuery looks in the incoming customer order (SalesOrder) for the <FulfillmentModeCode> element. It returns the text contained in that element.
declare namespace
im="http://xmlns.oracle.com/InputMessage";
<osm:fulfillmentMode name="{fn:normalize-space(.//im:SalesOrder/im:DataArea/im:FulfillmentModeCode/text())}"
This is the XML in the incoming customer order:
<im:FulfillmentModeCode>Deliver</im:FulfillmentModeCode>
In this case, the XQuery returns Deliver.
The Order Item Specification editor provides the following areas to define XQuery expressions related to order decomposition:
About Order Item Specification Order Item Property XQuery Expressions
About XQuery Expressions for Mapping Product Specifications and Fulfillment Patterns
About Order Item Specification Order Item Hierarchy XQuery Expressions
This topic describes how to use the Order Item Specification editor, Order Item Properties tab, Property Expression area, XQuery tab to write an expression that specifies order item properties based on the input context. These expressions have the following characteristics:
Context: The Property Expression area XQuery input document is a node from the node-set returned by the order item selector (see "About Order Sequence Order Item Selector XQuery Expressions"). OSM runs every order item Property Expression area XQuery against each node (starting with the first and ending with the last node) in the node-set returned by the order item selector.
Prolog: You can declare the following variables within the prolog to access additional context information:
The $inputDoc variable can be declared in the prolog of an OSM XQuery to provide access to the original input customer order. This external function can be useful if you need to generate order item properties based on elements outside of the order item node-set defined in the order item selector. The format for declaring this variable in the XQuery prolog is:
declare variable $inputDoc as document-node() external;
You can then access this variable within the XQuery body. For example, the following XQuery body uses $inputDoc to define the ItemReferenceName value:
let $inputOrderData:= $inputDoc/GetOrder.Response/_root fn:normalize-space(cso:ItemReferenceName/text())
For more information about typical customer order structures, see OSM Modeling Guide.
The $salesOrderLines variable can be used in an OSM XQuery to provide access to original order item node-set before it is selected by the orchestration sequence's order item selector. This can be useful if the order item selector XQuery changes the selected order item node-set (for example, by rearranging the order of the elements). The format for declaring this variable in the XQuery prolog is:
declare variable $salesOrderLines as document-node() external;
You can access this variable within the XQuery body. For more information about typical customer order structures, see OSM Modeling Guide.
Body: The XQuery body must specify the order item element that provides the values for each order item property you define.
After these XQuery expressions have run against an order item, the order item and the order item properties become internally accessible as an XQuery context for other OSM entities. For example,
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model" id="1288881040699">
<osm:name>Commercial Fixed Service [Add]</osm:name>
<osm:orderItemSpec xmlns="http://xmlns.oracle.com/communications/ordermanagement/model">
<osm:name>CustomerOrderItemSpecification</osm:name>
<osm:namespace>
http://oracle.communications.ordermanagement.unsupported.centralom
</osm:namespace>
</osm:orderItemSpec>
<osm:productSpec xmlns="http://xmlns.oracle.com/communications/ordermanagement/model">
<osm:name>Service.Fixed</osm:name>
<osm:namespace>
http://oracle.communications.ordermanagement.unsupported.centralom
</osm:namespace>
</osm:productSpec>
<osm:properties xmlns:im="http://oracle.communications.ordermanagement.unsupported. centralom">
<im:typeCode>PRODUCT</im:typeCode>
<im:parentLineId>3</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName>
<im:lineId>4</im:lineId>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productSpec>Fixed Service Plan Class</im:productSpec>
<im:serviceId>552131313131</im:serviceId>
<im:fulfillPatt>Service.Fixed</im:fulfillPatt>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
The following examples show some ways to map data in an incoming customer order to an order item property. The current context is a single node from salesOrderLines, which is one of the nodes returned by executing the orchestration sequence order item selector against the input message (see "About Order Sequence Order Item Selector XQuery Expressions").
Order management personnel need to know what the requested delivery date is for order items. Adding the date to the order item allows the order management personnel to see it in the OSM web clients. In addition, OSM needs the requested delivery date to calculate the order start date.
To retrieve the requested delivery data for an order item, OSM looks in the incoming customer order for the <requestedDeliveryDate> element:
<im:requestedDeliveryDate>2001-12-31T12:00:00</im:requestedDeliveryDate>
The definition of the requestedDeliveryDate order item property includes the following XQuery, which returns the text of the <requestedDeliveryDate> element:
declare namespace im="http://xmlns.oracle.com/InputMessage"; fn:normalize-space(im:requestedDeliveryDate/text())
Order management personnel need to identify order items in the OSM web clients. The lineItemName order item property includes the following XQuery:
declare namespace im="http://xmlns.oracle.com/InputMessage"; fn:normalize-space(fn:concat(im:itemReference/im:name/text(),' [',im:serviceActionCode/text(),']'))
This XQuery looks for two elements, <name> and <serviceActionCode>:
<im:name>Fixed Caller ID</im:name> <im:serviceActionCode>Add</im:serviceActionCode>
It then concatenates the text retrieved from the two elements to form the order item name, in this case Fixed Caller ID [Add].
Order management personnel need to identify the products or product specification from the customer order so that order items can be mapped to fulfillment patterns (see "About XQuery Expressions for Mapping Product Specifications and Fulfillment Patterns"). The following example shows the product specification data in the message, contained in the <primaryClassificationCode> element:
<im:primaryClassificationCode>Mobile Service Feature Class
</im:primaryClassificationCode>
The productClass order item property uses the following XQuery expression to get the data:
declare namespace im="http://xmlns.oracle.com/InputMessage";
fn:normalize-space(im:itemReference/im:primaryClassificationCode/text())
The order item property specified in the Fulfillment Pattern Mapping Property field for the order item must map to an existing OSM fulfillment pattern entity. The value could be contained in a customer order, but more often, it is derived from other customer order parameter. This property is mandatory.
The construction of the fulfillment pattern mapping order item property follows the same rules as other order item property XQuery expressions. See "About Order Item Specification Order Item Property XQuery Expressions" for more information about the XQuery context, prolog, and body.
The following describes a common scenario for deriving fulfillment patterns from product or product specification data contained in an order. In other scenarios, the mapping from product or product specification to fulfillment pattern might be simpler; or, there might be cases where some order line items have no product specification, in which case the product specification can be derived from the context of the order item.
You typically create conceptual model products in your OSM system by importing them. (See OSM Modeling Guide for more information.) When you import products, Design Studio creates the productClassMapping.xml and productSpecMapping.xml files. These files contain mappings between conceptual model products and OSM product specifications and fulfillment patterns. The productClassMapping.xml file is provided for backward compatibility, so in this topic it is assumed that you are using the productSpecMapping.xml file. These files are created in one of the following directories:
If you have specified a value for the Product Specification Mapping Folder field of the Orchestration Preferences in Eclipse, it will create the two files in the directory specified.
If no value is specified for that field, OSM will create the productClassMapping.xml file in the resources/productClassMapping directory and the productSpecMapping.xml file in the resources/productSpecMapping directory.
You can retrieve this mapping data from one of these files by creating a data instance provider that can be referenced from an XQuery expression body using a data instance behavior.
Note:
The element names are not the same between the productClassMapping.xml and productSpecMapping.xml files. Ensure that you are using the correct element names for the file you are referencing. The names in this topic are correct for the productSpecMapping.xml file.For example, the following XQuery creates the $productSpecMap variable that references the data instance that points to the productSpecMapping.xml file:
let $productSpecMap := vf:instance('dataInstace1')
The following code creates a variable that references the product specification value from the customer order. For example:
let $productSpecName := fn:normalize-space(im:itemReference/im:primaryClassificationCode/text())
You can now create an expression that matches the product specification from the order with the product specification contained in the productSpecMapping.xml file and returns the fulfillment pattern associated with it or else defaults to the Non.Service.Offer fulfillment pattern. For example:
return if ($productSpecName != '') then fn:normalize-space($productSpecMap/productSpec [fn:lower-case(@name)=fn:lower-case($productSpecName)]/productSpec/text()) else 'Non.Service.Offer'
In the following example, OSM retrieves the product specification Mobile Service Feature Class from the incoming customer order. OSM uses the order item property specified in the Fulfillment Pattern Mapping Property field for the order item to map the product specification to a fulfillment pattern.
The order item property specified in the Fulfillment Pattern Mapping Property field for the order item includes the following XQuery expression:
declare namespace im="http://xmlns.oracle.com/InputMessage";
(: Use the ProductSpecMap data instance behavior to retrieve the data in the productSpecMapping.xml file: :)
let $productSpecMap := vf:instance('ProductSpecMap')
let $productSpecName :=
fn:normalize-space(im:itemReference/im:primaryClassificationCode/text())
return
if ($productSpecName != '')
then
fn:normalize-space($productSpecMap/productSpec
[fn:lower-case(@name)=fn:lower-case($productSpecName)]/productClass/text())
else
'Non.Service.Offer'
The productSpecMapping.xml file includes the <productSpec> element, that maps the Mobile Service Feature Class product specification to the Service.Mobile fulfillment pattern:
<productSpec name="Mobile Service Feature Class" cartridge="OsmCentralOMExample-ProductSpecs"> <fulfillmentPattern>Service.Mobile</fulfillmentPattern> </productSpec>
To summarize, to map an order line item in an incoming customer order to a fulfillment pattern, you configure the following:
In the order item specification:
A property that retrieves the conceptual model product or the OSM product specification from the incoming customer order.
The order item property specified in the Fulfillment Pattern Mapping Property field, that maps the product or product specification to the fulfillment pattern. To do so, OSM uses the ProductClassMap data instance behavior.
The ProductSpecMap data instance behavior (and the data provider that supports it), that retrieves data from the productSpecMapping.xml file.
The productSpecMapping.xml file used by the ProductClassMap data instance behavior, that maps products and product specifications to fulfillment patterns.
When you update your product catalog, you might need to add new fulfillment patterns. In that case, you need to:
Create new fulfillment patterns and conceptual model products, if necessary.
Add mappings to the productSpecMapping.xml file.
You do not need to change the order item specification or the data instance behavior.
This topic describes how to use the Order Item Specification editor Order Item Hierarchies tab, Key Expression and Parent Key Expression areas, XQuery subtabs to write expressions that specify the relative hierarchy of order items, in the same order or between different orders, based on an order item value, such as lineId and parentLineId and has the following characteristics:
Context: The Key Expression and Parent Key Expression area XQuery input document is the order item. Specifically order item properties that indicate the relative hierarchy, such as order item lineId and parentLineID properties. For example:
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="1288881040699">
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>PRODUCT</im:typeCode>
<im:parentLineId>3</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName>
<im:lineId>4</im:lineId>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Fixed Service Plan Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Fixed</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
Prolog: You can declare the order item specification namespace and the OSM namespace in the XQuery prolog. For example:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";
You can declare the OrchestrationXQueryFunctions class in the prolog to use the ancestors method that returns the current node and all ancestors of the current node based on the specified hierarchy definition. This method can be useful when creating dependencies between order items based on hierarchy. For example:
declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions";
See "OSM XQuery Functions" for more information about the OrchestrationXQueryFunctions class. See OSM Modeling Guide for an example of how the ancestors method is used.
Body: The XQuery body must specify an order item property defined in the order item specification.
For example, for the Key Expression, you can identify a unique key for each order item, typically the order item line ID:
fn:normalize-space(osm:properties/im:LineId/text())
For example, for the Parent Key Expression, you can identify a parent order line item, typically the line ID for the parent order line item:
fn:normalize-space(osm:properties/im:parentLineId/text())
In the following example, the key expression uses the parent order line item's <lineId> element from the order item property customer order:
declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model";
fn:normalize-space(osm:properties/im:lineId/text())
The parent key expression uses the child order line item's <parentLineId> element from the incoming customer order:
declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model";
fn:normalize-space(osm:properties/im:parentLineId/text())
This topic describes how to use the Order Item Specification editor Orchestration Conditions tab, Condition Expression area, XQuery subtab to write expressions that specifies an order item property value as a condition that you can then use in an order decomposition rule or in a fulfillment pattern to determine whether an order item gets included in an order component. The XQuery for the condition has the following characteristics:
Context: The Condition Expression area XQuery input document is the order item properties you want to use as conditions. For example, the following order item contains the region and the ServiceActionCode order item properties, that could be associated to conditions:
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="1288881040699">
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>PRODUCT</im:typeCode>
<im:parentLineId>3</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName>
<im:lineId>4</im:lineId>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Fixed Service Plan Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Fixed</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
See "About Fulfillment Pattern Order Component Condition XQuery Expressions" for a description of the XQuery condition based on the ServiceActionCode. See "About Decomposition Rule Condition XQuery Expressions" for a description of the XQuery condition based on the region.
Prolog: You can declare the order item specification namespace and the OSM namespace in the XQuery prolog. For example:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";
Body: The XQuery body must evaluate an order item property defined in the order item specification. These order item properties are available from the OSM namespace using the properties element. For example, the following expression evaluates to true if the value of region is anything other than Sao Paulo and the order item gets included in the order component. If the region were set to Sao Paulo, then the order item would not be included in the order component.
fn:not(fn:normalize-space(osm:properties/im:region/text())='Sao Paulo')
Another condition could be created that would only evaluate to true if the value of region was set to Sao Paulo. In this case, the order item would only be included in the order component if the region were set to Sao Paulo.
The Fulfillment Pattern editor provides the following areas to define XQuery expressions related to order decomposition:
About Fulfillment Pattern Order Component Condition XQuery Expressions
About Associating Order Items Using Property Correlations XQuery Expressions
Note:
The XQuery expressions discussed in this chapter also apply to the Orchestration Dependency editor.This topic describes how to use the Fulfillment Pattern editor, Orchestration Plan tab, Order Components subtab, Conditions subtab XQuery subtab to write an expression that specifies whether to include or exclude an order item from an order component. You can create a new fulfillment pattern from the Fulfillment Pattern editor or select from conditions created in the Order Item Specification. See "About Order Item Specification Condition XQuery Expressions" for more information about the context, prolog, and body of condition XQuery expressions.
The following example XQuery expression only evaluates to true if the value of ServiceActionCode is not NONE or UPDATE. For example, if the value of ServiceActionCode were ADD, then the order item would be included in the order component.
fn:boolean ( (osm:properties/im:ServiceActionCode/text()!="NONE" and osm:properties/im:ServiceActionCode/text()!="UPDATE") or (
This topic describes how to use the Fulfillment Pattern editor, Orchestration Plan tab, Order Components subtab, Order Item Association subtab, Property Correlation selection, XQuery subtab to write an expression that associates order items to order components that are not assigned by their fulfillment pattern. These order item associations are typically required when external systems need a specific context for an order item and includes the following characteristics:
Context: The Order Item Association subtab XQuery input documents are multiple order items in the order after decomposition contained in the fromOrderComponent element and the entire set of order items included in the order contained in the toOrderComponent element. You can make an XQuery association based on the contents of these order items that create an association between the unique order item IDs. For example:
<fromOrderComponent xmlns=""> <osm:orderItem xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model" id="1234"> <osm:name>Speed By Demand [Add]</osm:name> ..... <osm:properties xmlns:im="http://oracle.communications.ordermanagement.unsupported. centralom"> <im:typeCode>PRODUCT</im:typeCode> <im:parentLineId>3</im:parentLineId> <im:requestedDeliveryDate>2013-06-31T12:00:00 </im:requestedDeliveryDate> <im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName> <im:lineId>4</im:lineId> <im:SiteID>10</im:SiteID> <im:ServiceActionCode>UPDATE</im:ServiceActionCode> <im:productClass>Speed by Demand class</im:productClass> <im:serviceId>552131313131</im:serviceId> <im:productSpec>Service.Fixed</im:productSpec> <im:lineItemPayload> [34 lines] <mi:region>Sao Paulo</im:region> <osm:properties> </osm:orderItem> <osm:orderItem [37 lines] <osm:orderItem [42 lines] <osm:orderItem [57 lines] <osm:orderItem [57 lines] </fromOrderComponent> <toOrderComponent xmlns=""> <osm:orderItem [35 lines] <osm:orderItem [37 lines] <osm:orderItem [42 lines] <osm:orderItem xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model" id="5678"> <osm:name>Broadband Bundle [Add]</osm:name> ..... <osm:properties xmlns:im="http://oracle.communications.ordermanagement.unsupported. centralom"> <im:typeCode>PRODUCT</im:typeCode> <im:parentLineId>3</im:parentLineId> <im:requestedDeliveryDate>2013-06-31T12:00:00 </im:requestedDeliveryDate> <im:lineItemName>Broadband Bundle [Add]</im:lineItemName> <im:lineId>4</im:lineId> <im:SiteID>10</im:SiteID> <im:ServiceActionCode>UPDATE</im:ServiceActionCode> <im:productClass>Broadband Bundle Class</im:productClass> <im:serviceId>1112223333</im:serviceId> <im:productSpec>Broadband.Bundle</im:productSpec> <im:lineItemPayload> [34 lines] <im:region>Sao Paulo</im:region> <osm:properties> </osm:orderItem> <osm:orderItem [57 lines] <osm:orderItem [57 lines] <osm:orderItem [42 lines] <osm:orderItem [37 lines] <osm:orderItem [37 lines] <osm:orderItem [57 lines] </toOrderComponent>
Prolog: You can declare the order item namespace and the OSM namespace in the XQuery prolog. For example:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";
Body: The XQuery body must specify a dependency between the order item and the associated order item using something similar to the following syntax:
let $fromItem := osm:fromOrderComponent/osm:orderItem[osm:name/text()="Speed By Demand [Add]"] let $toItem := osm:toOrderComponent/osm:orderItem[osm:name/text()="Broadband Bundle [Add]" and osm:properties/im:SiteID/text() = $fromItem/osm:properties/im:SiteID/text()] return <osm:dependency fromOrderItemId='{$fromItem/@id}' toOrderItemId='{$toItem/@id}'/>
where
osm:fromOrderComponent: Returns the set of order items included in the order component after the decomposition phase.
osm:toOrderComponent: Returns the entire set of order items included in the order.
osm:orderItem: These are the order items in the fromOrderComponent or toOrderComponent categories.
osm:dependency fromOrderItemId='{$fromItem/@id}: The output of the XQuery specifying the source order item ID for the association.
toItem='{$childOrderItem/@id}'/>: The output of the XQuery specifying the target order item ID for the association.
Given the sample provided in the context bullet, this XQuery would return the following association:
<osm:dependency fromOrderItemId='1234' toOrderItemId='5678'/>
The following example shows an XQuery that associates all child order items with their parent items. (See OSM Modeling Guide for more information.) The output of the XQuery expression returns a node-set of <osm:dependency fromOrderItemId='{$fromOrderItem/@id}' toOrderItemId=' {$toOrderItem/@id}'/> where item IDs are the @id attribute of the order item.
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace prop="http://oracle.communications.ordermanagement.unsupported.centralom"; (: $fromOrderItemList contains all order items in the selected order component: :) for $fromOrderItem in $fromOrderItemList let $fromOrderItemList := osm:fromOrderComponent/osm:orderItem (: $childOrderItems contains all children for the current $fromOrderItem: :) let $childOrderItems := osm:toOrderComponent/osm:orderItem/osm:properties [prop:ParentLineID/text() = $fromOrderItem/osm:properties/prop:LineID/text()] (: Returns the association between all parents and their children: :) for $childOrderItem in $childOrderItems return <osm:dependency fromOrderItemId='{$fromOrderItem/@id}' toOrderItemId='{$childOrderItem/@id}'/>
This topic describes how to use the Decomposition Rule editor, Conditions tab, Conditions Details subtab, XQuery subtab to write an expression that associates a condition with a decomposition rule. You can create the condition in the order item specification and select them in the decomposition rule, or you can create them directly in the decomposition rule. See "About Order Item Specification Condition XQuery Expressions" for more information about the context, prolog, and body of condition XQuery expressions.
The following is an example of two decomposition rules, each having a condition set that determines whether an order item is included in the target order component or not. In this example:
The decomposition rule that targets the target system order component for region 1 has the following decomposition condition:
isRegion1
The decomposition rule that targets the a target system order component for region 2 has the following decomposition condition:
isOtherRegion
The XQuery for the isRegion1 decomposition rule condition is:
declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom"; declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; fn:normalize-space(osm:properties/im:region/text())='Toronto')
This condition specifies the value of the region order item property. If the value is Toronto, the decomposition rule condition is true, and the order item is included in the region 1 target system order component.
The XQuery for the isOtherRegion decomposition rule condition is:
declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom";declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model";fn:not(fn:normalize-space(osm:properties/im:region/text())='Toronto')
This condition also specifies the value of the region order item property, but evaluates to true only if the value is not Toronto. All order items that have any other value are included in the region 2 target system order component.
The following example includes a variation on the isRegion1 decomposition rule that specifies that all the order items from the source order component to the target order component that have at least one order item with a region property of Toronto are included in the order component. Otherwise, if the condition evaluates to false then none of the order items in fromOrderComponent are included in the resulting order component.
declare namespace im="http://oracle.communications.centralom"; declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; fn:exists(osm:fromOrderComponent/osm:orderItem[fn:normalize-space(osm:properties/im:Region/text())='Toronto'])
For some functions, there is only one target system in the topology. For example, if you have only one collections system in the topology, you will have one dependency rule that uses a simple mapping from the source collections function order component to the collections target system order component, and no decomposition condition is necessary.
This topic describes how to use the Order Component Specification editor, Component ID tab, Component ID area, XQuery subtab to write an expression that specifies a custom component ID for an order component. These custom component IDs are typically required when the default component IDs are not sufficiently specific (see OSM Modeling Guide for more information about the default component ID). The Component ID XQuery includes the following characteristics:
Context: The Component ID tab XQuery input document is the order item and the order item properties you want to use to create a custom component ID with. For example, the following order item contains the SiteID and requestedDeliveryDate order item properties. In a simple scenario, you can use this element to group all order items that share the same SiteID value and further delineate groups based on requestedDeliveryDate date range.
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="1288881040699">
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>Bundle</im:typeCode>
<im:parentLineId>3</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName>
<im:lineId>4</im:lineId>
<im:SiteID>10</im:SiteID>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Fixed Service Plan Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Fixed</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
Prolog: You can declare the order item namespace and the OSM namespace in the XQuery prolog. In more complicated XQuery expressions, you can also use the OrchestrationXQueryFunctions OSM Java package to specify component IDs based on order item hierarchies, order item requested delivery date, order component duration, order component minimum duration separation, or a combination of some or all of them. For example:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace im="http://oracle.communications.ordermanagement.unsupported.centralom"; declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions";
See "OSM XQuery Functions" for more information about the OrchestrationXQueryFunctions class.
Body: The body must return a string. Every order item that ends with the same string gets included in the order component. For example, if you wanted to group all order items based on the SiteID value, you could specify the following XQuery:
return osm:properties/im:SiteID/text()
The following topics describe OSM Java package methods.
For more information about how the OrchestrationXQueryFunctions are used in custom Component ID XQuery expressions and for more complicated custom group ID generation scenarios that use Orchestration XQueryFunction, see the following topics:
Custom Component IDs Based on Requested Delivery Date and Duration
Custom Component IDs by Duration and Minimum Separation Duration
Combining Order Item Hierarchy with Duration-Based Groupings
A more common scenario where custom order component IDs can be used is when you need additional groupings of order components at the granularity level. For example, three levels of decomposition from Function, System, to Bundle, results in the following component IDs:
BillingFunction
BillingFunction.BillingSystem
BillingFunction.BillingSystem.Bundle
If you had order items in the Bundle order components that were part of different bundles that go to different the billing system, you would need to separate each order item bundle into different bundle order component. A component ID for such a scenario could look like this:
For billing system 1: BillingFunction.BillingSystem.Bundle.2/BundleGranularity
For billing system 2: BillingFunction.BillingSystem.Bundle.6/BundleGranularity
To create custom component IDs for this scenario, you could use the following order item properties:
typeCode: This property specifies if the order line item is an offer, bundle, or product. This element also defines the product hierarchy of the order line items. For example:
OFFER
BUNDLE
PRODUCT
lineId and parentLineId: These properties specify the hierarchical relationship between the bundle and product order line items. You can create separate component IDs for every order item bundle and associate all product order items with their corresponding bundle component ID. To identify all ancestor order items that may be a bundle, you can use the XQuery ancestors function, as explained later.
For example, the following four order items include two bundles and two associated products. These order items have the following characteristics:
Order Item 1 includes:
typeCode: BUNDLE
lineId: 2
parentLineId: 1 (for example, an order item with an OFFER typeCode. This order item is not specified in this example).
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="1234">
<osm:name>FIXED BUNDLE - BUNDLE</osm:name>
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>BUNDLE</im:typeCode>
<im:parentLineId>1</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Fixed Bundle</im:lineItemName>
<im:lineId>2</im:lineId>
<im:SiteID>5</im:SiteID>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Fixed Bundle Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Fixed</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
Order Item 2 includes:
typeCode: PRODUCT
lineId: 3
parentLineId: 2 (This matches the lineID of order item 1 indicating that order item 1 is the parent of order item 2).
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="56789">
<osm:name>FIXED CALLER ID - PRODUCT</osm:name>
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>PRODUCT</im:typeCode>
<im:parentLineId>2</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Commercial Fixed Service [Add]</im:lineItemName>
<im:lineId>5</im:lineId>
<im:SiteID>7</im:SiteID>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Fixed Bundle Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Fixed</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
Order Item 3 includes:
typeCode: BUNDLE
lineId: 6
parentLineId: 1 (This indicates that both order item 1 and order item 3 share the same parent).
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="10111213">
<osm:name>BroadBand BUNDLE - BUNDLE</osm:name>
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>BUNDLE</im:typeCode>
<im:parentLineId>1</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Broadband Bundle</im:lineItemName>
<im:lineId>6</im:lineId>
<im:SiteID>5</im:SiteID>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Broadband Bundle Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Broadband</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
Order Item 4 includes:
typeCode: PRODUCT
lineId: 7
parentLineId: 6 (This matches the lineID of order item 3 indicating that order item 3 is the parent of order item 4).
<osm:orderItem
xmlns:osm="http://xmlns.oracle.com/communications/ordermanagement/model"
id="14151617">
<osm:name>BroadBand Service - PRODUCT</osm:name>
.....
<osm:properties
xmlns:im="http://oracle.communications.ordermanagement.unsupported.
centralom">
<im:typeCode>PRODUCT</im:typeCode>
<im:parentLineId>6</im:parentLineId>
<im:requestedDeliveryDate>2013-06-31T12:00:00</im:requestedDeliveryDate>
<im:lineItemName>Fixed Bundle</im:lineItemName>
<im:lineId>7</im:lineId>
<im:SiteID>5</im:SiteID>
<im:ServiceActionCode>UPDATE</im:ServiceActionCode>
<im:productClass>Broadband Bundle Class</im:productClass>
<im:serviceId>552131313131</im:serviceId>
<im:productSpec>Service.Broadband</im:productSpec>
<im:lineItemPayload> [34 lines]
<im:region>Sao Paulo</im:region>
<osm:properties>
</osm:orderItem>
The customer order includes two bundles with two products. The hierarchy is:
Fixed Bundle - order item 2
Fixed Caller ID - order item 5
Broadband Bundle - order item 6
BroadBand Service - order item 7
To create the separate customized component IDs for the bundle order items 1 and 3, and include all their corresponding children order items you need to:
Return a separate component ID for each BUNDLE typeCode. This causes BUNDLE order components to be generated.
Ensure that the PRODUCT typeCode for that bundle are included in its parent order item.
To do so, the XQuery uses the ancestors function to find whether the order item has a BUNDLE typeCode or has a BUNDLE typeCode in one of its parent order items. If the order item is a bundle, then a OSM creates a component ID for the bundle. If the order item has a bundle in one of its parent order items, then OSM includes the order item in its parent order item component ID. The following example shows an XQuery that does this.
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace prop="http://oracle.communications.ordermanagement.unsupported.centralom"; declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions"; (: The following part of the XQuery identifies the order line hierarchy definition and retrieve all of the predecessor order line items in the bundle: :) let $ancestors := osmfn:ancestors("CustomerOrderItemSpecification","default","http://oracle.communications.ordermanagement.unsupported.centralom") (: The following part of the XQuery finds the BUNDLE order item and generates an ID based on the bundle order item lineID: :) return if (fn:exists($ancestors[osm:properties/prop:typeCode='BUNDLE'])) then ( concat($ancestors[osm:properties/prop:typeCode=('BUNDLE')] [1]/osm:properties/prop:lineId/text(),'/BundleGranularity') ) else ( 'ALL_OFFERS_AND_NON_SERVICE_BILLING/BundleGranularity' )
This XQuery finds the child order line items, finds their parent order line items, and creates a bundle order component for each of the bundle lines. The component keys are:
BillingFunction.BillingSystem.Bundle.2/BundleGranularity
BillingFunction.BillingSystem.Bundle.6/BundleGranularity
In another example, there is one offer with two bundles and two products in each bundle. The following table shows the hierarchy of bundles and products. The component keys use the line IDs of the two bundle items.
| Line Number | Line Name | Line typeCode | Parent Line ID | Value to Use in Component Key |
|---|---|---|---|---|
| 1 | Triple Play | OFFER | - | - |
| 2 | Fixed Bundle | BUNDLE | 1 | 2 |
| 2.1 | Fixed Service | PRODUCT | 2 | 2 |
| 2.2 | Call Forwarding | PRODUCT | 2 | 2 |
| 5 | Broadband Bundle | BUNDLE | 1 | 5 |
| 5.1 | Broadband Service | PRODUCT | 5 | 5 |
| 5.2 | High-Speed Internet | PRODUCT | 5 | 5 |
In some scenarios, you may want to create custom Order Component IDs based on order item requested delivery date and duration. For example, the following custom component ID XQuery creates order component grouping based on the order item requested delivery dates:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace prop="http://oracle.communications.ordermanagement.unsupported.centralom"; declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions"; let $groupDuration := "P2D" return osmfn: getGroupIdByDateTime ($groupDuration)
The XQuery creates a new order component for an order item based on the order item's requested delivery date and includes all order items within this group that fall within two days of the first order item's requested delivery date in the group. The XQuery does the same thing for all other order items within the order.
The following table shows how five order items would be grouped given a custom Order Component ID XQuery that creates a new component IDs.
Note:
The group ID names are static with the first order component always called Group1 and the next Group2, and so on.| Order Item | Requested Delivery Date | Group ID |
|---|---|---|
| A | June 9, 2014 | Group1 |
| B | June 10, 2014 | Group1 |
| C | June 11, 2014 | Group2 |
| D | June 12, 2014 | Group2 |
| E | June 12, 2014 | Group3 |
See "About Component Specification Custom Component ID XQuery Expressions" for more information about the context, prolog, and body of this XQuery. See "OSM XQuery Functions" for more information about the OrchestrationXQueryFunctions class.
You can specify a minimum duration separation value for order items that fall very close to a custom Order ID grouping based on order item requested delivery date and duration. For example, the following XQuery adds a minimum separation value of one day:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model"; declare namespace prop="http://oracle.communications.ordermanagement.unsupported.centralom"; declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions"; let $groupDuration := "P2D" let $minSeparationDuration := "P1D" return osmfn: getGroupIdByDateTime ($groupDuration, $minSeparationDuration)
All order item requested delivery dates that fall within one day of a two day grouping, would be included in the two day grouping.
The following table shows how the five order items would be grouped given a one day minimum separation duration.
| Order Item | Requested Delivery Date | Group ID |
|---|---|---|
| A | June 9, 2014 | Group1 |
| B | June 10, 2014 | Group1 |
| C | June 11, 2014 | Group1 |
| D | June 12, 2014 | Group2 |
| E | June 12, 2014 | Group2 |
See "About Component Specification Custom Component ID XQuery Expressions" for more information about the context, prolog, and body of this XQuery. See "OSM XQuery Functions" for more information about the OrchestrationXQueryFunctions class.
You can combine the function to create custom Component IDs based on order item requested delivery date, duration, and minimum duration separation, or a combination of these functions with order component ID generation based on order item hierarchy. The following example creates separate component IDs for order items that, although they have the same requested delivery date, are part of different order item hierarchical groupings:
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model";
declare namespace prop="http://oracle.communications.ordermanagement.unsupported.centralom";
declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions";
let $groupDuration := "P2D"
let $minSeparationDuration := "P1D"
return
osmfn: getGroupIdByDateTime ($groupDuration, $minSeparationDuration)
let $rootAncestorID := osmfn:ancestors("eboLineItem", "default", "http://xmlns.oracle.com/communications/ordermanagement")[fn:last()]/osm:properties/prop:BaseLineId/text()
return fn:concat($rootAncestorId, '/', $groupId)
The following table shows how five hierarchically divided order items would be grouped given a one day minimum separation duration.
| Order Item | Requested Delivery Date | Group ID | Component ID |
|---|---|---|---|
| A.1 | June 9, 2014 | Group1 | A/Group1 |
| A.1.1 | June 11, 2014 | Group1 | A/Group1 |
| A1.2 | June 19, 2014 | Group2 | A/Group2 |
| A.1.3 | June 20, 2014 | Group2 | A/Group2 |
| B.1 | June 9, 2014 | Group1 | B/Group1 |
| B.1.1 | June 11, 2014 | Group1 | B/Group1 |
| B.1.2 | June 12, 2014 | Group1 | B/Group2 |
See "About Component Specification Custom Component ID XQuery Expressions" for more information about the context, prolog, and body of this XQuery. See "OSM XQuery Functions" for more information about the OrchestrationXQueryFunctions class.
This topic applies to the Order Component editor, Duration tab, Duration Expression area, XQuery subtab.
Context: There is no input document for this expression.
Prolog: There is no prolog required for this expression.
Body: The XQuery body returns a duration value based on the XQuery you enter:
PyYmMdDThHmMsS
where
P begins the expression.
yY specifies the year.
mM specifies the month.
dD specifies the day.
T separates the parts of the expression indicating the date from the parts of the expression indicating the time.
hH specifies the hour.
mM specifies the minutes.
sS specifies the seconds.
The following example is a hard-coded duration expression for seven hours:
PT7H0M0S
For more information about how OSM uses these fields to calculate order component durations, see OSM Modeling Guide.
This topic applies to the Fulfillment Pattern editor, Orchestration Plan tab, Duration subtab, Duration Expression area, XQuery subtab. The functionality for this tab has been deprecated and is displayed to provide backward compatibility with older cartridges.
For the recommended functionality for configuring order component durations, see "About Fulfillment Pattern Component Duration XQuery Expressions" and "About Component Specification Duration XQuery Expressions".
This topic applies to the Fulfillment Pattern editor, Orchestration Plan tab, Order Components subtab, Duration subtab, Duration Expression area, XQuery subtab.
Context: There is no input document for this expression.
Prolog: There is no prolog required for this expression.
Body: The XQuery body returns a duration value based on the XQuery you enter:
PyYmMdDThHmMsS
where
P begins the expression.
yY specifies the year.
mM specifies the month.
dD specifies the day.
T separates the parts of the expression indicating the date from the parts of the expression indicating the time.
hH specifies the hour.
mM specifies the minutes.
sS specifies the seconds.
The following example is a hard-coded duration expression for three hours:
PT3H0M0S
For more information about how OSM uses these fields to calculate order component durations, see OSM Modeling Guide.