5 Extending Order-to-Activate Cartridges

This chapter describes how to extend the Order-to-Activate cartridges for Oracle Communications Order and Service Management (OSM).

The Order-to-Activate cartridges are provided as a working foundation which you can extend to design and build a solution. This chapter provides details and guidelines on how to extend the base model entities.

Adding Custom Data Elements

To add custom data elements to the Order-to-Activate cartridges, please see knowledge article 1514936.1, Data Enrichment - Extending Order to Activate Cartridges, on the Oracle support Web site:

https://support.oracle.com

Adding Custom Order Item Properties

You can add custom order item properties to your order template without unsealing any cartridges. The following XML-type variable is available in the COM_Sales_OrderFulfillment order template:

ControlData
    OrderItem
        CustomXmlData

This data element allows the addition of custom properties, but it does not support significance or revision, and it cannot be used for component wait dependencies.

You can populate custom properties into that element by using the following URI for the CustomXmlData property in the Order Item Specification editor:

http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/CustomXmlData.xquery

After installation, the shell for the CustomXmlData.xquery file is located in the SolutionCartridge/resources/CustomExtensions folder, where SolutionCartridge is the cartridge for your solution, as listed in Table 5-1:

Table 5-1 Solution Configurations and Corresponding Solution Cartridge Names

Using Calculate Service Order Option?	Current Workspace Is for:	Topology	Solution Cartridge
Yes	COM only	All	OracleComms_OSM_O2A_COM_CSO_Solution
Yes	SOM only	All	OracleComms_OSM_O2A_SOM_CSO_Solution
Yes	COM and SOM	All	OracleComms_OSM_O2A_COMSOM_CSO_Solution
No	COM only	Simple	OracleComms_OSM_O2A_COM_Simple_NP_Soln
No	COM only	Typical or Complex	OracleComms_OSM_O2A_COM_Typical_NP_Soln
No	SOM only	All	OracleComms_OSM_O2A_SOM_NP_Soln
No	COM and SOM	Simple	OracleComms_OSM_O2A_COMSOM_Simple_NP_Soln
No	COM and SOM	Typical or Complex	OracleComms_OSM_O2A_COMSOM_Typical_NP_Soln

Note:

If you edit the CustomXmlData.xquery file, save a copy of the updated file to the custom-extension folder in the OracleComms_OSM_O2A_Configuration cartridge. This ensures that your changes will not be overwritten if you reconfigure your workspace.

Following is a sample of a configured CustomXmlData.xquery file:

Example 5-1 Sample CustomXmlData.xquery File

import module namespace fulfillmentmodecodefn = "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/fulfillmentmodecodefn" at "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/FulfillmentModeCode.xqy";
import module namespace fulfillmentcondprovfn = "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/fulfillmentcondprovfn" at "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/FulfillmentCondProv.xqy";
import module namespace fulfillmentcondfn = "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/fulfillmentcondfn" at "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/FulfillmentCond.xqy";
import module namespace completeshippingfn = "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/completeshippingfn" at "http://xmlns.oracle.com/communications/ordermanagement/o2a/customextensions/CompleteShipping.xqy";
 
declare namespace prop = "COM_SalesOrderFulfillment";
declare namespace salesord="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V2";
 
declare variable $inputDoc as document-node() external;
 
let $ebm := $inputDoc/GetOrder.Response/_root/messageXmlData/salesord:ProcessSalesOrderFulfillmentEBM
let $line := .
 
return
(
    <prop:CustomProperties>
        <prop:CompleteShipping>{completeshippingfn:CompleteShipping($line, $ebm)}</prop:CompleteShipping>
        <prop:FulfillmentCond>{fulfillmentcondfn:FulfillmentCond($line, $ebm)}</prop:FulfillmentCond>
        <prop:FulfillmentCondProv>{fulfillmentcondprovfn:FulfillmentCondProv($line, $ebm)}</prop:FulfillmentCondProv>
        <prop:FulfillmentModeCode>{fulfillmentmodecodefn:FulfillmentModeCode($line, $ebm)}</prop:FulfillmentModeCode>
    </prop:CustomProperties>
)

Changing Durations for Order Components

You can change the Optimistic, Most Likely, and Pessimistic order component durations. If you create custom functional order components, you can change the values in the Order Component Specification editor, like you would for any non-Order-to-Activate configuration. However, since the standard Order-to-Activate functional order components are in a sealed cartridge, you should not edit the order component durations in the normal way, but instead using the instructions in this section.

Note:

As in non-Order-to-Activate scenarios, the duration settings for fulfillment patterns override the duration settings for order components. Since Order-to-Activate fulfillment patterns are not in sealed cartridges, you can edit durations for the fulfillment patterns in the normal way, using the Fulfillment Pattern editor in Design Studio. See Design Studio Modeling OSM Orchestration Help for more information about setting durations for fulfillment patterns.

To change durations for standard Order-to-Activate functional order components:

1. Edit the workspace\OracleComms_OSM_O2A_Configuration\solution-config\ComponentDurationMap.xml file, where workspace is the directory containing the files for your Order-to-Activate workspace.

   You can edit this file in any text or XML editor or in Eclipse. If you use Eclipse, use the Package Explorer view to find the file.

2. Find the entry for the order component you would like to modify. The name of the order component is located in the OrderComponentSpec tag. The example below shows the element tag for the SyncCustomerFunction functional order component:

   <model:orderComponentSpec name="SyncCustomerFunction" namespace="COM_SalesOrderFulfillment">
   

3. Update the durations you would like to change. The durations are in the standard XML date/time format:

   PnYnMnDTnHnMnS
   

   for example:

   P0Y0M0DT0H2M0S
   

   which indicates a duration of two minutes.

   The individual elements of the format are:

   • P indicates the period

   • nY indicates the number of years

   • nM indicates the number of months

   • nD indicates the number of days

   • T indicates the start of a time section

   • nH indicates the number of hours

   • nM indicates the number of minutes

   • nS indicates the number of seconds

4. Save and close the workspace\OracleComms_OSM_O2A_Configuration\solution-config\ComponentDurationMap.xml file.

5. In Design Studio, go to the Ant view and look for the SolutionConfig.xml build file you added when you installed the Order-to-Activate cartridges.

   Note:

   If you have removed this file from your workspace, see "Configuring WebLogic Server Resources" and follow steps 1 through 4.

6. Expand the SolutionConfig.xml build file and double-click the config_Metadata_And_ModelVariable target.

   This updates the metadata so that the system will use the new values you have configured.

Adding a New Fulfillment Function

A fulfillment function represents an activity, for example billing or provisioning, that must be performed to process an order item. You can add a new fulfillment function for a new action or you can extend an existing fulfillment function to add data elements and entities without unsealing the productized Order-to-Activate cartridges.

Planning the Addition of a New Fulfillment Function

This section contains planning considerations for adding a new fulfillment function to a solution.

• Is the new fulfillment function for a system type that is already modeled in the Order-to-Activate cartridge, or is it for a new system type?

  • If the new fulfillment function is for a new system type, you must know the naming convention configured in Oracle Application Integration Architecture (Oracle AIA) deployments for logical identifiers of instances of the new system type. See the coverage of EBMHeader/Sender/ID and EBMHeader/Target/ID elements for the various system interactions in Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack. The Sender IDs and Target IDs in the EBM messages must match the logical identifiers for the system instances configured in the Oracle AIA deployment. See "Considerations When Integrating with Oracle AIA."

  • Following is a summary of naming conventions for fulfillment functions in Oracle AIA:

    • Naming convention used for OSM central order management instances: OSMCFS_01, OSMCFS_02, and so on.

    • Naming convention used for OSM service order management instances: OSMPROV_01, OSMPROV_02, and so on.

    • Naming convention used for Billing and Revenue Management instances: BRM_01, BRM_02, and so on.

    • Naming convention used for Siebel Customer Relationship Management (Siebel CRM) instances: SEBL_01, SEBL_02, and so on.

• What is the message format for the fulfillment function request and response?

  • The fulfillment function request must conform to an Enterprise Business Message (EBM).

  • The fulfillment function response can be either an EBM or an OrderFalloutNotification. Oracle AIA specifies XML schemas for the EBMs which describe the request and response format.

• What are the JNDI names for the source and destination queues that are used to exchange request and response messages between OSM and Oracle AIA for the new fulfillment function?

• What are the data elements on the order that are compensation-significant for the new fulfillment function? Compensation-significant data elements trigger compensation if a revision order contains changes to the values.

• What service action codes will apply to the current fulfillment function? The predefined service action codes include:

  • ADD: Add a new service.

  • UPDATE: Make a change to an existing service.

  • DELETE: Remove a service.

  • SUSPEND: Suspend a service.

  • RESUME: Resume a suspended service.

  • MOVE-ADD: Add service as part of a service location move process.

  • MOVE-DELETE: Remove service as part of a service location move process.

  • NONE: Make no service change.

• What processing is required for the different execution modes? The following execution modes supported in the existing Order-to-Activate fulfillment function and are mandatory:

  • do is required to handle new orders and change orders

  • redo is required for amendment processing to fulfill an order revision

  • undo is required for order cancellation

• What data elements from the fulfillment request XML schema must be included in the outbound fulfillment request?

  • Identify the data elements that must be copied as-is by OSM from the customer order to the fulfillment request. This data exists in the OSM order data in the messageXMLData element and does not need to be modeled separately.

  • Identify the data that must be generated by OSM and inserted into the fulfillment request. Consider data generation for all OSM execution modes: do, redo, and undo.

• What data elements from the fulfillment response XML schema must be included in data updates to Siebel CRM or included in subsequent fulfillment function requests? For example, you might include a service ID returned from provisioning that must be included in the fulfillment-data updates to Siebel CRM and in the FulfillBilling request that takes place after provisioning is complete.

Response Patterns in System Interactions

There are two patterns of handling responses in system interactions, the single-response pattern and the multiple-response pattern. Single-response patterns receive a single response in a system interaction with the Oracle AIA billing service, while multiple-response patterns can receive multiple responses.

Single Response Pattern

The single-response pattern is used in billing functions. Each billing function is transactional. In a system interaction with the Oracle AIA billing service, a single response is expected which is either a response EBM or an OrderFalloutNotification created by Oracle AIA error handling framework, and not both.

If a revision order with compensation-significant updates for the billing function arrives while the request is in progress in OSM central order management (that is, after an EBM has been put on the queue for the Oracle AIA billing service to pick up but before the arrival and processing of a response), the amendment is queued until the response is processed.

In this case, a single automated task in the subprocess for the fulfillment function (such as SyncCustomerSITask, InitiateBillingSITask, or FulfillBillingSITask) includes automation to generate the EBM and put it on a queue in do, redo, and undo execution modes, and the same automated task also includes automation to correlate and process the response from Oracle AIA.

Multiple Response Pattern

The multiple-response pattern is used in the ProvisionOrderFunction. In a system interaction with the Oracle AIA order provisioning service, multiple responses are expected in the form of a sequence of response EBMs of type ProcessFulfillmentOrderUpdateEBM or an OrderFalloutNotification created by the Oracle AIA error-handling framework.

If a revision order with compensation-significant updates for the ProvisionOrderFunction arrives while a request is in progress in OSM central order management (that is, after a request EBM has been put on the queue for the Oracle AIA provisioning service to pick up but before the arrival and processing of a response), then a separate request for the revision is sent to the Oracle AIA order provisioning service.

In this case, a separate automated task, such as ProvisionOrderSIResponseTask, is needed in the subprocess to correlate and process the responses. The success flow without debugging breakpoints then becomes:

1. YourFunctionNameEntryPointTask

2. YourFunctionNameSITask

3. YourFunctionNameSIResponseTask

Entities to Create, Modify, or Reuse

Table 5-2 provides an overview of the entities that may be created, modified, or reused in the creation of a fulfillment function. Further information about many of these entities is provided in the following sections.

Table 5-2 Entities to be Created, Modified, or Reused

Name	Type	Remarks
OracleComms_OSM_CommonDataDictionary OracleComms_OSM_O2A_AIAEBMDataDictionary	Data Dictionary	See "Data Dictionary and Order Templates" for information about how to make changes for the new fulfillment function.
COM_SalesOrderFulfillment_CreationTask	Manual Task	See "About Creation Tasks" for information about adding to task data for the new fulfillment function.
COM_SalesOrderFulfillment_OrderDetails	Manual Task	See "About Query Tasks" for information about adding to task data for the new fulfillment function.
FUNCTION/YourSystemTypeFunction extends FulfillmentFunction FUNCTION/YourFunctionNameFunction extends YourSystemTypeFunction SYSTEM/YourSystemTypeSystem extends FulfillmentSystem UPDATES/YourFunctionNameSignificantUpdates extends SignificantUpdates	Order Component Specification	If your system type is an already modeled system type such as Billing, you reuse the existing entities, for example: FUNCTION/BillingFunction and SYSTEM/BillingSystem Existing GRANULARITY order component specifications are reusable for new fulfillment functions without any modifications.
SUBPROCESS/YourFunctionNameSubProcess	Process	See "About Subprocesses."
TASK/YourFunctionNameEntryPointTask TASK/YourFunctionNameSITask	Automated Task	See "About Subprocesses" for automated tasks to be created for the new subprocess for the new fulfillment function.
TASK/YourFunctionNamePreSITask TASK/YourFunctionNamePostSITask TASK/YourFunctionNameFalloutRecoverTask TASK/YourFunctionNameWaitForAmendmentTask TASK/YourFunctionNameEPQTask extends TASK/YourFunctionNameEntryPointTask TASK/YourFunctionNameSIQTask extends TASK/YourFunctionNameSITask	Manual Task	See "About Subprocesses" for manual tasks to be created for the new subprocess for the new fulfillment function.

Data Dictionary and Order Templates

Additional data fields for the new fulfillment function can be defined in the cartridge created for it. All order template entities can be placed in a separate cartridge, in an order that extends from COM_SalesOrderFulfillment. Orchestration sequences, processes, and tasks for the new fulfillment function can also be placed in this separate cartridge.

An XML data type element named messageXMLdata is used to store the incoming customer order data in an XML format inside the OracleComms_OSM_O2A_COM_Base cartridge. This element is defined in the OracleCgbuCommonDataDictionary data dictionary and is included in the order template. It should be added to any new tasks that require access to the raw customer order data. The raw data is used by automated tasks that copy some data as-is to the fulfillment request.

Model additional fields in the LineItemData structure in the data dictionary. The element names, types, and sub-structures in LineItemData mimic the structure of the SalesOrderLine structure in the Oracle AIA SalesOrderEBM schema. The following sections contain information about these changes.

Order Change Management Configuration

You may need to model data for order change management configuration including keys and data significance. Add all data elements from the customer order line that are compensation-significant for the fulfillment function to the LineItemData structure (if they do not already exist in the LineItemData structure).

Customize a copy of the BaseLineItemData.xquery XQuery file located in OracleComms_OSM_O2A_COM_Base/resources/OrderItemProperties to add code to copy compensation-significant data for the new fulfillment function from the customer order line to the order line item property BaseLineItemData.

Note:

Use XML catalogs to specify the location of XQuery files. Use a unique namespace prefix to avoid naming conflicts.

Data Required for Sending the Fulfillment Request or Processing the Fulfillment Request Response

You may need to model data that must be generated by OSM and copied to the fulfillment request, not including service order identification and service order line identification. Add these to the LineItemData structure (if they do not already exist in the LineItemData structure). An example of this is new and prior values for customized billing date calculations to send to a billing provider.

You may also need to model data that can be updated back to central order management from the fulfillment system.

Additional Control Data Required for Orchestration Logic

If the new fulfillment function can process order items with a service action code of UPDATE or MOVE-ADD, add an element such as OrderItemHasYourFunctionNameUpdates to the OrderItemControl structure. You can make a copy of CommunicationsSalesOrderItemProperties_OrderItemControl.xqy and edit the XQuery to set the property value for each order item. A value of YES means that this order item has relevant changes for your fulfillment function to process. A service action code has relevant changes if it is a service action code that the fulfillment function can process, or in the case of UPDATE or MOVE-ADD, a service action code with compensation-significant updates.

Add a condition to the decomposition rule that decomposes from YourFunctionNameFunction to YourFunctionName SignificantUpdates. The condition checks for the existence of at least one order item in the fromOrderComponent that has OrderItemHasYourFunctionNameUpdates set to YES. This avoids creating an executable order component (which avoids generating and sending a fulfillment request) when there are no order items with relevant changes for the fulfillment function to process.

Data that Must be Modeled in the Order Template

If any additional data must be modeled in the order template:

• Follow the same pattern as for the existing fulfillment functions model ControlData/Functions/YourFunctionNameFunction

• Any data that must be generated by OSM and copied to the fulfillment request or data that can be updated back to central order management from the fulfillment system is added to:

  ControlData/OrderItem/WorkLineItemData for OSM-generated new values, or new values from fulfillment function response

  ControlData/OrderItem/WorkPriorLineItemData for OSM-generated prior values

  ControlData/OrderItem/BaseLineItemData for significance information for compensation

• Any additional control data required for the orchestration logic

About Creation Tasks

COM_SalesOrderFulfillment_CreationTask is the creation task for the OSM COM_SalesOrderFulfillment order. With the Order-to-Activate composite cartridge, you can add data to this creation task through the task data contribution tab in the Order-to-Activate composite cartridge for the new fulfillment function.

About Query Tasks

COM_SalesOrderFulfillment_OrderDetails is the query task for the OSM COM_SalesOrderFulfillment order. With the Order-to-Activate composite cartridge, you can add data to this query task through the task data contribution tab in the Order-to-Activate composite cartridge for the new fulfillment function.

About Subprocesses

A system interaction configured in the OracleComms_OSM_O2A_COM_Base cartridge handles the asynchronous communication of service order data to a fulfillment system instance. A fulfillment system instance is also referred to as a fulfillment provider. The system interaction should handle the delivery of a relevant subset of service order data to the fulfillment provider. When triggered, the system interaction also invokes the correct subprocess which represents the fulfillment function for the order component. Additionally, the system interaction must handle responses from the fulfillment provider and cope with messaging, fallout, status and data updates, and order change management.

Model the subprocess following the pattern established for the existing fulfillment functions as depicted in Figure 5-1. Prefix task names with YourFunctionName. The flow of the process is described in Table 5-3.

Figure 5-1 Creating Subprocesses

The manual tasks YourFunctionNamePreSITask, and YourFunctionNamePostSITask are optional. They are useful as cartridge breakpoints for a number of purposes including providing the user the ability to control process flow before and after functions and to examine data in the process flow for revision testing. Cartridge breakpoints stop at manual tasks in subprocess flows for system interactions. In a success flow, the process flows distinguish whether to exit with 'success_debug' status (to include manual tasks in the subprocess flow) or success status (to skip the manual tasks in the subprocess flow).

Table 5-3 lists the tasks and flows associated with subprocess.

Table 5-3 Flows and Tasks

Flow patterns	Tasks associated
Success flow without debug breakpoints	Start --> YourFunctionNameEntryPointTask --> YourFunctionNameSITask --> End
Success flow with debug breakpoints	Start --> YourFunctionNameEntryPointTask --> YourFunctionNamePreSITask (manual) --> YourFunctionNameSITask --> YourFunctionNamePostSITask (manual) --> End
Failure flows	Start --> YourFunctionNameEntryPointTask --> YourFunctionNameSITask -->YourFunctionNameFalloutRecoverTask (manual) --> Option 1: abort End Option 2: wait for amendment YourFunctionNameWaitForAmendmentTask (manual) --> End Option 3: retry

Significance must be set in the task data for the nodes in CreateCommunicationsSalesOrderTask and the tasks in the subprocess for the fulfillment function YourFunctionName.

The system interaction for the fulfillment function is implemented by a subprocess named YourFunctionNameSubProcess in the Order-to-Activate cartridges. The automated tasks in the subprocess accomplish the following:

1. Accept input data from the original EBM message destined for the outbound message and properties for each of the configurable data elements.

   • Input data to pass through from the original message (ProcessSalesOrderFulfillmentEBM) to the outbound message:

     • Reference to the message header (EBMHeader) from the original EBM

     • Reference to the customer order header (DataArea/ProcessSalesOrderFulfillment) from the original EBM

     • References to line items from the original EBM destined for the outbound message

     The inbound message is expected to conform to the schema AIAComponents\EnterpriseObjectLibrary\Industry\Communications\EBO\SalesOrder\V2\SalesOrderEBM.xsd

   • Input data for the configurable elements of the outbound message:

     • EBMHeader/Sender/ID and all EBMHeader/Sender element values

     • EBMHeader/Target/ID

2. Automation actions in the automated task YourFunctionNameEntryPointTask update the order item data required for the fulfillment function system interaction. Copy the SIEntryPoint.xqy file, and customize it as needed.

   Use XML catalogs to specify the location of the XQuery files. Use a unique namespace prefix to avoid naming conflicts.

   Table 5-4 lists the XML catalogs.

   Table 5-4 XML Catalogs

   Automation Action	Execution Modes	Automation Type	Event Type	Customize
   'YourFunctionNameEntryPointBean_doredo'	do, redo	XQuery Sender	Internal	Customize a copy of the SIEntryPoint.xqy XQuery file to add code to update order data before message generation for the new fulfillment function.

   
   

   • Logic for do and redo execution modes (if applicable) include updating the order data in ControlData/Functions/YourFunctionName/orderItem/orderItemRef/WorkLineItemData. Because orderItemRef is a reference, subsequent functions on the same order line reference the same instance of the data. Any additional data that is generated by OSM for the fulfillment function request should be updated.

3. Automation actions YourFunctionNameRequestBean_do, YourFunctionNameRequestBean_redo, YourFunctionNameRequestBean_undo in automated task YourFunctionNameSITask are configured as internal XQuery Senders to use the XQuery automation plug-in to construct the payload for the outbound message, in do, redo, and undo modes, respectively (if applicable).

   • Outbound message format: Identify the EBM

   • Outbound message schema: Identify the Oracle AIA schema. For example, the schema for the billing functions is: AIAComponents\EnterpriseObjectLibrary\Industry\Communications\EBO\FulfillmentOrder\V1\FulfillmentOrderEBM.xsd.

   • Relevant line items: all line items targeted at the same fulfillment provider

4. Configure automation actions in the automated task YourFunctionNameSITask to generate messages in the EBM format and send the XML payload over JMS. You must specify the JNDI name of the JMS destination.

   Table 5-5 lists the automation actions and the XQueries to be customized.

   Table 5-5 Automation Actions

   Automation Action	Execution Modes	Automation Type	Event Type	Customize
   YourFunctionNameRequestBean_do	do	XQuery Sender	Internal	Customize a copy of the AIAEBMRequest_do.xqy XQuery file to add code to update the order data before message generation for the new fulfillment function.
   YourFunctionNameRequestBean_redo	redo	XQuery Sender	Internal	Customize a copy of the AIAEBMRequest_redo.xqy XQuery file to add code to update the order data before message generation for the new fulfillment function.
   YourFunctionNameRequestBean_undo	undo	XQuery Sender	Internal	Customize a copy of the AIAEBMRequest_undo.xqy XQuery file to add code to update the order data before message generation for the new fulfillment function.

   
   

5. Configure automation action YourFunctionNameResponseBean in automated task YourFunctionNameSITask as an external XQuery Automator to process responses. You must specify the JNDI name of the JMS source.

   Table 5-6 lists the automated XQueries.

   Table 5-6 Automated XQueries

   Automation action	Execution Modes	Automation Type	Event Type	Customize
   YourFunctionNameResponseBean	N/A	XQuery Automater	External	Customize a copy of the AIAEBMResponse.xqy XQuery file to add code to update the order data before message generation for the new fulfillment function.

   
   

   • Success response: Recognize and process a successful response. Set the reached milestone to YOUR FUNCTION NAMECOMPLETE. A successful response is a well-formed response message, that conforms to the response EBM format, with an empty or non-existent EBMHeader/FaultNotification and FaultMessage Code.

   • Failure response: Recognize and process failure responses that OSM expects to be either a response EBM, or an OrderFalloutNotification.

   • No response: In this case OSM expects an OrderFalloutNotification from Oracle AIA.

Fulfillment Function Extension Point Interface

The Order-to-Activate cartridges use XQuery resources to perform functions including setting order item properties, mapping product specifications to fulfillment patterns, managing fulfillment function dependencies, and managing the order life cycle. One way to customize XQueries is to rewrite or add to a provided XQuery module and use the XML catalog to enable URI reference mapping. Fulfillment function extension points have different input parameters depending on whether you are using the calculate service order solution option or the solution option without calculate service order. Both sets of input parameters are provided in the tables in this section. Extension points are defined for both fulfillment functions and fulfillment states. This section contains information about the fulfillment function extension points. For information about the fulfillment state extension points, see "Fulfillment State Extension Point Interface."

XML catalogs are system-wide entities, which means an XML Catalog specified in one cartridge will be used when processing requests for orders on other cartridges. With the use of solution cartridges, multiple solutions can be deployed to a single system and coexist with each other.

Each fulfillment function extension point has one XQuery API except for CREATE-EBM, which has three: one for each execution mode (do, redo, and undo).

An XQuery extension script must be implemented in a standalone file. The file URI must be registered to the extension configuration.

Fulfillment Function Extension Point Overview

Table 5-7 lists the XQuery extension points for fulfillment functions in the Order-to-Activate cartridges.

Table 5-7 Fulfillment Function Extension Points

Fulfillment Function Extension Point	Description
COMPONENT-START	Fulfillment function start extension point. The extension is expected to return a list of OrderItem properties to be updated when the fulfillment function is started.
COMPONENT-COMPLETE	Fulfillment function complete extension point. The extension is expected to return a list of OrderItem properties to be updated when the fulfillment function is completed.
COMPONENT-UPDATE	Fulfillment function update extension point. The extension is expected to return a list of OrderItem properties to be updated when the fulfillment function is updated.
CREATE-EBM	Fulfillment function create payload extension point. The extension is expected to return the EBM to be sent to the external system in do, redo, or undo mode operations.
CREATE-EBM-CUSTOM	Fulfillment function create payload extension point with order level Custom XML element in the EBM.
CREATE-EBM-ALL-ORDERITEMS	Fulfillment function create payload extension point for all order items. The extension is expected to return the EBM to be sent to the external system.
CREATE-EBM-ORDERITEM	Fulfillment function extension point to create an XML fragment for a single order item in do, redo, or undo mode operations.
CREATE-EBM-ORDERITEM-CUSTOM	Fulfillment function extension point to create an XML fragment for a single order item that has an order-item-level Custom XML element in the EBM.
CREATE-EBM-PRIORORDERITEM	Fulfillment function extension point to create an XML fragment for a single prior order item.
CREATE-EBM-PRIORORDERITEM-CUSTOM	Fulfillment function extension point to create a payload with prior-order-item-level Custom XML element in the EBM.
VALIDATE-RESPONSE-EBM	Fulfillment function response validation extension point. The extension is expected to validate the EBM response coming back from the external system.
COMPONENT-RESPONSE-UPDATE	Fulfillment function response update extension point. The extension is expected to return a list of OrderItem properties to be updated when a valid EBM response comes back from the external system.
ORDER-EXTENSION-UPDATE-STATUS-EBM	Fulfillment function update extension point for status updates from central order management to the upstream system. The extension is expected to return an EBM containing sales order status and other information. Other systems, such as Customer Asset Manager can also listen to the output of this extension point to create or update asset information.

When a fulfillment function is introduced, you can create an ExtensionPointMap entry for each applicable fulfillment function extension point (such as Component Start) in the resources\SolutionConfig\ComponentExtensionPointMap.xml of the Order-to-Activate composite cartridge. You must create a separate XQuery file for each fulfillment function extension point.

COMPONENT-START Extension Point

This section describes the XQuery script that implements the logic to handle the COMPONENT-START extension point.

Table 5-8 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-8 COMPONENT-START Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log.
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
$component	element()	External variable	XML fragment containing the fulfillment function data
.	element()	Context node	Order item data XML fragment

Table 5-9 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-9 COMPONENT-START Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log.
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
.	element()	Context node	Order item data XML fragment

Table 5-10 lists the return parameters for the extension point XQuery.

Table 5-10 COMPONENT-START Return Parameters

Output Parameter Type	Description
element()*	XML wrapper element that contains all the order item properties to be updated

Example 5-2 is a sample XQuery code fragment for the COMPONENT-START fulfillment function extension point.

Example 5-2 COMPONENT-START XQuery Code Fragment

import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";

declare variable $executionMode external;
declare variable $breakpointDebugControl external;
declare variable $taskInputData external;

(: This function registers to the YourFunctionName/START event.
 : It returns a list of elements which are the properties to be updated for 
 : the given order item. :)
declare function YourFunctionNamefn:onYourFunctionNameStart(
    $execMode as xs:string,
    $lineItem  as element(),
    $taskData as element(),
    $debugControl as element()) as element()*
{
    let $id := $lineItem/oms:BaseLineId
    return 
        <BaseLineId>{ $id/text() }</BaseLineId>,
        (: list of order item properties to be updated :) 
};
 
let $lineItem := .
return
    <OrderItem>
    {
        YourFunctionNamefn:onYourFunctionNameStart($executionMode, $lineItem, $taskInputData, $breakpointDebugControl)
    }
    </OrderItem>

COMPONENT-COMPLETE Extension Point

This section describes the XQuery script that implements the logic to handle the COMPONENT-COMPLETE extension point.

Table 5-11 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-11 COMPONENT-COMPLETE Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$component	element()	External variable	XML fragment containing the fulfillment function data
$executionMode	xs:string	External variable	Task execution mode
$orderItemFromResponse	element()	External variable	Order item data from the response message
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
.	element()	Context node	Order item data XML fragment

Table 5-12 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-12 COMPONENT-COMPLETE Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$executionMode	xs:string	External variable	Task execution mode
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
.	element()	Context node	Order item data XML fragment

Table 5-13 lists the return parameters for the extension point XQuery.

Table 5-13 COMPONENT-COMPLETE Return Parameters

Output Parameter Type	Description
element()*	XML wrapper element which contains all the order item properties to be updated

Example 5-3 is a sample XQuery code fragment for the COMPONENT-COMPLETE fulfillment function extension point.

Example 5-3 COMPONENT-COMPLETE XQuery Code Fragment

import module namespace pipextensionmodule = "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule" at "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule/ExtensionPointModule.xquery";
import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";
 
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
 
declare variable $hasFallout external;
declare variable $falloutMessage external;
 
(: This function register to the YourFunctionName/COMPLETE event.
 : It return a list of elements that are the properties to be updated for 
 : the given order item. :)
declare function YourFunctionNamefn:onYourFunctionNameComplete(
    $lineItem as element(), 
    $hasFallout as xs:boolean, 
    $falloutMessage as xs:string*) as element()*
{
    let $id := $lineItem/oms:BaseLineId
    return 
        <BaseLineId>{ $id/text() }</BaseLineId>,
        (: list of order item properties to be updated :)
};
 
let $lineItem := .
return
    <OrderItem>
    {
        YourFunctionNamefn:onYourFunctionNameComplete($lineItem, $hasFallout, pipextensionmodule:unWrapStringParameter($falloutMessage))
    }
    </OrderItem>

COMPONENT-UPDATE Extension Point

This section describes the XQuery script that implements the logic to handle the COMPONENT-UPDATE extension point.

Table 5-14 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-14 COMPONENT-UPDATE Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$executionMode	xs:string	External variable	Task execution mode
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
$milestoneCode	xs:string	External variable	Injected milestone code
.	element()	Context node	Order item data XML fragment

Table 5-15 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-15 COMPONENT-UPDATE Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$executionMode	xs:string	External variable	Task execution mode
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$breakpointDebugControl	element()	External variable	Break Point Control XML fragment
$taskInputData	element()	External variable	Task data XML fragment with the schema for GetOrder.Response
$milestoneCode	xs:string	External variable	Injected milestone code
.	element()	Context node	Order item data XML fragment

Table 5-16 lists the return parameters for the extension point XQuery.

Table 5-16 COMPONENT-UPDATE Return Parameters

Output Parameter Type	Description
element()*	XML wrapper element which contains all the order item properties to be updated

Example 5-4 is a sample XQuery code fragment for the COMPONENT-UPDATE fulfillment function extension point.

Example 5-4 COMPONENT-UPDATE XQuery Code Fragment

import module namespace pipextensionmodule = "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule" at "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule/ExtensionPointModule.xquery";
import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";
import module namespace pipbreakpointfn = "http://xmlns.oracle.com/communications/ordermanagement/pip/pipbreakpointmodule" at "http://xmlns.oracle.com/communications/ordermanagement/pip/pipbreakpointmodule/BreakpointControlModule.xquery";
 
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
declare namespace salesord="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V2";
 
declare variable $executionMode external;
declare variable $breakpointDebugControl external;
declare variable $taskInputData external;
declare variable $hasFallout external;
declare variable $falloutMessage external;
declare variable $milestoneCode external;
 
declare function YourFunctionNamefn:onYourFunctionNameUpdate(
    $execMode as xs:string,
    $lineItem as element(),
    $taskData as element(),
    $debugControl as element(),
    $milestoneCode as xs:string) as element()*
{
    let $ponrOverride := pipbreakpointfn:checkPONROverride(YourFunctionNamefn, $debugControl)
    let $revisionPermissibleCode := if ($ponrOverride=fn:false()) then "HARD" else "NOT YET"
    let $updateRevisionPermissibleCode := ($taskData/oms:_root/oms:CustomerHeaders/oms:FulfillmentModeCode/text()!="TSQ")
    return
        YourFunctionNamefn:onYourFunctionNameUpdate($execMode, $lineItem, $taskData, $milestoneCode, $updateRevisionPermissibleCode, $revisionPermissibleCode)
};
 
let $lineItem := .
return
    <OrderItem>
    {
        YourFunctionNamefn:onYourFunctionNameUpdate($executionMode, $lineItem, $taskInputData, $breakpointDebugControl, $milestoneCode)
    }
    </OrderItem>

CREATE-EBM Extension Point for do Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM extension point for do execution mode.

Table 5-17 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-17 CREATE-EBM Input Parameters for do Execution Mode for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$orderId	xs:string	External variable	OSM Order ID of the current order
$orderKey	xs:string	External variable	AIA Order Number
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
$component	element()	External variable	XML fragment containing the fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message. This element only applies if the request EBM is sent to service order management (SOM).
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-18 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-18 CREATE-EBM Input Parameters for do Execution Mode for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log.
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$component	element()	External variable	XML fragment containing the fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message. This element only applies if the request EBM is sent to service order management (SOM).
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-19 lists the return parameters for the extension point XQuery.

Table 5-19 CREATE-EBM for do Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the EBM: The EBM format depends on external fulfillment provider requirements.

Example 5-5 is a sample XQuery code fragment for the CREATE-EBM fulfillment function extension point implementation for the do execution mode.

Example 5-5 CREATE-EBM XQuery Code Fragment for do Execution Mode

import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";

declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";

declare variable $ebmHeader external;
declare variable $salesOrderLine external;
declare variable $priorSalesOrderLine external;
declare variable $component external;
declare variable $targetIdentifier external;
declare variable $idMap external;
declare variable $ebmId external;
declare variable $fulfillmentOrderId external;
declare variable $fulfillmentOrderNumber external;
declare variable $faultMode external;

let $fulfillmentOrder := .
return
    <Ebm>
    {
        YourFunctionNamefn:createDoYourFunctionNamePayload(
            $ebmHeader,
            $fulfillmentOrder,
            $salesOrderLine,
            $priorSalesOrderLine,
            $targetIdentifier,
            $idMap,
            $ebmId,
            $fulfillmentOrderId,
            $fulfillmentOrderNumber,
            $faultMode)
    }
    </Ebm>

CREATE-EBM Extension Point for redo Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM extension point for the redo execution mode.

Table 5-20 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-20 CREATE-EBM Input Parameters for redo Execution Mode for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$orderId	xs:string	External variable	OSM Order ID of the current order
$orderKey	xs:string	External variable	AIA Order Number
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function
$histTransformedOrderLines	element()	External variable	XML fragment of all transformed order items belonging to the current fulfillment function before the revision
$histMappingContext	element()	External variable	XML fragment describing the pre-revision mapping context between all sales order items and transformed order items belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$histSalesOrderLine	element()	External variable	All order lines belonging to the current fulfillment function before amendment
$histPriorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function before amendment
$deletedlineItems	element()	External variable	Order lines that were deleted by the amendment
$deletedTransformedLineItems	element()	External variable	XML fragment of all deleted transformed order lines belonging to the current fulfillment function
$deletedpriorlineItems	element()	External variable	Prior order line data that was deleted by the amendment
$deletedMappingContext	element()	External variable	XML fragment describing the deleted mapping context for all sales order items and transformed order items belonging to the current fulfillment function
$addedlineItems	element()	External variable	Order line data that was added by the amendment
$component	element()	External variable	XML fragment containing the fulfillment function data
$histComponent	element()	External variable	XML fragment with the pre-amendment fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$histIdMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the BusinessComponentID populated into the earlier EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message. This element only applies if the request EBM is sent to service order management (SOM).
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-21 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-21 CREATE-EBM Input Parameters for redo Execution Mode for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$histSalesOrderLine	element()	External variable	All order lines belonging to the current fulfillment function before amendment
$histPriorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function before amendment
$deletedlineItems	element()	External variable	Order lines that were deleted by the amendment
$deletedpriorlineItems	element()	External variable	Prior order line data that was deleted by the amendment
$addedlineItems	element()	External variable	Order line data that was added by the amendment
$component	element()	External variable	XML fragment containing the fulfillment function data
$histComponent	element()	External variable	XML fragment with the pre-amendment fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$histIdMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the BusinessComponentID populated into the earlier EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE). This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE.
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message: This element only applies if the request EBM is sent to service order management (SOM).
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-22 lists the return parameters for the extension point XQuery.

Table 5-22 CREATE-EBM for redo Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the EBM: The EBM format depends on external fulfillment provider requirements.

Example 5-6 is a sample XQuery code fragment for the CREATE-EBM fulfillment function extension point implementation for the redo execution mode.

Example 5-6 CREATE-EBM XQuery Code Fragment for redo Execution Mode

import module namespace pipextensionmodule = "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule" at "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule/ExtensionPointModule.xquery";
import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";
 
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
 
declare variable $ebmHeader external;
declare variable $salesOrderLine external; (:check null:)
declare variable $priorSalesOrderLine external; (:check null:)
declare variable $histSalesOrderLine external; (:check null:)
declare variable $histPriorSalesOrderLine external; (:check null:)
declare variable $deletedlineItems external; (:check null:) 
declare variable $deletedpriorlineItems external; (:check null:)
declare variable $addedlineItems external; (:check null:)
declare variable $component external;
declare variable $targetIdentifier external;
declare variable $idMap external;
declare variable $histIdMap external;
declare variable $ebmId external;
declare variable $fulfillmentOrderId external;
declare variable $fulfillmentOrderNumber external;
declare variable $faultMode external;
declare variable $hasFallout external;
 
let $fulfillmentOrder := .
return
    <Ebm>
    {
        YourFunctionNamefn:createRedoYourFunctioNamePayload(
            $ebmHeader, 
            $fulfillmentOrder, 
            pipextensionmodule:unWrapParameter($salesOrderLine),
            pipextensionmodule:unWrapParameter($priorSalesOrderLine),
            if ($hasFallout = fn:true()) then () else pipextensionmodule:unWrapParameter($histSalesOrderLine),   
            if ($hasFallout = fn:true()) then () else pipextensionmodule:unWrapParameter($deletedlineItems),
            $targetIdentifier,
            $idMap,
            $histIdMap,   
            $ebmId,
            $fulfillmentOrderId,
            $fulfillmentOrderNumber,
            $faultMode,
            $hasFallout)
    }
    </Ebm>

CREATE-EBM Extension Point for undo Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM extension point for the undo execution mode.

Table 5-23 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-23 CREATE-EBM Input Parameters for undo Execution Mode for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$orderId	xs:string	External variable	OSM Order ID of the current order
$orderKey	xs:string	External variable	AIA Order Number
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
$component	element()	External variable	XML fragment containing the fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE). This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message. this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message: This element only applies if the request EBM is sent to service order management (SOM).
$priorFulfillmentOrder	element()	External variable	Prior Fulfillment order header for the SalesOrder request EBM
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-24 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-24 CREATE-EBM Input Parameters for undo Execution Mode for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$component	element()	External variable	XML fragment containing the fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE): This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE.
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message. this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$verbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message: This element only applies if the request EBM is sent to service order management (SOM).
$priorFulfillmentOrder	element()	External variable	Prior Fulfillment order header for the SalesOrder request EBM
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-25 lists the return parameters for the extension point XQuery.

Table 5-25 CREATE-EBM for undo Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the EBM: The EBM format depends on external fulfillment provider requirements.

Example 5-7 is a sample XQuery code fragment for the CREATE-EBM fulfillment function extension point implementation for the undo execution mode.

Example 5-7 CREATE-EBM XQuery Code Fragment for undo Execution Mode

import module namespace pipextensionmodule = "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule" at "http://xmlns.oracle.com/communications/ordermanagement/pip/pipextensionmodule/ExtensionPointModule.xquery";
import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";
 
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
 
declare variable $ebmHeader external;
declare variable $salesOrderLine external; (:check null:)
declare variable $priorSalesOrderLine external; (:check null:)
declare variable $component external;
declare variable $targetIdentifier external;
declare variable $idMap external;
declare variable $ebmId external;
declare variable $fulfillmentOrderId external;
declare variable $fulfillmentOrderNumber external;
declare variable $fulfillmentOrderStatus external;
declare variable $faultMode external;
declare variable $hasFallout external;
declare variable $verbCode external;
 
let $fulfillmentOrder := .
return
    <Ebm>
    {
        YourFunctionNamefn:createUndoYourFunctionNamePayload(
            $ebmHeader, 
            $fulfillmentOrder, 
            pipextensionmodule:unWrapParameter($salesOrderLine), 
            pipextensionmodule:unWrapParameter($priorSalesOrderLine), 
            $component, 
            $targetIdentifier,
            $idMap,
            $ebmId,
            $fulfillmentOrderId,
            $fulfillmentOrderNumber,
            $faultMode,
            $hasFallout,
            $verbCode)
    }
    </Ebm>

CREATE-EBM-CUSTOM Extension Point

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-CUSTOM extension point.

Table 5-26 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-26 CREATE-EBM-CUSTOM Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$component	element()	External variable	XML fragment containing the fulfillment function data
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
.	element()	Context node	OSM component element

Table 5-27 lists the return parameters for the extension point XQuery.

Table 5-27 CREATE-EBM-CUSTOM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the order-level custom EBM fragment

Example 5-8 is a sample XQuery code fragment for the CREATE-EBM-CUSTOM fulfillment function extension point.

Example 5-8 CREATE-EBM-CUSTOM XQuery Code Fragment

declare namespace log = "java:org.apache.commons.logging.Log";
declare variable $log external;
declare variable $ebmHeader external;
declare variable $component external;
declare variable $ebmId external;
declare variable $customerHeaders external;

let $fulfillmentOrder := .
return
(
    <Ebm>
    {
        yourFuntionNamefn:createProvisioningOrderCustom(
            $log,
            $ebmHeader,
            $fulfillmentOrder,
            $component, 
            $ebmId,
            $customerHeaders)
    }
    </Ebm>
)

CREATE-EBM-ALL-ORDERITEMS Extension Point

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-ALL-ORDERITEMS extension point.

Table 5-28 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-28 CREATE-EBM-ALL-ORDERITEMS Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header.
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function (has the same value as $priorLineItems)
$priorLineItems	element()	External variable	All prior order lines belonging to the current fulfillment function (has the same value as $priorSalesOrderLine)
$component	element()	External variable	XML fragment containing the fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: This parameter in effect only if the request EBM is sent to an external system emulator rather than a real system.
$lfVerbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message. This element only applies if the request EBM is sent to service order management (SOM).
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
$orderMode	xs:string	Internal variable	This parameter has the following possible values: In do mode, this parameter has the value of DELIVER. In redo mode, this parameter has the value CHANGE if the service order management order has completed, so the service order management order is being revised by sending a change order. It has the value of REVISE if the service order management order has not completed, so the service order management order is being revised by sending an amendment order. In undo mode, this parameter has the value CANCEL if the action codes are going to be set to None for the order items. It has the value of DELIVER if the action codes are going to be set to Disconnect for the order items.
$changeMode	xs:string	Internal variable	This parameter is used to set action codes appropriately. It only has a value if the value of $orderMode is CHANGE. Available values for this parameter are DO, REDO, and UNDO.
.	element()	Context node	Fulfillment order header for the SalesOrder request EBM

Table 5-29 lists the return parameters for the extension point XQuery.

Table 5-29 CREATE-EBM-ALL-ORDERITEMS Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the XML fragment for the all order items EBM. The EBM format depends on external fulfillment provider requirements.

Example 5-9 is a sample XQuery code fragment for the CREATE-EBM-ALL-ORDERITEMS fulfillment function extension point.

Example 5-9 CREATE-EBM-ALL-ORDERITEMS XQuery Code Fragment

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $ebmHeader external;
declare variable $salesOrderHeader external;
declare variable $salesOrderLine external;
declare variable $component external;
declare variable $idMap external;
declare variable $fulfillmentOrderId external;
declare variable $fulfillmentOrder external;
declare variable $fulfillmentOrderNumber external;
declare variable $orderId external;
declare variable $orderKey external;
declare variable $log external;
declare variable $customerHeaders external;
declare variable $aiaEbmHelper external;
declare variable $transformedOrderLines external;
declare variable $histTransformedOrderLines external;
declare variable $mappingContext external;
declare variable $orderMode external;
declare variable $changeMode external;
declare variable $execMode external;
declare variable $lineItems external;
declare variable $priorLineItems external;
 
let $input := .
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
 
return
(       
    <OrderItemEbm>
    {
        if ($isCSOEnabled = fn:true()) then
        (
            yourFuntionNamefn:createTransformedLines(
                $log, 
                $aiaEbmHelper,
                $orderId,
                $orderKey,
                $ebmHeader,
                $salesOrderHeader,
                pipextensionmodule:unWrapParameter($salesOrderLine),
                pipextensionmodule:unWrapParameter($transformedOrderLines),
                pipextensionmodule:unWrapParameter($histTransformedOrderLines),
                pipextensionmodule:unWrapParameter($mappingContext),
                $component, 
                $idMap,
                $fulfillmentOrder,
                $fulfillmentOrderId,
                $fulfillmentOrderNumber,
                $customerHeaders,
                $execMode,
                $orderMode,
                $changeMode)
        )
        else
        (
            yourFuntionNamefn:createNormalLines(
                $log, 
                $aiaEbmHelper,
                $orderId,
                $orderKey,
                $ebmHeader,
                $salesOrderHeader,
                pipextensionmodule:unWrapParameter($lineItems),
                pipextensionmodule:unWrapParameter($priorLineItems),
                $component, 
                $idMap,
                $fulfillmentOrder,
                $fulfillmentOrderId,
                $fulfillmentOrderNumber,
                $customerHeaders,
                $execMode,
                $orderMode,
                $changeMode)
        )
    }
    </OrderItemEbm>
)

CREATE-EBM-ORDERITEM Extension Point for do Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-ORDERITEM extension point for do execution mode.

Table 5-30 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-30 CREATE-EBM-ORDERITEM Input Parameters for do Execution Mode

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header.
$serviceActionCode	element()	External variable	Service action for order item or transformed order item
$orderItem	element()	External variable	XML fragment for a single order item in the current Fulfillment function
$lineItem	element()	External variable	Single sales order line in the current fulfillment function
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$component	element()	External variable	XML fragment containing the fulfillment function data
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE). This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE.
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
$orderMode	xs:string	Internal variable	In do mode, this parameter has the value of DELIVER.
$changeMode	xs:string	Internal variable	This parameter has no value in do mode.
.	element()	Context node	Fulfillment order item

Table 5-31 lists the return parameters for the extension point XQuery.

Table 5-31 CREATE-EBM-ORDERITEM for do Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the XML fragment for single order item.

Example 5-10 is a sample XQuery code fragment for the CREATE-EBM-ORDERITEM fulfillment function extension point implementation for the do execution mode.

Example 5-10 CREATE-EBM-ORDERITEM XQuery Code Fragment for do Execution Mode

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace myContext = "java:oracle.communications.ordermanagement.extensionpoint.XQueryExtensionUtil";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $idMap external;
declare variable $fulfillmentOrderId external;
declare variable $orderId external;
declare variable $log external;
declare variable $transformedOrderLines external;
declare variable $transformedOrderLine external;
declare variable $serviceActionCode external;
declare variable $lineItems external;
declare variable $lineItem external;
 
let $input := .
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
 
return
(       
    let $tag := myContext:getString("tag")
    return
    (
        <OrderItemEbm>
        {
            if ($isCSOEnabled = fn:true()) then
            (
                YourFunctionNamefn:createProvisionOrderLineItemFromTransformLine(
                    $log,
                    $orderId,
                    $tag,
                    $fulfillmentOrderId,
                    $lineItem,
                    $transformedOrderLines,
                    $transformedOrderLine, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode)
            )
            else
            (
                YourFunctionNamefn:createProvisionOrderLineItem(
                    $lineItems, 
                    $lineItem, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode, 
                    $lineItem)
            )
        }
        </OrderItemEbm>
    )
)

CREATE-EBM-ORDERITEM Extension Point for redo Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-ORDERITEM extension point for the redo execution mode.

Table 5-32 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-32 CREATE-EBM-ORDERITEM Input Parameters for redo Execution Mode

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header.
$orderItem	element()	External variable	XML fragment for a single order item in the current Fulfillment function
$lineItem	element()	External variable	Single sales order line in the current fulfillment function
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$histTransformedOrderLines	element()	External variable	XML fragment of all transformed order items belonging to the current fulfillment function before the revision (applies to Calculate Service Order only)
$histMappingContext	element()	External variable	XML fragment describing the pre-revision mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$histSalesOrderLine	element()	External variable	All order lines belonging to the current fulfillment function before amendment (has the same value as $histLineItem)
$histLineItem	element()	External variable	All order lines belonging to the current fulfillment function before amendment (has the same value as $histSalesOrderLine)
$histPriorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function before amendment
$deletedlineItem	element()	External variable	Deleted order item that is currently being processed.
$deletedlineItems	element()	External variable	List of the order items that were deleted by the amendment
$deletedTransformedLineItems	element()	External variable	XML fragment of all deleted transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$deletedMappingContext	element()	External variable	XML fragment describing the deleted mapping context for all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$deletedpriorlineItems	element()	External variable	Prior order line data that was deleted by the amendment
$addedlineItems	element()	External variable	Order line data that was added by the amendment
$component	element()	External variable	XML fragment containing the fulfillment function data
$histComponent	element()	External variable	XML fragment with the pre-amendment fulfillment function data
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$histIdMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the BusinessComponentID populated into the earlier EBM request message
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE). This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE.
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$faultMode	xs:string	External variable	FaultMode code to control how the emulator generates the response message: this parameter is in effect only if the request EBM is sent to an external system emulator rather than a real system.
$lfVerbCode	xs:string	External variable	FaultMode code to control how the service order management orchestration order generates the response message. This element only applies if the request EBM is sent to service order management (SOM).
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
.	element()	Context node	Fulfillment order item

Table 5-33 lists the return parameters for the extension point XQuery.

Table 5-33 CREATE-EBM-ORDERITEM for redo Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the XML fragment for single order item.

Example 5-11 is a sample XQuery code fragment for the CREATE-EBM-ORDERITEM fulfillment function extension point implementation for the redo execution mode.

Example 5-11 CREATE-EBM-ORDERITEM XQuery Code Fragment for redo Execution Mode

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace myContext = "java:oracle.communications.ordermanagement.extensionpoint.XQueryExtensionUtil";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $idMap external;
declare variable $fulfillmentOrderId external;
declare variable $orderId external;
declare variable $log external;
declare variable $transformedOrderLines external;
declare variable $transformedOrderLine external;
declare variable $serviceActionCode external;
declare variable $lineItems external;
declare variable $lineItem external;
 
let $input := .
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
 
return
(       
    let $tag := myContext:getString("tag")
    return
    (
        <OrderItemEbm>
        {
            if ($isCSOEnabled = fn:true()) then
            (
                YourFunctionNamefn:createProvisionOrderLineItemFromTransformLine(
                    $log,
                    $orderId,
                    $tag,
                    $fulfillmentOrderId,
                    $lineItem,
                    $transformedOrderLines,
                    $transformedOrderLine, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode)
            )
            else
            (
                YourFunctionNamefn:createProvisionOrderLineItem(
                    $lineItems, 
                    $lineItem, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode, 
                    $lineItem)
            )
        }
        </OrderItemEbm>
    )
)

CREATE-EBM-ORDERITEM Extension Point for undo Execution Mode

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-ORDERITEM extension point for the undo execution mode.

Table 5-34 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-34 CREATE-EBM-ORDERITEM Input Parameters for undo Execution Mode

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$salesOrderHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header.
$priorSalesOrderHeader	element()	External variable	Prior SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header.
$component	element()	External variable	XML fragment containing the fulfillment function data
$orderItem	element()	External variable	XML fragment for a single order item in the current Fulfillment function
$lineItem	element()	External variable	Single sales order line in the current fulfillment function
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$targetIdentifier	element()	External variable	XML fragment describing the target system information
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$fulfillmentOrderStatus	xs:string	External variable	The child order's current status (IN_PROGRESS or COMPLETE). This element controls how the EBM should be generated. The EBM is expected to be generated as a cancel order if the child order is IN_PROGRESS or as a disconnect order if the child order is COMPLETE.
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
$histComponent	element()	External variable	XML fragment with the pre-amendment fulfillment function data
$histTransformedOrderLines	element()	External variable	XML fragment of all transformed order items belonging to the current fulfillment function before the revision (applies to Calculate Service Order only)
$histMappingContext	element()	External variable	XML fragment describing the pre-revision mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$histSalesOrderLine	element()	External variable	All order lines belonging to the current fulfillment function before amendment
$histPriorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function before amendment
$histIdMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the BusinessComponentID populated into the earlier EBM request message
$deletedlineItems	element()	External variable	Order lines that were deleted by the amendment
$deletedTransformedLineItems	element()	External variable	XML fragment of all deleted transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$deletedMappingContext	element()	External variable	XML fragment describing the deleted mapping context for all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$deletedpriorlineItems	element()	External variable	Prior order line data that was deleted by the amendment
$addedlineItems	element()	External variable	Order line data that was added by the amendment
.	element()	Context node	Fulfillment order item

Table 5-35 lists the return parameters for the extension point XQuery.

Table 5-35 CREATE-EBM-ORDERITEM for undo Execution Mode Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the XML fragment for single order item.

Example 5-12 is a sample XQuery code fragment for the CREATE-EBM-ORDERITEM fulfillment function extension point implementation for the undo execution mode.

Example 5-12 CREATE-EBM-ORDERITEM XQuery Code Fragment for undo Execution Mode

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace myContext = "java:oracle.communications.ordermanagement.extensionpoint.XQueryExtensionUtil";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $idMap external;
declare variable $fulfillmentOrderId external;
declare variable $orderId external;
declare variable $log external;
declare variable $transformedOrderLines external;
declare variable $transformedOrderLine external;
declare variable $serviceActionCode external;
declare variable $lineItems external;
declare variable $lineItem external;
 
let $input := .
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
 
return
(       
    let $tag := myContext:getString("tag")
    return
    (
        <OrderItemEbm>
        {
            if ($isCSOEnabled = fn:true()) then
            (
                YourFunctionNamefn:createProvisionOrderLineItemFromTransformLine(
                    $log,
                    $orderId,
                    $tag,
                    $fulfillmentOrderId,
                    $lineItem,
                    $transformedOrderLines,
                    $transformedOrderLine, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode)
            )
            else
            (
                YourFunctionNamefn:createProvisionOrderLineItem(
                    $lineItems, 
                    $lineItem, 
                    aiaebmfn:hasParentLine($lineItems, $lineItem), 
                    aiaebmfn:getRootLineItem($lineItems, $lineItem), 
                    $idMap, 
                    $serviceActionCode, 
                    $lineItem)
            )
        }
        </OrderItemEbm>
    )
)

CREATE-EBM-ORDERITEM-CUSTOM Extension Point

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-ORDERITEM-CUSTOM extension point.

Table 5-36 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-36 CREATE-EBM-ORDERITEM-CUSTOM Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$component	element()	External variable	XML fragment containing the fulfillment function data
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
.	element()	Context node	OSM Component element

Table 5-37 lists the return parameters for the extension point XQuery.

Table 5-37 CREATE-EBM-ORDERITEM-CUSTOM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the order-item-level custom EBM fragment

Example 5-13 is a sample XQuery code fragment for the CREATE-EBM-ORDERITEM-CUSTOM fulfillment function extension point.

Example 5-13 CREATE-EBM-ORDERITEM-CUSTOM XQuery Code Fragment

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace myContext = "java:oracle.communications.ordermanagement.extensionpoint.XQueryExtensionUtil";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $sourceLineItem external;
declare variable $transformedOrderLine external;
 
let $input := .
 
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
let $result := 
       if ($isCSOEnabled = fn:true()) then
       (
            YourFunctionNamefn:createTransformedLineCustom($sourceLineItem,$transformedOrderLine)
       )
       else
       (
            YourFunctionNamefn:createLineCustom($sourceLineItem)
       )
return
(       
    <result>
    {
        $result
    }
    </result>

CREATE-EBM-PRIORORDERITEM Extension Point

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-PRIORORDERITEM extension point.

Table 5-38 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-38 CREATE-EBM-PRIORORDERITEM Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$component	element()	External variable	XML fragment containing the fulfillment function data
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$transformedOrderLine	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function (applies to Calculate Service Order only)
$priorSalesOrderLine	element()	External variable	All prior order lines belonging to the current fulfillment function
$idMap	element()	External variable	XML fragment describing the mapping between the original order line's BusinessComponentID and the newly generated BusinessComponentID to be populated into the EBM request message
$fulfillmentOrderId	xs:string	External variable	BusinessComponentID to be populated into the EBM request message as the Order ID
$fulfillmentOrderNumber	xs:string	External variable	Cross-system order number reference
$customerHeaders	element()	External variable	XML fragment describing the mapping of the CustomerHeader structure
.	element()	Context node	EBM Header

Table 5-39 lists the return parameters for the extension point XQuery.

Table 5-39 CREATE-EBM-PRIORORDERITEM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the XML fragment for the prior single order item custom EBM

Example 5-14 is a sample XQuery code fragment for the CREATE-EBM-PRIORORDERITEM fulfillment function extension point.

Example 5-14 CREATE-EBM-PRIORORDERITEM XQuery Code Fragment

declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $priorSalesOrderLine external;
 
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
 
let $input := .
 
return
(
    <OrderItemEbm>
    {
        if ($isCSOEnabled = fn:true()) then
        (
            YourFunctionNamefn:createSingleTransformedLine(
                $priorSalesOrderLine
            )
        else
        (
            YourFunctionNamefn:createProvisionOrderLineItem(
                $priorSalesOrderLine
        )
    }
 
    </OrderItemEbm>
)

CREATE-EBM-PRIORORDERITEM-CUSTOM Extension Point

This section describes the XQuery script that implements the logic to handle the CREATE-EBM-PRIORORDERITEM-CUSTOM extension point.

Table 5-40 lists the input parameters for the extension point XQuery. If any parameters do not apply to the solution option without Calculate Service Order, that will be indicated in the parameter description.

Table 5-40 CREATE-EBM-PRIORORDERITEM-CUSTOM Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$aiaEbmHelper	Java Object	External variable	java:oracle.communications.ordermanagement.util.ebm.AiaEbmHelper For more information about this object, see knowledge article 2086727.1, Javadocs for Order to Activate (O2A) Cartridge, on the Oracle Support Web site: https://support.oracle.com
$taskContext	Java Object	External variable	Java Type java:com.mslv.oms.automation.TaskContext OSM-provided interface into the task. See the OSM SDK for more information.
$orderId	xs:string	External variable	OSM order ID of the current order
$orderKey	xs:string	External variable	AIA order number
$componentName	xs:string	External variable	Name of the component from which the extension point was called.
$systemType	xs:string	External variable	Name of the target system for the component, for example, BRM-BIZBDB
$execMode	xs:string	External variable	Task execution mode
$ebmHeader	element()	External variable	SalesOrder request EBM header: This element can be used as a reference to populate the request EBM header
$component	element()	External variable	XML fragment containing the fulfillment function data
$salesOrderLine	element()	External variable	XML fragment of all order lines belonging to the current fulfillment function
$transformedOrderLines	element()	External variable	XML fragment of all transformed order lines belonging to the current fulfillment function (applies to Calculate Service Order only)
.	element()	Context node	OSM Component element

Table 5-41 lists the return parameters for the extension point XQuery.

Table 5-41 CREATE-EBM-PRIORORDERITEM-CUSTOM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the prior-order-item-level custom EBM fragment

Example 5-15 is a sample XQuery code fragment for the CREATE-EBM-PRIORORDERITEM-CUSTOM fulfillment function extension point.

Example 5-15 CREATE-EBM-PRIORORDERITEM-CUSTOM XQuery Code Fragment

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace orderActivity = "java:oracle.communications.ordermanagement.log.LogOrderActivity";
declare namespace taskExecutionMode = "java:oracle.communications.ordermanagement.automation.OsmPipTaskConstant";
declare namespace myContext = "java:oracle.communications.ordermanagement.extensionpoint.XQueryExtensionUtil";
declare namespace solutionconfig = "java:oracle.communications.ordermanagement.config.OsmPipConfigProvider";
 
declare variable $sourceLineItem external;
declare variable $transformedOrderLine external;
 
let $input := .
 
let $isCSOEnabled := if (solutionconfig:getVariable("O2A_CSO_ENABLE_FLAG") = "enable") then fn:true() else fn:false()
let $result := 
    if ($isCSOEnabled = fn:true()) then
    (
        YourFunctionNamefn:createTransformedLineCustom($sourceLineItem,$transformedOrderLine)
    )
    else
    (
        YourFunctionNamefn:createLineCustom($sourceLineItem)
    )
return
(       
    <result>
    {
        $result
    }
    </result>
)

VALIDATE-RESPONSE-EBM Extension Point

This section describes the XQuery script that implements the logic to handle the VALIDATE-RESPONSE-EBM extension point.

Table 5-42 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-42 VALIDATE-RESPONSE-EBM Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$executionMode	xs:string	External variable	Task execution mode
.	element()	Context node	Response EBM message to be validated

Table 5-43 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-43 VALIDATE-RESPONSE-EBM Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
.	element()	Context node	Response EBM message to be validated

Table 5-44 lists the return parameters for the extension point XQuery.

Table 5-44 VALIDATE-RESPONSE-EBM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element which contains an empty sequence if no error was found or a list of XML fragments that describe the validation error if an error was found

Example 5-16 is a code fragment from OracleComms_OSM_O2A_COM_Billing/resources/ExtensionPoint/SyncCustomerValidateResponseEBM_Event.xquery demonstrates the extension implementation.

Example 5-16 VALIDATE-RESPONSE-EBM XQuery Code Fragment

import module namespace aiaebmvalidationfn = "http://xmlns.oracle.com/communications/ordermanagement/pip/aiaebmvalidationfn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/aiaebmvalidationfn/AIAEBMResponse_ValidationModule.xquery";
 
declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
declare variable $SYNCCUST_RESPONSE_EBM := "ProcessFulfillmentOrderBillingAccountListResponseEBM";
 
declare function local:validateSyncCustomerResponse(
    $ebm as element() *) as element()
{
    if(fn:local-name($ebm) = $SYNCCUST_RESPONSE_EBM)
    then
        <oms:validationReport>
        {
            aiaebmvalidationfn:validateSyncCustomerResponse($ebm)
        }
        </oms:validationReport>
    else
        <oms:validationReport>{ $aiaebmvalidationfn:NO_VALID_EBM }</oms:validationReport>
};
 
let $ebm := .
return
    <Validation>
    {
        local:validateSyncCustomerResponse($ebm)
    }
    </Validation>

COMPONENT-RESPONSE-UPDATE Extension Point

This section describes the XQuery script that implements the logic to handle the COMPONENT-RESPONSE-UPDATE extension point.

Table 5-45 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-45 COMPONENT-RESPONSE-UPDATE Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$orderId	xs:string	External variable	OSM Order ID of the current order
$orderKey	xs:string	External variable	AIA Order Number
$component	element()	External variable	XML fragment containing the fulfillment function data
$executionMode	xs:string	External variable	Task execution mode
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$orderItemFromResponse	element()	External variable	Order item data from the response message
$mappingContext	element()	External variable	XML fragment describing the mapping context between all sales order items and transformed order items belonging to the current fulfillment function
.	element()	Context node	The order item data XML fragment

Table 5-46 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-46 COMPONENT-RESPONSE-UPDATE Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
$extensionVersion	xs:string	External variable	Version number of the extension framework
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$executionMode	xs:string	External variable	Task execution mode
$hasFallout	xs:boolean	External variable	Boolean indicator of whether the previous EBM request sent to the external system has had fallout
$orderId	xs:string	External variable	OSM Order ID of the current order
$orderKey	xs:string	External variable	AIA Order Number
$falloutMessage	xs:string	External variable	The fallout error message of this order item
$orderItemFromResponse	element()	External variable	Order item data from the response message
.	element()	Context node	The order item data XML fragment

Table 5-47 lists the return parameters for the extension point XQuery.

Table 5-47 COMPONENT-RESPONSE-UPDATE Return Parameters

Output Parameter Type	Description
element()*	XML wrapper element that contains all the order item properties to be updated

Example 5-17 is a sample XQuery code fragment for the COMPONENT-RESPONSE-UPDATE fulfillment function extension point.

Example 5-17 COMPONENT-RESPONSE-UPDATE XQuery Code Fragment

import module namespace YourFunctionNamefn = "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn" at "http://xmlns.oracle.com/communications/ordermanagement/pip/YourFunctionNamefn/YourFunctionNameInteractionModule.xquery";

declare namespace oms = "urn:com:metasolv:oms:xmlapi:1";
 
declare variable $hasFallout external;
declare variable $falloutMessage external;
declare variable $orderItemFromResponse external;
 
declare function YourFunctionNamefn:onYourFunctionNameResponseUpdate(
    $lineItem as element(),
    $orderItemFromResponse as element()) as element()*
{
    let $id := $lineItem/oms:BaseLineId
    return 
        <BaseLineId>{ $id/text() }</BaseLineId>,
        (: list of order item properties to be updated :)
};
 
let $lineItem := .
return
    <OrderItem>
    {
        YourFunctionNamefn:onYourFunctionNameResponseUpdate($lineItem, $orderItemFromResponse)
    }
    </OrderItem>

ORDER-EXTENSION-UPDATE-STATUS-EBM Extension Point

This section describes the XQuery script that implements the logic to handle the ORDER-EXTENSION-UPDATE-STATUS-EBM extension point.

Table 5-48 lists the input parameters for the extension point XQuery when you are using the calculate service order solution option.

Table 5-48 ORDER-EXTENSION-UPDATE-STATUS-EBM Input Parameters for the Calculate Service Order Option

Name	Type	Scope	Description
$controlData	element()	External variable	XML data fragment of the control data from the current task that calls to this extension point
$taskData	element()	External variable	XML data fragment of the current task that calls to this extension point
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$ebm	element()	External variable	XML data fragment of the EBM header from the CRM system
$fulfillmentOrder	element()	External variable	XML data fragment of the Fulfillment Order from the CRM system
$extensionVersion	xs:string	External variable	Version number of the extension framework
$orderId	xs:string	External variable	OSM Order ID of the current order
$sequenceNumber	xs:string	External variable	EBM message unique sequence tracking number to be populated in the update EBM
$changeLinesStatus	element()*	External variable	XML data fragment which contains multiple order items that must be included in the update EBM
$hasFalloutFlag	xs:boolean	External variable	Boolean indicator of whether the order is in Fallout state
$isCancelFlag	xs:boolean	External variable	Boolean indicator for the order is being cancelled
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$execMode	xs:string	External variable	Task execution mode
$debugControl	element()	External variable	XML data fragment of the order execution control for break point and debug
$orderStatusContext	xs:string	External variable	Order status description to be populated in the update EBM
$includeActualDelDateTime	xs:boolean	External variable	Boolean indicator for whether to populate the actual delivery date/time field of the update EBM
$includeFulfillmentData	xs:boolean	External variable	Boolean indicator for whether to include detailed order item data in the update EBM

Table 5-49 lists the input parameters for the extension point XQuery when you are using the solution option without calculate service order.

Table 5-49 ORDER-EXTENSION-UPDATE-STATUS-EBM Input Parameters for the Option Without Calculate Service Order

Name	Type	Scope	Description
$controlData	element()	External variable	XML data fragment of the control data from the current task that calls to this extension point
$taskData	element()	External variable	XML data fragment of the current task that calls to this extension point
$ebmId	xs:string	External variable	EBM ID to be populated into the EBM request message
$ebm	element()	External variable	XML data fragment of the EBM header from the CRM system
$fulfillmentOrder	element()	External variable	XML data fragment of the Fulfillment Order from the CRM system
$extensionVersion	xs:string	External variable	Version number of the extension framework
$orderId	xs:string	External variable	OSM Order ID of the current order.
$sequenceNumber	xs:string	External variable	EBM message unique sequence tracking number to be populated in the update EBM
$changeLinesStatus	element()*	External variable	XML data fragment which contains multiple order items that must be included in the update EBM
$hasFalloutFlag	xs:boolean	External variable	Boolean indicator of whether the order is in a fallout state
$isCancelFlag	xs:boolean	External variable	Boolean indicator of whether the order is being cancelled
$log	Java Object	External variable	Java Type org.apache.commons.logging.Log Logging level related to server log
$execMode	xs:string	External variable	Task execution mode
$debugControl	element()	External variable	XML data fragment of the order execution control for break point and debug
$orderStatusContext	xs:string	External variable	Order status description to be populated in the update EBM
$includeActualDelDateTime	xs:boolean	External variable	Boolean indicator for whether to populate the actual delivery date/time field of the update EBM
$includeFulfillmentData	xs:boolean	External variable	Boolean indicator for whether to include detailed order item data in the update EBM

Table 5-50 lists the return parameters for the extension point XQuery.

Table 5-50 ORDER-EXTENSION-UPDATE-STATUS-EBM Return Parameters

Output Parameter Type	Description
element()?	XML wrapper element that contains the Update Sales Order EBM. The EBM format depends on external fulfillment provider requirements.

Example 5-18 is a sample XQuery code fragment for the ORDER-EXTENSION-UPDATE-STATUS-EBM fulfillment function extension point when you are using the calculate service order solution option.

Example 5-18 ORDER-EXTENSION-UPDATE-STATUS-EBM XQuery Code Fragment for the Calculate Service Order Option

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
declare namespace salesord="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V2";
declare namespace corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2";
 
declare variable $controlData external;
declare variable $taskData external;
declare variable $ebmId external;
declare variable $ebm external;
declare variable $fulfillmentOrder external;
declare variable $extensionVersion external;
declare variable $orderId external;
declare variable $sequenceNumber external;
declare variable $changeLinesStatus external;
declare variable $hasFalloutFlag external;
declare variable $isCancelFlag external;
declare variable $log external;
declare variable $execMode external;
declare variable $debugControl external;
declare variable $orderStatusContext external;
declare variable $includeActualDelDateTime external;
declare variable $includeFulfillmentData external;
 
if ($extensionVersion=$pipextensionmodule:EXTENSION_VERSION_2) then
(
    yourOrderFunctionfn:createUpdateSalesOrderPayloadWithUserProvideOrderStatusContext(
        $log,
        $orderId,
        $ebm,
        $fulfillmentOrder, 
        $ebmId,
        $sequenceNumber,
        $controlData,
        $changeLinesStatus,
        $hasFalloutFlag,
        $isCancelFlag,
        $orderStatusContext,
        $includeActualDelDateTime,
        $includeFulfillmentData)
)
else 
(
    log:warn($log, fn:concat("UpdateEBM Extension Point V2 is receiving the wrong version! extensionVersion:[",$extensionVersion,"]"))
)

Example 5-19 is a sample XQuery code fragment for the ORDER-EXTENSION-UPDATE-STATUS-EBM fulfillment function extension point when you are using the solution option without calculate service order.

Example 5-19 ORDER-EXTENSION-UPDATE-STATUS-EBM XQuery Code Fragment for the Calculate Service Order Option

declare namespace log = "java:org.apache.commons.logging.Log";
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
declare namespace salesord="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V1";
declare namespace corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1";
 
declare variable $controlData external;
declare variable $taskData external;
declare variable $ebmId external;
declare variable $ebm external;
declare variable $fulfillmentOrder external;
declare variable $extensionVersion external;
declare variable $orderId external;
declare variable $sequenceNumber external;
declare variable $changeLinesStatus external;
declare variable $hasFalloutFlag external;
declare variable $isCancelFlag external;
declare variable $log external;
declare variable $execMode external;
declare variable $debugControl external;
declare variable $orderStatusContext external;
declare variable $includeActualDelDateTime external;
declare variable $includeFulfillmentData external;
 
if ($extensionVersion=$pipextensionmodule:EXTENSION_VERSION_1) then
(
    yourOrderFunctionfn:createUpdateSalesOrderPayloadWithUserProvideOrderStatusContext(
        $log,
        $orderId,
        $ebm,
        $fulfillmentOrder, 
        $ebmId,
        $sequenceNumber,
        $controlData,
        $changeLinesStatus,
        $hasFalloutFlag,
        $isCancelFlag,
        $orderStatusContext,
        $includeActualDelDateTime,
        $includeFulfillmentData)
)
else 
(
    log:warn($log, fn:concat("UpdateEBM Extension Point V1 is receiving the wrong version! extensionVersion:[",$extensionVersion,"]"))
)

About Fallout

When creating a new fulfillment function, you must consider the fallout handling needed. Information about the fallout considerations is contained in the following sections.

Fallout Customization

The AIAResponseEBM.xqy XQuery file is called from automated tasks, for example, SyncCustomerSITask and ProvisionOrderSITask. When adding a fulfillment function, you must customize a copy of this file, located in OracleComms_OSM_O2A_COM_SalesOrderFulfillment\resources\ComponentInteraction, and call it from the automation in the SITask that processes the response coming from the Application Business Connector Service (ABCS) for the fulfillment system. The response can be either a response EBM or an OrderFalloutNotification.

You may need to customize the local:getEbmFromResponse function to extract the response EBM, depending on the fulfillment function.

The function local:getCFSystem extracts the system name from the value of the componentKey for the executable order component. Due to the four orchestration stages defined in the orchestration sequence in the OracleComms_OSM_O2A_COM_Base cartridge, the componentKey takes the format:

FunctionName.SystemName.Granularity.FunctionSignificantUpdates

An example of a component key for an executable FulfillBillingFunction Order Component targeted at the BRM-VoIP billing system using ServiceBundleGranularity processing granularity, with a base line ID of the service bundle line of 31383732333932333934333332373635 is:

FulfillBillingFunction.BRM-VOIP.ServiceBundleGranularity.31383732333932333934333332373635/ServiceBundleGranularity.FulfillBillingSignificantUpdates

Example 5-20 is a sample XQuery code fragment from OracleComms_OSM_O2A_COM_Base/resources/FalloutHandling/TargetMapping.xquery.

Example 5-20 Target System Map XQuery Code Fragment

(:
 : Function to return the Target system name that the given ActiveInteractionId is associate to. 
 :)
declare function osmmappip:getCFSystem(
    $orderData as element()?, 
    $activeInteractionId as xs:string) as xs:string?
{
    (: First use the $activeInteractionId to locate the FulfillmentComponent under _root/FulfillmentOrderManagement :)
    let $ffmOrdMgr := $orderData/osm:Data/oms:_root/oms:FulfillmentOrderManagement
    let $fulfillmentComponent := $ffmOrdMgr/oms:FulfillmentComponent[oms:FulfillmentOrder/oms:ActiveInteractionId/text()=$activeInteractionId]
    return 
        if (fn:exists($fulfillmentComponent))
        then
        (        
            (: FulfillmentComponent found, get the componentKey :)
            let $componentKey := $fulfillmentComponent/oms:componentKey/text()
            return
                substring-before(substring-after($componentKey, "."), ".")
        )
        else ()
};

Failure During Revision

During the OSM fulfillment process, an order may fail due to various reasons like insufficient data, incorrect data and so on. To correct the failure, you may have to revise the failed order. In OSM, failure may occur even while revising the failed orders. With the existing functionality of Oracle Communications Order to Cash Integration Pack for Oracle Communications Order and Service Management, the following events happen when fallout occurs during revision:

• Initially, an update customer order status message, with Order Header status code (FAILED) and description "Order will be aborted due to failure during revision, manual intervention is required", is sent to Siebel CRM. This message contains the corresponding OrderLine status code/descriptions.

• The base Central Order Management/Service Order Management orders are put into Aborted state in OSM, followed by another update customer order status message to Siebel CRM, with Order Header status code (FAILED and description "Order is aborted". This message does not include any OrderLine status information.

• After the failure is resolved manually, Siebel CRM can resend the same customer order to OSM with the correct data.

When there are service order management and Provisioning systems involved in the customer order processing, the following events happen:

• The aborting request is propagated to all service order management systems and then all provisioning systems abort all associated service orders.

• The statuses of all associated service order management and provisioning AbortOrder requests are propagated back to central order management.

• While the order is in AbortInProgress state, incoming revisions are blocked.

• The statuses of the downstream order aborting operations are stored in the central order management or service order management order for reference.

It is mandatory that a fault thrown from a provisioning system must contain the service order state using an AlternateObjectKey element of the sales-order Identification element, where the ID element should have the attribute schemeID="SERVICE_ORDER_STATE". Otherwise, the fault is not treated as a fault during revision.

Since the AIA_CreateProvisioningOrderQueue, AIA_CreateProvisioningOrderResponseQueue, ProcessProvisioningOrderEBM and UpdateFulfillmentOrderEBM are reused for Abort Order Propagation,

• A new value ABORT in the ProcessProvisioningOrderEBM for the FulfillmentModeCode is introduced.

• For the AIA_CreateProvisioningOrderResponseQueue, a JMS message property, CGBUPIPCFFALLOUT, is introduced as: "CGBUPIPCFFALLOUT IS NULL" "CGBUPIPCFFALLOUT LIKE 'ABORT%'" for AbortProvisioningOrderResponse. So it is mandatory that this JMS message property is not stripped off or changed.

Adding a New Fulfillment Function for a New Service Offering

This procedure describes how to add a new fulfillment function for a new service offering. For more information about performing the actions in this procedure in Oracle Communications Design Studio, see the information about adding a new fulfillment function in the section on extending component cartridges in the Design Studio Modeling OSM Orchestration Help.

To add a new fulfillment function:

1. Create a new OSM project to host the new fulfillment function.

2. In the Order and Service Management Project editor Properties tab, deselect the Standalone check box.

   This allows the cartridge to be referenced in the composite cartridge as part of the solution (rather than as a standalone cartridge).

3. Delete the Order entity.

4. Create a base task for the new function from which all other new tasks will be extended.

5. Create any other tasks required by the new function by extending them from the base task created in the previous step.

6. Create a process that will execute when fulfilling the new function. You can create an entirely new process or have the new process extend an existing process.

7. Create the new fulfillment function that either extends from COM_FulfillmentFunction or its extended fulfillment function, and specify keys for the order data at the following XPath location:

   • ./componentKey for order data/ControlData/Functions/YourFunctionName

   • ./orderItemRef/LineId for order data/ControlData/Functions/YourFunctionName/orderItem

   For more information about adding a new fulfillment function, see the information about adding new functional order components in the Design Studio Modeling OSM Orchestration Help.

8. If new fulfillment states are to be introduced for the new fulfillment function, add external fulfillment states for the new fulfillment function in the form of State-YourFunctionName_Milestone. For example, IN_PROGRESS-YourFunctionName_START.

9. Optionally create a new fulfillment system for the fulfillment function.

   When you introduce a new fulfillment function, you may often also require a new fulfillment provider.

10. Create a new decomposition rule (with the COM_SalesOrderLine order item) that maps from the fulfillment function to the fulfillment provider.

    For example, DecompSyncCustomer_To_BRM-VoIP in the OracleComms_OSM_O2A_TypicalTopology_Sample cartridge is a decomposition rule that maps SyncCustomer fulfillment function to the BRM-VoIP fulfillment provider.

11. Add the following cartridge to the Dependency tab for the new cartridge you created for the new fulfillment function:

    • OracleComms_OSM_O2A_COM_Base

    If there are any other cartridges that the new cartridge depends on, add them to the Dependency tab.

12. Add the cartridge you created for the new fulfillment function, to the Dependency tab for the Order-To-Activate composite cartridge.

13. Create composite cartridge views in the cartridge you created for the new fulfillment function.

    • Create a composite cartridge view that adds data to the sales order creation task COM_SalesOrderFulfillment_CreationTask for the new fulfillment function. This composite cartridge view should extend from the base task of the new fulfillment function.

    • Create a composite cartridge view that adds data to the sales order query tasks such as COM_SalesOrder_StateChangeView and COM_SalesOrder_AggregatedOLMView for the new fulfillment function.

14. Add the data for the new tasks you created to the composite cartridge views.

15. Create a task data contribution to extend the existing sales order creation task with the following information:

    • Order = COM_SalesOrderFulfillment

    • Process = COM_SalesOrderFulfillmentOrchestrationProcess

    • Task = COM_SalesOrderFulfillment_CreationTask

    • Composite Cartridge View = YourCompositeCartridgeViewForCreationTask

16. Create a query task data contribution to extend the existing sales order query tasks with the following fields:

    • Order = COM_SalesOrderFulfillment

    • Role = COM_SalesOrder_AggregatedOLM_Role, COM_SalesOrder_StateChange_Roles

    • Query Task = COM_SalesOrder_AggregatedOLMView, COM_SalesOrder_StateChangeView

    • Composite Cartridge View = YourCompositeCartridgeViewForQueryTask

17. In the resources/SolutionConfig folder of the Order-to-Activate composite cartridge such as OracleComms_OSM_O2A_COMSOM_TypicalSolution:

    • Add a new <Component> entry to the ComponentExtensionPointMap.xml file for the new fulfillment function. For each applicable fulfillment function extension point, create an XQuery file based on an existing fulfillment function extension point XQuery file, for example, SyncCustomerComplete_Event.xquery.

    • Add a new entry of a query task to the ComponentQueryViewMap.xml file for the new fulfillment function.

    • If new milestones are to be introduced for the new fulfillment function:

      • add a new <MilestoneMap> entry to the ComponentMilestoneMap.xml file for the new fulfillment function

      • add a new <StatusItemContext> entry for each new milestone to the OrderItemStatusContextMap.xml file

    • If fallout simulation is needed for the new fulfillment function, add a new <FaultModeMap> entry to the FaultModeMap.xml file.

    • Add a new <StatusMap> entry to the OrderStateMap.xml file for the new fulfillment function per system type and fulfillment mode.

    • If a new fulfillment provider is added, add a new <targetSystem> entry for each new fulfillment provider instance to the TargetSystemMap.xml file.

    • For each automated task in the process of the new fulfillment function, add a new <TaskExitStatusMap> entry to the TaskExitStatusMap.xml file.

18. Package and deploy the Order-To-Activate composite cartridge.

Adding a New Fulfillment Provider

Oracle AIA has logical identifiers for fulfillment providers (for example, fulfillment instances). There are naming conventions that must correspond to your Oracle AIA deployment, for example, fulfillment system type and fulfillment system code. Currently the logical identifiers and fulfillment system type and application are defined in XML Document TargetSystemMap.xml, which is deployed with the Order-to-Activate composite cartridge (such as OracleComms_OSM_O2A_COMSOM_TypicalSolution). You modify this file when restructuring the fulfillment topology definition, for example when you add more billing system instances. The Sender IDs and Target IDs in the EBM messages must match the logical identifiers for the system instances configured in the Oracle AIA deployment. The following is the summary for fulfillment functions for Oracle AIA:

• Naming convention used for OSM central order management instances: OSMCFS_01, OSMCFS_02, and so on

• Naming convention used for OSM service order management instances: OSMPROV_01, OSMPROV_02, and so on

• Naming convention used for Billing and Revenue Management instances BRM_01, BRM_02, and so on

• Naming convention used for Siebel CRM instances: SEBL_01, SEBL_02, and so on

When adding a fulfillment provider, such as a billing system instance, you must customize a copy of the following files to map the Studio entity name of the system entity to the target ID:

• O2A_CompositeCartridge\resources\SolutionConfig\TargetSystemMap.xml

  For example,

  OracleComms_OSM_O2A_COM_CSO_Solution\resources\SolutionConfig\TargetSystemMap.xml contains all fulfillment providers and their logical identifiers used in the Order-to-Activate cartridges in the Typical topology.

You can name the Studio entity using the Oracle AIA naming convention such as BRM_01, BRM_02, to simplify the fulfillment system mapping to be a direct mapping.

The following procedure describes how to add a new fulfillment provider. For more information about performing the actions in this procedure in Design Studio, see the Design Studio Modeling OSM Orchestration Help.

To add a new fulfillment provider:

1. In the topology cartridge such as the OracleComms_OSM_O2A_TypicalTopology_Sample cartridge, add a new order component specification that extends COM_FulfillmentSystem with COM_SalesOrderFulfillment namespace to represent the new fulfillment provider, and ensure the Order Component Executable check box is deselected.

2. Open the decomposition rule in the form of Topology_DetermineProcessingGranularity_For_FulfillmentFunction in the OracleComms_OSM_O2A_COM_CSO_Topology, OracleComms_OSM_O2A_TypicalTopology, or OracleComms_OSM_O2A_SimpleTopology_Sample cartridge depending on the solution option and topology.

   For example, Typical_DetermineProcessingGranularity_For_SyncCustomer is the decomposition rule for SyncCustomerFunction fulfillment function in the Typical topology.

3. In the Decomposition Rule editor Source/Target tab, select the desired processing granularity under COM_FulfillmentGranularity in the Target Order Components section.

   See "Configuring a New Processing Granularity Rule" for more information on creating a new processing granularity.

4. (Optional) Add or Change decomposition condition in the Decomposition Rule editor Conditions tab.

5. If you are using the Calculate Service Order option in your Order-to-Activate cartridges and you want to add a new fulfillment provider that makes use of the Calculate Service Order transformation sequence, create an order component that references the Calculate Service Order provider function. You can use an existing provisioning order component as an example of the correct way to model this.

6. Package and deploy the Order-to-Activate composite cartridge.

Adding a New Fulfillment Mode

This procedure describes how to add a new fulfillment mode. For more information about performing the actions in this procedure in Design Studio, see the information about adding a new fulfillment mode in the section on extending component cartridges in the Design Studio Modeling OSM Orchestration Help.

To add a new fulfillment mode:

1. Create a new Order and Service Management project to host the new fulfillment mode.

2. In the Order and Service Management Project editor Properties tab, deselect the Standalone check box.

   This allows the cartridge to be referenced in the composite cartridge as part of the solution (rather than as a standalone cartridge with no dependencies).

3. Add a new fulfillment mode with COM_SalesOrderFulfillment namespace for central order management or SOM_ProvisionOrderFulfillment namespace for service order management.

4. Modify the order recognition rule's XQuery to recognize the new fulfillment mode.

   1. Copy the existing OracleComms_OSM_O2A_COM_Base/resources/OrderRecognitionRule/AIAOrderRecognition.xquery to the resources folder of the new OSM cartridge created in step 1, if the new fulfillment mode is for central order management. For service order management, copy the existing OracleComms_OSM_O2A_SOM_Base/resources/OrderRecognitionRule/ProvisionOrderRecognition.xquery to the resources folder of the new OSM cartridge.

   2. Modify the XQuery to recognize the new fulfillment mode.

   3. Create an XML Catalog rewrite rule to override the order recognition rule XQuery.

      For example, for central order management's AIAOrderRecognition.xquery

      <rewriteURI uriStartString="http://xmlns.oracle.com/communications/ordermanagement/o2acombase/order_recognition/AIAOrderRecognition.xquery" rewritePrefix="osmmodel:///<New_OSM_Cartridge>/1.0.0.0.0/resources /AIAOrderRecognition.xquery"/>
      

5. Add the new fulfillment mode to the base fulfillment pattern or to any applicable fulfillment patterns.

6. Model the orchestration plan for the new fulfillment mode for all of the affected fulfillment patterns.

7. In the Fulfillment State Map editor, create fulfillment state mappings for the new fulfillment mode. The fulfillment state map to edit is one of the following:

   • For the calculate service order option:

     In the OracleComms_OSM_O2A_COM_CSO_FulfillmentStateMap cartridge, edit the COM_CSO_FulfillmentStateMap entity.

   • For the solution option without calculate service order:

     In the OracleComms_OSM_O2A_FulfillmentPatternMap cartridge, edit the COM_FulfillmentStateMap entity.

8. Add the cartridge you created for the new fulfillment mode, to the Dependency tab for the Order-to-Activate composite cartridge.

9. Open the Ant view and select Add Buildfiles to add SolutionConfig.xml in the Order-to-Activate composite cartridge, for example OracleComms_OSM_O2A_COMSOM_TypicalSolution.

10. In the Ant view, expand the Order-to-Activate composite cartridge and double-click config_Metadata_And_ModelVariable to ensure that the new fulfillment mode is visible in the Order-to-Activate composite cartridge.

11. Package and deploy the Order-to-Activate composite cartridge.

Adding a New Product Specification

This section provides information about adding a new product specification.

Mapping Product Specifications to Order-to-Activate Sample Fulfillment Patterns

There are two types of product specifications in Design Studio: conceptual model products and OSM product specifications. You do not create a new product specification in OSM, although OSM supports existing product specifications that were created in OSM. Instead, to create a new product, create a new conceptual model Product entity, which will then be mapped to a conceptual model fulfillment pattern, which is realized into an OSM fulfillment pattern. For more information about conceptual model products, see Design Studio Concepts.

Product specification entities can either be imported from a product catalog, such as Oracle Product Hub, or manually created in Design Studio. If you import products, the result will be new conceptual model products, not new OSM products as it was in earlier releases of Design Studio and OSM.

For more information about mapping product specifications to fulfillment patterns in OSM, see the XQuery appendix in OSM Concepts.

Each product specification can be mapped to an Order-to-Activate sample fulfillment pattern. Design Studio generates a mapping file in the resources folder of the OracleComms_OSM_O2A_FulfillmentPatternMap_Sample cartridge. In Oracle AIA, a field called fulfillment item code (FIC) is used to specify the product specification name.

Note:

In communications industry customer orders in AIAEBM format, 'fulfillment item code' is a unique identifier that maps an order line item subject to a Studio recognized fulfillment pattern entity. By default, this is populated with the product specification name for product specification mapping.

Alternatively you can use any combination of attribute values on the order template to drive the mapping of order lines to fulfillment patterns. The value 'item class name' determines some business classification of a product and can be used for product specification mapping. It becomes significant when you adopt a methodology that aligns commercial product specifications with fulfillment commercial services (fulfillment patterns).

When new FulfillmentItemCodes are introduced, you must ensure a mapping of the new FulfillmentItemCode to a fulfillment pattern that exists in the OracleComms_OSM_O2A_FulfillmentPatternMap_Sample/resources/productClassMapping/productClassMapping.xml file so that product specification validation will succeed.

Creating a New Product

This section contains information about creating a new conceptual model product to work with the Order-to-Activate cartridges. For more information about creating a product in Design Studio, see the information about adding a new product specification in the section on extending component cartridges in the Design Studio Modeling OSM Orchestration Help.

A new product is created in the same way as any new conceptual model product in Design Studio, with the following specifics:

1. If you create a new product that requires a new fulfillment pattern, add a new conceptual model fulfillment pattern and then add a new OSM fulfillment pattern that realizes the new conceptual model fulfillment pattern and that extends from the base fulfillment pattern BaseProductSpec.

   Note:

   If you create a new conceptual model cartridge to contain your new conceptual model entities, you must add that cartridge in the Common Model Entity Container field in an appropriate cartridge. If you are using the Calculate Service Order solution option, add the cartridge to the OracleComms_OSM_O2A_COM_CSO_Model_Container cartridge for a central order management (or combined central order management and service order management) environment, or to OracleComms_OSM_O2A_SOM_CSO_ModelContainer for an environment that contains only service order management. If you are using the solution option without Calculate Service Order, add the cartridge to the recognition cartridge in your environment or create a new OSM component cartridge to contain the entries.

2. Specify the location of the external directory containing the fulfillment pattern. From the Window menu, select Preferences, then expand Oracle Design Studio in the Preferences navigation tree, then select Order and Service Management Preferences, and then select Orchestration Preferences. Enter the appropriate directory in the Product Specification Mapping field. For example, enter OracleComms_OSM_O2A_COM_FulfillmentPattern/resources/productSpecMapping if you are using the calculate service order option or OracleComms_OSM_O2A_FulfillmentPatternMap_Sample/resources/productSpecMapping if you are using the option without calculate service order.

Creating a New Fulfillment Pattern

This procedure describes how to add a new fulfillment pattern. For more information about performing the actions in this procedure in Design Studio, see the information about adding a new fulfillment pattern in the Design Studio Modeling OSM Orchestration Help.

To add a new fulfillment pattern:

1. Create a new Order and Service Management project to host the new fulfillment pattern or optionally use the existing fulfillment pattern sample cartridge to host the new fulfillment pattern.

2. In the Order and Service Management Project editor Properties tab, deselect the Standalone check box.

   This allows the cartridge to be referenced in the composite cartridge as part of the solution (rather than as a standalone cartridge with no dependencies).

3. Add a new fulfillment pattern that extends from the base fulfillment pattern BaseProductSpec or its extended fulfillment pattern.

4. Model the orchestration plan for the new fulfillment pattern such as indicating which fulfillment functions are decomposed for which fulfillment mode.

5. Include the new fulfillment pattern on the appropriate decomposition rules that map order line items from fulfillment functions to fulfillment providers. For example, DecompSyncCustomer_To_BRM-VoIP is a decomposition rule that maps order line items for SyncCustomerFunction to BRM-VoIP fulfillment provider.

6. If you added a new cartridge to host the new fulfillment pattern, add the cartridge to the Dependency tab for the Order-to-Activate composite cartridge.

7. Package and deploy the Order-to-Activate composite cartridge.

Customizing Mapping Rules

The following section describes customizing rules for mapping order items to Order-to-Activate sample fulfillment patterns.

The XQuery function osmpip:getProductSpec() defined in the OracleComms_OSM_O2A_CommonUtility cartridge provides an API for mapping customer order items to Order-to-Activate sample fulfillment patterns.

The XQuery function osmpip:getProductSpec() is invoked from the XQuery in the productSpec order item property in the COM_SalesOrderLine order item specification in the OracleComms_OSM_O2A_COM_Base cartridge. By default, the direct mapping rules map the Fulfillment Item Code to a fulfillment pattern.

Customize Rules for Mapping Order Items to Fulfillment Patterns

Customize a copy of the OracleComms_OSM_O2A_COM_Base/resources/OrderItemProperties/ProductSpec.xquery file to customize the direct mapping rule, such as to pass as input the Fulfillment Item Code, to adopt a methodology that aligns the commercial product specifications with the fulfillment patterns when the Fulfillment Item Code is not populated.

Customize Rules for Mapping Order Items with Product Specifications to Fulfillment Patterns

Customize a copy of OracleComms_OSM_O2A_CommonUtility/resources/ProductClassToProductSpec.xquery file to enable the mapping of order items with new product specifications on the customer order to Order-to-Activate sample fulfillment patterns. The ProductClassToProductSpec.xquery file also provides access to common XQuery functions across the central order management cartridges.

Table 5-51 lists the functions found in ProductClassToProductSpec.xquery:

Table 5-51 Functions in ProductClassToProductSpec.xquery

Name	Function Interface	Description
getProductSpec	declare function osmpip:getProductSpec( $salesOrder as element(), $salesOrderLine as element(), $productClassName as xs:string*) as xs:string	This function returns the fulfillment pattern entity as a string based on the given Fulfillment Item Code of a customer order line. If the input value is not specified, or no direct mapping is found, the function uses mapping rules based on data provided on the customer order. The mapping rules, applicable when no direct mapping is found, should check (in the order listed) whether there is a mapping rule specific to: Subject of the order line item, if one exists (One of: Discount, Product, Service Bundle, Offer, SpecialRating, or Unknown). Subject Type (a short way to get couple of other attributes), if one exists. Unknown (as a last resort, use a default mapping rule that maps the Order Line Item to a Fulfillment Item Code of a special Unknown item action). The default mapping rules achieve the following mappings: Service bundle lines having no FulfillmentItemCode and identified by ServiceInstanceIndicator=true, are mapped to a fulfillment pattern of its child order lines. OFFER lines are mapped to fulfillment pattern 'NonService.Offer'. DISCOUNT, SPECIAL RATING, and BUNDLE lines having no FulfillmentItemCode are mapped to fulfillment pattern 'NonService.BillingItem'. When a fulfillment pattern cannot be determined, it is set to fulfillment pattern 'Service.Unknown'.
getDoublePlayPrimaryClassificationCode	declare function osmpip:getDoublePlayPrimaryClassificationCode( $orderline as element(), $salesOrder as element()) as xs:string*	This function returns the classification code of a customer order line. The classification code is used by decomposition rule conditions and order line item dependencies. The classification of order line items is based on the fulfillment topology definition. For example, for order lines in which the fulfillment pattern itself is not sufficient to determine the billing provider (such as offer, discount, and bundle lines) order line items are classified into VoIP only, BroadBand only, or combination Broadband and VoIP, based on the demonstration Typical fulfillment topology definition to determine the appropriate billing provider. Offer and bundle lines go to as many different, unique billing providers as in its child lines in the customer order. Discount lines, if contained in a service bundle, follow the service bundle.
getBillingPattern	declare function osmpip:getBillingPattern( $orderline as element()) as xs:string	Return the billing pattern of the current customer order line.

Importing the New Product Specification

It is possible to query product specifications and transaction attributes into Design Studio directly from the Oracle Product Hub. Design Studio users use the existing Oracle AIA interface QueryProductClassAndAttributesSCECommsReqABCSImpl to import product specifications from both Siebel CRM and the Product Hub. When product specifications are queried using this interface, the interface API checks for Product Hub implementation in the solution stack, and if it is there, the product specifications will be imported to Design Studio from the Product Hub. Otherwise, the product specifications will be imported from Siebel CRM.

Import the new product specifications as described in the Design Studio Help. After importing the product specifications, follow this procedure:

1. Open the newly imported or modified conceptual model product.

2. Map the new or changed product to the appropriate conceptual model fulfillment pattern.

Changing Processing Granularity

This section provides information on changing the processing granularity for an order item.

To change processing granularity for a fulfillment function:

1. Open the decomposition rule in the form of Topology_DetermineProcessingGranularity_For_FulfillmentFunction in the OracleComms_OSM_O2A_COM_CSO_Topology, OracleComms_OSM_O2A_TypicalTopology, or OracleComms_OSM_O2A_SimpleTopology_Sample cartridge depending on the solution option and topology.

   For example, Typical_DetermineProcessingGranularity_For_SyncCustomer is the decomposition rule for SyncCustomerFunction fulfillment function if you are using the calculate service order option.

2. In the Decomposition Rule editor Source/Target tab, select the desired processing granularity under COM_FulfillmentGranularity in the Target Order Components section.

   See "Configuring a New Processing Granularity Rule" for more information on creating a new processing granularity.

3. (Optional) Add or Change decomposition condition in the Decomposition Rule editor Conditions tab.

4. Package and deploy the Order-to-Activate composite cartridge.

Configuring a New Processing Granularity Rule

Begin by creating a new order component specification in Design Studio that extends COM_FulfillmentGranularity and has the COM_SalesOrderFulfillment namespace and give it a name such as YourCustomGranularity.

On the Component ID tab of the newly created order component specification, specify an XQuery condition to return the ComponentId of an order line. Order lines with the same ComponentId value are grouped together for the processing of order lines a group at a time. To construct the XQuery, you can copy the XQuery expression from the Component ID tab of an existing processing granularity rule, such as BundleGranularity shown in Example 5-21, and in it replace BundleGranularity with YourCustomGranularity, and replace TypeCode=(BUNDLE) with the condition that identifies the parent of the group. If you require nested groups to make it on separate fulfillment requests, also replace [fn:last()] with [1]. There are multiple instances of index fn:last() in the XQuery expression; the ones to replace are highlighted below. Otherwise, nested groups are processed on the same fulfillment request.

Example 5-21 Customizable Granularity Configuration XQuery

(: Copyright (c) 2008, 2012, Oracle and/or its affiliates. All rights reserved. :)
import module namespace comqueryviewconstants = "http://xmlns.oracle.com/communications/ordermanagement/o2acombase/comqueryviewconstants" at "http://xmlns.oracle.com/communications/ordermanagement/o2acombase/constants/QueryViewConstants.xquery";
 
declare namespace osm="http://xmlns.oracle.com/communications/ordermanagement/model";
declare namespace prop="COM_SalesOrderFulfillment";
declare namespace osmfn = "java:oracle.communications.ordermanagement.orchestration.generation.OrchestrationXQueryFunctions";
        
let $ancestors := osmfn:ancestors($comqueryviewconstants:COM_ORDER_ITEN_SPEC,$comqueryviewconstants:COM_PARENTCHILD_HIER, $comqueryviewconstants:COM_ORDER_NAMESPACE)
let $relatedItems := osmfn:ancestors($comqueryviewconstants:COM_ORDER_ITEN_SPEC,$comqueryviewconstants:COM_RELATEDITEM_HIER,$comqueryviewconstants:COM_ORDER_NAMESPACE)
return
    (: to locate the bundle that this order line should be included with on a fulfillment request, first follow the RelatedSalesOrderLineId references (if any exist) :)
    if (osm:properties/prop:RelatedSalesOrderLineId/text() != '' and fn:exists($relatedItems))
    then
    (
        let $topmostRelatedItem := $relatedItems[fn:last()]
        let $topmostRelatedItemAncestors := osmfn:ancestors($topmostRelatedItem,$comqueryviewconstants:COM_ORDER_ITEN_SPEC,$comqueryviewconstants:COM_PARENTCHILD_HIER,$comqueryviewconstants:COM_ORDER_NAMESPACE)
        return
        if (fn:exists($topmostRelatedItemAncestors[osm:properties/prop:TypeCode=('BUNDLE')]))
        then
        (
            (: for the topmost related order line, follow the ParentLineId references to locate the outermost bundle. This will cause nested bundles to make it on the same fulfillment request. :)
            concat($topmostRelatedItemAncestors[osm:properties/prop:TypeCode=('BUNDLE')][fn:last()]/osm:properties/prop:BaseLineId/text(),'/BundleGranularity')
        )
        else
        (
            (: locate the root node, such that any other root node on the order along with their related order items makes a separate fulfillment request :)
            concat($topmostRelatedItemAncestors[fn:last()]/osm:properties/prop:BaseLineId/text(),'/BundleGranularity')
        )
    )
    else
    (
        if (fn:exists($ancestors[osm:properties/prop:TypeCode=('BUNDLE')]))
        then
        (
            (: follow the ParentLineId references to locate the outermost bundle. This will cause nested bundles to make it on the same fulfillment request. :)
            concat($ancestors[osm:properties/prop:TypeCode=('BUNDLE')][fn:last()]/osm:properties/prop:BaseLineId/text(),'/BundleGranularity')
        )
        else
        (
            (: locate the root node, such that any other root node on the order along with their related order items makes a separate fulfillment request :)
            concat($ancestors[fn:last()]/osm:properties/prop:BaseLineId/text(),'/BundleGranularity')
        )
    )

Changing Fulfillment Function Dependencies

This procedure describes how to change fulfillment function dependencies. For more information about performing the actions in this procedure in Design Studio, see the information about the fulfillment pattern editor in the Design Studio Modeling OSM Orchestration Help.

To change fulfillment function dependencies:

1. Open the Fulfillment Pattern editor Orchestration Plan tab for the base fulfillment pattern or any applicable fulfillment pattern for which the dependencies between fulfillment functions needed to be changed.

2. Select the fulfillment mode, for which the dependencies between fulfillment functions need to be changed, in the Fulfillment Mode field.

3. Select the Dependencies tab and do one of the following:

   • In the Dependencies table, select the dependency and change the From Order Component or To Order Component to update the fulfillment function dependency.

   • In the Dependencies table, add a new dependency and specify the From Order Component and To Order Component for the new fulfillment function dependency.

4. Package and deploy the Order-to-Activate composite cartridge.

Setting a Point of No Return

A point of no return (PoNR) is a point during the orchestration process when revisions are no longer accepted and processed for an order. The Hard PoNR indicates that it is technically infeasible to amend the order.

A PoNR is realized when a condition is met on an order line item.

The seeded values in the Order-to-Activate cartridges are:

• A value of NOT YET indicates that the Soft PoNR has been reached for an order line.

• A value of HARD indicates that a Hard PoNR has been reached for an order line, which signifies that it is technically infeasible to revise the order beyond this point.

Each fulfillment pattern may have a PoNR set to HARD at a different fulfillment state in the fulfillment flow.

In the Order-to-Activate cartridge, the value of PoNR for each order line item is stored in ControlData/OrderItem/WorkLineItemData/RevisionPermissibleCode in the order data in the format [SOFT]NOT YET or [HARD]HARD.

A fulfillment state is set before and after each fulfillment function. There may be multiple fulfillment states during the progress of a fulfillment function, such as IN_PROGRESS-PROVISION_DESIGNED and COMPLETE-PROVISION_COMPLETE. In this case, the RevisionPermissibleCode value is returned in the fulfillment data updates from provisioning and is updated into the order data.

RevisionPermissibleCode must be updated at every fulfillment function transition because there is no guarantee on the conditions that cause fulfillment functions to be called in a fulfillment pattern. Update the order data as follows:

• Before every fulfillment function until PoNR is reached (if a PoNR is non-existent or null, set RevisionPermissibleCode to NOT YET)

• For every function transition after which the HARD PoNR is reached (if a PoNR is non-existent, null, or has the value NOT YET, set RevisionPermissibleCode to HARD)

• productSpec1: (NOT YET) FunctionA --> (NOT YET)--> FunctionB--> (HARD) --> FunctionC

• productSpec2: (NOT YET) FunctionA --> (HARD) --> FunctionB --> (HARD) --> FunctionC

A HARD PoNR is set at the FunctionC Start milestone for productSpec1, and at the FunctionB Start milestone for productSpec2. Assuming that FunctionB may be skipped if a conditional expression is not met, PoNR=HARD must be set between FunctionA and FunctionC: (NOT YET): FunctionA --> (HARD) --> FunctionC.

For fulfillment functions, these values are implemented in the order data updates in the automated tasks of the subprocess. For example:

Table 5-52 lists the various hard PoNRs for each fulfillment pattern.

Table 5-52 Hard Points of No Return by Fulfillment Pattern

Product Spec	Fulfillment Function	HARD PoNR is set	Fulfillment State
NonService.BillingInitatedItem	FulfillBillingFunction	Y	IN_PROGRESS-FULFILL_BILLING_START
NonService.BillingItem	FulfillBillingFunction	Y	IN_PROGRESS-FULFILL_BILLING_START
NonService.Offer	FulfillBillingFunction	Y	IN_PROGRESS-FULFILL_BILLING_START
Service.Broadband	ProvisionOrderFunction	Y	For solutions that are using the Calculate Service Order option: IN_PROGRESS-PROVISION_ISSUED For solutions that are not using the Calculate Service Order option: IN_PROGRESS-PROVISION_DESIGNED
Service.CPE.Broadband	ShipOrderFunction	Y	COMPLETE-SHIP_ORDER_SHIPPED
Service.CPE.VoIP	ShipOrderFunction	Y	COMPLETE-SHIP_ORDER_SHIPPED
Service.Install	InstallOrderFunction	Y	IN_PROGRESS-INSTALL_COMMITTED
Service.VoIP	FulfillBillingFunction	Y	IN_PROGRESS-FULFILL_BILLING_START

OSM enforces HARD PoNR in the order life-cycle policy by disallowing Submit Amendment if the PoNR value in the order data is found to be HARD (for a revised order line item) when a revision order arrives.

PoNR (SalesOrderLine/RevisionPermissibleCode) is included in status updates to Siebel CRM, which occur at every milestone data change. This enables Siebel CRM to enforce the rule that a revision cannot be submitted beyond HARD PoNR for an order line.

Modeling a PoNR

This section describes the steps to add a point of no return for a fulfillment pattern. For more information about performing the actions in this procedure in Design Studio, see the information about configuring points of no return in the Design Studio Modeling OSM Orchestration Help.

To model a point of no return:

1. In the Fulfillment Pattern editor Orchestration Plan tab, select the fulfillment mode for which a PoNR will be added for the fulfillment pattern, and also select a fulfillment function in Order Components section at which the PoNR will be set.

2. Once a fulfillment function is selected, add an entry to the Point of No Return Values box in the Point of No Return subtab. Either click Select and select an existing PoNR value, or click Add and add a new PoNR value. Then select a fulfillment state that will trigger this PoNR for the fulfillment flow of the fulfillment pattern.

3. If you added a new PoNR value rather than selecting an existing value, it will automatically be added as a hard PoNR. If you would like your new PoNR to be a soft PoNR, click the Details tab in the Fulfillment Pattern editor, select your new PoNR from the Point of No Return Values box and then deselect Hard Point of No Return in the Details subtab.

Note:

Point-of-no-return enforcement can be disabled for testing purposes when a new fulfillment function is introduced, or when revision or order cancellation testing is performed. See "Controlling Point of No Return" for more information.

Configuring Fulfillment States

This section describes the steps for configuring fulfillment states. For more information about performing the actions in this procedure in Design Studio, see the information about configuring fulfillment states in the Design Studio Modeling OSM Orchestration Help.

To configure fulfillment states:

1. If a new fulfillment function is introduced, add external fulfillment states to represent status information sent to OSM by fulfillment systems in the Order Component Specification editor External Fulfillment States tab for that order component specification. The external fulfillment states should be in the form of State-YourFunctionName_Milestone. For example, IN_PROGRESS-YourFunctionName_START, representing the starting of your fulfillment function.

2. In the Fulfillment State Map editor, create fulfillment state mappings for each new external fulfillment state for any applicable fulfillment mode for the COM_SalesOrderLine order item. The fulfillment state map to edit is one of the following:

   • For the calculate service order option:

     In the OracleComms_OSM_O2A_COM_CSO_FulfillmentStateMap_Sample cartridge, edit the COM_CSO_FulfillmentStateMap entity.

   • For the solution option without calculate service order:

     In the OracleComms_OSM_O2A_FulfillmentPatternMap_Sample cartridge, edit the COM_FulfillmentStateMap entity.

3. In the Order Item Fulfillment State Composition Rule Set editor for COM_OrderItemStateCompositionRule (in the same cartridge as the fulfilment state map), modify existing composition rules for the BaseProductSpec fulfillment pattern and COM_SalesOrderLine order item if necessary.

4. In the Order Fulfillment State Composition Rule Set editor for COM_OrderStateCompositionRule (in the same cartridge as the fulfilment state map), modify existing composition rules for the COM_SalesOrderFulfillment order if necessary.

5. If a new fulfillment state is introduced in addition to the base fulfillment states (that is, OPEN, IN_PROGRESS, COMPLETE, FAILED and CANCELLED) defined in COM_FulfillmentStateMap, modify the XQuery implementation for any applicable fulfillment state extension points. See Table 5-53 for more information about fulfillment state extension points.

6. If a new fulfillment state is introduced to the solution, ensure that the state is mapped appropriately in the Order Lifecycle Manager entity in the OracleComms_OSM_O2A_COM_Base cartridge. If you need to add or change any mappings, you must first unseal the OracleComms_OSM_O2A_COM_Base cartridge. Oracle recommends resealing the cartridge after you have made your changes. See the information about the Order Lifecycle Manager entity in the Design Studio Modeling OSM Processes Help for more information about viewing and changing these mappings.

7. Package and deploy the Order-to-Activate composite cartridge.

External Fulfillment States

In Order-to-Activate cartridges, the following structure in the order template is required for processing fulfillment states to support revision of orders. The default location for this structure is in the root level of the order data. The data elements (as opposed to the structure elements) are indicated in bold below. These values should be populated by the task that handles the interaction with the external system.

OrderLifeCycleManagement
   OrderItemStatus
      BaseLineId
      LineType
      LineName
      OrderItemComponentStatus
         componentKey
         componentType
         systemType
         MilestoneStatusRecord
            StatusTimestamp
            ExternalFulfillmentStateCode
            MilestoneCode
            ExecutionMode
            componentId
            compensationId
            Status
               Code
               Description

See the information about modeling order template structures for fulfillment states in the OSM Developer's Guide for more information.

Fulfillment State Extension Point Interface

The Order-to-Activate cartridges use XQuery resources to perform functions including setting order item properties, mapping product specifications to fulfillment patterns, managing fulfillment function dependencies, and managing the order life cycle. One way to customize XQueries is to rewrite or add to the out-of-box XQuery module and use the XML catalog to enable URI reference mapping. Extension points are defined for both fulfillment functions and fulfillment states. This section contains information about the fulfillment state extension points. For information about the fulfillment function extension points, see "Fulfillment Function Extension Point Interface."

XML catalogs are system-wide entities, which means an XML Catalog specified in one cartridge will be used when processing requests for orders on other cartridges. With the use of solution cartridges, multiple solutions can be deployed to a single system and coexist with each other.

An XQuery extension script must be implemented in a standalone file. The file URI must be registered to the extension configuration.

Fulfillment State Extension Point Overview

Table 5-53 lists the XQuery extension points for fulfillment states in the Order-to-Activate cartridges.

Table 5-53 Fulfillment State Extension Points

Fulfillment State Extension Point	Description
ORDERITEM_FULFILLMENT_STATE_UPDATED	ORDERITEM_FULFILLMENT_STATE_UPDATED is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point overrides the default evaluation of the order item composite fulfillment state modeled in COM_OrderItemStateCompositionRule to support an order with no order items (order items had been dropped during revision), and to support the completion of a cancellation order.
ORDER_FULFILLMENT_STATE_UPDATED	ORDER_FULFILLMENT_STATE_UPDATED is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order. This extension point overrides the default evaluation of the order composite fulfillment state modeled in COM_OrderStateCompositionRule to support an order with no order items (order items had been dropped during revision), and to support the completion of a cancellation order.
ORDER_STATUS	ORDER_STATUS at the order level is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for the order. This extension point provides order status to the upstream system. ORDER_STATUS at the order item level is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point provides order item status to the upstream system.
ORDER_STATUSCONTEXT	ORDER_STATUSCONTEXT is triggered when the OSM fulfillment state engine finishes evaluation of the composite fulfillment state for the order. This extension point provides order status context to the upstream system.
ORDERITEM_MILESTONE	ORDERITEM_MILESTONE is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point calculates the order item milestone, taking order cancellation into consideration.
ORDERITEM_STATUSCONTEXT	ORDERITEM_STATUSCONTEXT is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point provides order item status context to the upstream system.
REPORT_ORDERITEM_STATUS	REPORT_ORDERITEM_STATUS is triggered when the OSM fulfillment state engine finishes calculating the composite fulfillment state for an order item. This extension point is not currently being used in the Order-to-Activate cartridges.
REPORT_ORDERITEM_MILESTONE	REPORT_ORDERITEM_MILESTONE is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point overrides the default milestone when handling a cancellation order.
REPORT_ORDERITEM_STATUSCONTEXT	REPORT_ORDERITEM_STATUSCONTEXT is triggered when the OSM fulfillment state engine finishes calculating the composite fulfillment state for an order item. This extension point overrides the default evaluation of the order item composite fulfillment state modeled in COM_OrderItemStateCompositionRule to support different order item status contexts for failed order items with different order fulfillment modes.

Fulfillment state extension points provide a means to handle additional context, such as fulfillment mode and order types (cancel order, revision order, etc), in Order-to-Activate cartridges. This enables you to alter the default behavior modeled in both order composition rules and order item composition rules.

For example, in the ORDER_FULFILLMENT_STATE_UPDATED fulfillment state extension point, the order fulfillment state is changed from what is configured in the COM_OrderStateCompositionRule for the following scenarios:

• If an order has no child order items (because existing lines were dropped in a revision order), the order fulfillment state should be CANCELLED (fulfillment mode CANCEL) or COMPLETED (fulfillment mode DELIVER) instead of PENDING.

• If an order is in progress, the order fulfillment state should be IN_PROGRESS regardless of whether all of the order items have been completed.

• If an order is completed, the order fulfillment state should be COMPLETE or, if the order's fulfillment mode is CANCEL, CANCEL COMPLETE.

ORDERITEM_FULFILLMENT_STATE_UPDATED Extension Point

This section describes the XQuery script that implements the logic to handle the ORDERITEM_FULFILLMENT_STATE_UPDATED extension point. The extension point detects an orphaned order item and sets the fulfillment state value for the orphaned order item. For example, an order item might have no child order item and may not invoke any components (possibly because the order itself does not have any lines in its base order, or because existing lines or components have been removed due to an order amendment). The core fulfillment state engine will not update the order item's fulfillment state, and the order item fulfillment state will remain as PENDING (if no order line was present) or IN_PROGRESS (if an order line has been started but has been removed by an order amendment). In either case, the actual fulfillment state of this order depends on the type of operation (CANCEL or DELIVER). If it is CANCEL, this script changes the fulfillment state of the orphaned order item to CANCELLED. If the operation is DELIVER, the script changes the fulfillment state of the orphaned order item to COMPLETED.

Table 5-54 lists the input parameters for the extension point XQuery.

Table 5-54 ORDERITEM_FULFILLMENT_STATE_UPDATED Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	Order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$hasChildLines	xs:boolean	External variable	True to indicate this order item has children, otherwise false
$hasComponents	xs:boolean	External variable	True to indicate this order item is contained in fulfillment function, otherwise false
.	element()	Context node	The OrderLifeCycleManagement/OrderItemStatus XML fragment for the order item

Table 5-55 lists the return parameters for the extension point XQuery.

Table 5-55 ORDERITEM_FULFILLMENT_STATE_UPDATED Return Parameters

Output Parameter Type	Description
xs:string	Calculated fulfillment state to be set for the orphaned order item

Example 5-22 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OnOrderItemFulfillmentStateUpdated.xquery that demonstrates the extension implementation.

Example 5-22 ORDERITEM_FULFILLMENT_STATE_UPDATED XQuery Code Fragment

import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
import module namespace osmpiplog = "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog" at "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog/LogModule.xquery";
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
declare namespace fulfillmeneStateConstant = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.FulfillmeneStateConstant";

declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $hasChildLines as xs:string external;
declare variable $hasComponents as xs:string external;

declare variable $MODULE_NAME := "OnOrderItemFulfillmentStateUpdate";

declare variable $ORDER_EVENT_CANCELLED := fulfillmeneStateConstant:ORDER_EVENT_CANCELLED();
declare variable $ORDER_EVENT_UPDATE := fulfillmeneStateConstant:ORDER_EVENT_UPDATE();
declare variable $ORDER_EVENT_COMPLETE := fulfillmeneStateConstant:ORDER_EVENT_COMPLETE();

declare variable $ORDER_OPERATION_NORMAL := fulfillmeneStateConstant:ORDER_OPERATION_NORMAL();
declare variable $ORDER_OPERATION_CANCEL := fulfillmeneStateConstant:ORDER_OPERATION_CANCEL();

declare variable $HAS_CHILDS := fulfillmeneStateConstant:HAS_CHILDS();
declare variable $HAS_COMPONENT := fulfillmeneStateConstant:HAS_COMPONENTS();

let $calculatedFulfillmentState :=
    if ($hasChildLines != $HAS_CHILDS and $hasComponents != $HAS_COMPONENT)
    then
    (
        (:
         : No current status can be detects from components or children lines, meaning this line don't invoke any component
         : and also no children line exists, set the status to cancelled if this is cancel order operation or set the status to complete if
         : this is not cancel operation
         :)
        if ($orderEventType = ($ORDER_EVENT_UPDATE, $ORDER_EVENT_COMPLETE))
        then
        (
            if ($orderOperationType = $ORDER_OPERATION_CANCEL)
            then $o2acomfulfillmentstate:CANCELLED_STATE
            else $o2acomfulfillmentstate:COMPLETE_STATE
        )
        else $o2acomfulfillmentstate:CANCELLED_STATE
    )
    else $fulfillmentState
return
    $calculatedFulfillmentState

ORDER_FULFILLMENT_STATE_UPDATED Extension Point

This section describes the XQuery script that implements the logic to handle the ORDER_FULFILLMENT_STATE_UPDATED extension point. This extension point overrides the default calculation result that is based on the COM_OrderStateCompositionRule defined in cartridge OracleComms_OSM_O2A_FulfillmentPatternMap_Sample. The COM_OrderStateCompositionRule only defines the basic aggregation rule that is based on children order item's fulfillment state and does not consider the current order's operation and event.

For example, if an order has no child order items, it maybe because the order itself does not have any base order items, or because the existing order items were dropped during revision. The server Fulfillment state engine may not update the order level fulfillment state or will calculate the order level fulfillment state as PENDING (If no line has started) or IN_PROGRESS (If line has been started but now get dropped). In either case, the actual fulfillment state of this order should depends on the type of operation (CANCEL or DELIVER) and if is CANCEL then this script will override it to CANCELLED or if it is DELIVER then the script will override it to COMPLETED.

Given another example where the fulfillment state engine calculates a CANCEL or COMPLETE state but the order is still in progress state (detected with $orderEventType=ORDER_EVENT_UPDATE), the override value in this case is IN_PROGRESS since the order is still in the middle of processing.

ORDER_EVENT_COMPLETE can be due to DELIVER COMPLETE or DELIVER COMPLETE of a CANCEL order. In this case, operation type is used to detect if it is a normal COMPLETE or CANCEL COMPLETE.

Table 5-56 lists the input parameters for the extension point XQuery.

Table 5-56 ORDER_FULFILLMENT_STATE_UPDATED Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	Order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$hasChildLines	xs:boolean	External variable	True to indicate this order item has children, otherwise false
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-57 lists the return parameters for the extension point XQuery.

Table 5-57 ORDER_FULFILLMENT_STATE_UPDATED Return Parameters

Output Parameter Type	Description
xs:string	Calculated fulfillment state for the order

Example 5-23 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OnOrderFulfillmentStateUpdated.xquery that demonstrates the extension implementation.

Example 5-23 ORDER_FULFILLMENT_STATE_UPDATED XQuery Code Fragment

import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
declare namespace fulfillmeneStateConstant = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.FulfillmeneStateConstant";

declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $hasChildLines as xs:string external;

declare variable $ORDER_EVENT_CANCELLED := fulfillmeneStateConstant:ORDER_EVENT_CANCELLED();
declare variable $ORDER_EVENT_UPDATE := fulfillmeneStateConstant:ORDER_EVENT_UPDATE();
declare variable $ORDER_EVENT_COMPLETE := fulfillmeneStateConstant:ORDER_EVENT_COMPLETE();
declare variable $ORDER_OPERATION_NORMAL := fulfillmeneStateConstant:ORDER_OPERATION_NORMAL();
declare variable $ORDER_OPERATION_CANCEL := fulfillmeneStateConstant:ORDER_OPERATION_CANCEL();
declare variable $HAS_CHILDS := fulfillmeneStateConstant:HAS_CHILDS();

let $calculatedFulfillmentState :=
    if ($hasChildLines != $HAS_CHILDS)
    then
    (
        (: No child lines detected :)
        if ($orderEventType = $ORDER_EVENT_UPDATE)
        then $o2acomfulfillmentstate:IN_PROGRESS_STATE
        else if ($orderEventType = $ORDER_EVENT_COMPLETE)
        then
        (
            (: This is an order complete event,
             : if this is a normal order completion, the status is complete.
             : if this is a cancel order completion, the status is canceled. 
             :)
            if ($orderOperationType = $ORDER_OPERATION_NORMAL)
            then $o2acomfulfillmentstate:COMPLETE_STATE
            else $o2acomfulfillmentstate:CANCELLED_STATE
        )
        else $o2acomfulfillmentstate:CANCELLED_STATE
    )
    else if($fulfillmentState = ($o2acomfulfillmentstate:COMPLETE_STATE, $o2acomfulfillmentstate:CANCELLED_STATE))
    then
    (
        (: Children line exist and all completed or cancelled
         : However if the event is not an order complete or cancelled even than need
         : to switch the status back to in progress
         :)
        if ($orderEventType != $ORDER_EVENT_COMPLETE and $orderEventType != $ORDER_EVENT_CANCELLED)
        then $o2acomfulfillmentstate:IN_PROGRESS_STATE
        else $fulfillmentState
    )
    else
    (
        if ($orderEventType = $ORDER_EVENT_COMPLETE)
        then
        (
            if ($orderOperationType = $ORDER_OPERATION_CANCEL)
            then
            (
                (: An OSM order get cancelled by AIA or Admin then always set the order status to cancelled :)
                $o2acomfulfillmentstate:CANCELLED_STATE
            )
            else (
                (: Only set status to complete if it is not failed.
                 : So OPEN and IN_PROGRESS will forced to COMPLETE but FAILED will be remained.
                 :)
                if ($fulfillmentState != $o2acomfulfillmentstate:FAILED_STATE)
                then $o2acomfulfillmentstate:COMPLETE_STATE
                else $fulfillmentState
            )
        )
        else $fulfillmentState
    )
return
    $calculatedFulfillmentState

ORDER_STATUS Extension Point

This section describes the XQuery script that implements the logic to handle the ORDER_STATUS extension point. This extension point generates the upstream expected status value for the order or order item. The generated value is based on the current composite fulfillment state value of the order or order item.

The mapping between the composite fulfillment state and the upstream status is defined in OracleComms_OSM_O2A_Configuration/solution-config/OrderStatusMap.xml.

Table 5-58 lists the input parameters for the extension point XQuery.

Table 5-58 ORDER_STATUS Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	Current composite fulfillment state of the order or order item
$componentType	xs:string	External variable	Should be set to OrderLifecycleManagement
$systemType	xs:string	External variable	Should be set to CRM
.	element()	Context node	OrderLifeCycleManagement/OrderItemStatus XML fragment if this is invoked for an order item or OrderLifeCycleManagement XML fragment if this is invoked for an order

Table 5-59 lists the return parameters for the extension point XQuery.

Table 5-59 ORDER_STATUS Return Parameters

Output Parameter Type	Description
xs:string	Calculated status value

Example 5-24 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OrderStatus.xquery that demonstrates the extension implementation.

Example 5-24 ORDER_STATUS XQuery Code Fragment

import module namespace statusctxmapmodule = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule/OrderAndOrderItemStatueContextModule.xquery"; 
 
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
 
declare namespace fulfillmeneStateConstant = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.FulfillmeneStateConstant";
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $componentType as xs:string external;
declare variable $systemType as xs:string external;
statusctxmapmodule:getOrderStatus($fulfillmentMode, $fulfillmentState, $componentType, $systemType)

ORDER_STATUSCONTEXT Extension Point

This section describes the XQuery script that implements the logic to handle the ORDER_STATUSCONTEXT extension point. This extension point generates the upstream expected description value to the status for Order. The generated value is based on the current composite fulfillment state value of the Order.

The status context is defined in OracleComms_OSM_O2A_Configuration/solution-config/OrderStatusContextMap.xml.

Table 5-60 lists the input parameters for the extension point XQuery.

Table 5-60 ORDER_STATUSCONTEXT Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$doubleFailure	xs:boolean	External variable	True to indicate this Order is in Fallout during a revision
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-61 lists the return parameters for the extension point XQuery.

Table 5-61 ORDER_STATUSCONTEXT Return Parameters

Output Parameter Type	Description
xs:string	Calculated description of the current order status

Example 5-25 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OrderStatusContext.xquery that demonstrates the extension implementation.

Example 5-25 ORDER_STATUSCONTEXT XQuery Code Fragment

import module namespace statusctxmapmodule = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule/OrderAndOrderItemStatueContextModule.xquery"; 
import module namespace osmpiplog = "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog" at "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog/LogModule.xquery";
import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
 
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
 
declare namespace fulfillmeneStateConstant = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.FulfillmeneStateConstant";
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $doubleFailure as xs:string external;
 
declare variable $IS_DOUBLE_FAILURE := fulfillmeneStateConstant:DOUBLE_FAILURE_TRUE();
declare variable $ORDER_OPERATION_CANCEL := fulfillmeneStateConstant:ORDER_OPERATION_CANCEL();
declare variable $ORDER_EVENT_CANCELLED := fulfillmeneStateConstant:ORDER_EVENT_CANCELLED();
 
declare variable $TRUE := "TRUE";
declare variable $FALSE := "FALSE";
declare variable $MODULE_NAME := "OrderStatusContext";
 
declare function local:hasOrderItemCancelled(
   $orderItemsFulfilmentState as element()) as xs:boolean
{
    fn:exists($orderItemsFulfilmentState/oms:fulfillmentState[text()=$o2acomfulfillmentstate:CANCELLED_STATE])
};
 
declare function local:isAllOrderItemFailed(
   $orderItemsFulfilmentState as element()) as xs:boolean
{
   let $itemCount := fn:count($orderItemsFulfilmentState/oms:fulfillmentState)
   let $failCount := fn:count($orderItemsFulfilmentState/oms:fulfillmentState[text()=$o2acomfulfillmentstate:FAILED_STATE])
   return 
      if ($itemCount = $failCount)
      then fn:true()
      else fn:false()
};
 
let $orderItemsFulfilmentState := .
return
(
   let $statusStateInfo :=
      <oms:StatusStateInfo>
      {
         if ($fulfillmentState = $o2acomfulfillmentstate:COMPLETE_STATE)
         then
         (
            <oms:statusState>
            {
               if (local:hasOrderItemCancelled($orderItemsFulfilmentState)=fn:true())
               then fulfillmeneStateConstant:COMPLETE_WITH_CANCELLED()
               else fulfillmeneStateConstant:COMPLETE_ALL_COMPLETE()
            }
            </oms:statusState>
         )
         else if ($fulfillmentState = $o2acomfulfillmentstate:FAILED_STATE)
         then
         (
            <oms:statusState>
            {
               if ($orderOperationType = $ORDER_OPERATION_CANCEL or $doubleFailure = $IS_DOUBLE_FAILURE)
               then fulfillmeneStateConstant:FAILED_REVISION_FAILED()
               else
               (
                  if (local:isAllOrderItemFailed($orderItemsFulfilmentState)=fn:true())
                  then fulfillmeneStateConstant:FAILED_ALL_FAILED()
                  else fulfillmeneStateConstant:FAILED_PARTIAL_FAILED()
               )
            }
            </oms:statusState>
         )
         else if ($fulfillmentState = $o2acomfulfillmentstate:CANCELLED_STATE)
         then
         (
            <oms:statusState>
            {
               if ($orderEventType = $ORDER_EVENT_CANCELLED)
               then fulfillmeneStateConstant:CANCELLED_BY_ADMIN()
               else fulfillmeneStateConstant:CANCELLED_BY_UPSTREAM()
            }
            </oms:statusState>,
            <oms:hasOrderItems>
            {
               if (fn:exists($orderItemsFulfilmentState/oms:fulfillmentState))
               then $TRUE
               else $FALSE
            }
            </oms:hasOrderItems>
         )
         else ()
      }
      </oms:StatusStateInfo>
   return
      statusctxmapmodule:getOrderStatusContext($fulfillmentMode, $fulfillmentState, $statusStateInfo)
)

ORDERITEM_MILESTONE Extension Point

This section describes the XQuery script that implements the logic to handle the ORDERITEM_MILESTONE extension point. This extension point generates the upstream expected milestone value to the order item. The implementation for this script is to calculate the milestone value (expected by the upstream CRM system) based on the calculated fulfillment state value and the last reported milestone. For a fulfillment state value equal to CANCELLED, the milestone code is the last milestone code before the cancel was applied to this order item. For other fulfillment states, the milestone code is the current latest milestone code injected by Order-to-Activate or reported from external system.

Also if none of the components invoked by this order item has started then if fulfillment state value equals to CANCELLED, the milestone code is $o2acomfulfillmentstate:NOTSTARTED_MILESTONE, and for all other fulfillment state value, the milestone code is $o2acomfulfillmentstate:NO_MILESTONE.

Table 5-62 lists the input parameters for the extension point XQuery.

Table 5-62 ORDERITEM_MILESTONE Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state.
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$milestoneCode	xs:string	External variable	The prior milestone code of the order item
$orderItemComponentfulfillmentState	xs:string	External variable	The most recent fulfillment state updated from the order component
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-63 lists the return parameters for the extension point XQuery.

Table 5-63 ORDERITEM_MILESTONE Return Parameters

Output Parameter Type	Description
xs:string	Calculated milestone value for the current order item

Example 5-26 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OrderItemMilestone.xquery that demonstrates the extension implementation.

Example 5-26 ORDERITEM_MILESTONE XQuery Code Fragment

import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
import module namespace osmpiplog = "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog" at "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog/LogModule.xquery";
 
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
 
declare variable $MODULE_NAME := "OrderItemMilestone";
 
(:
 : Current fulfillment state is not cancelled then calculate the latest milestone of this line for this time being.
 :)
declare function local:getLatestMilestoneFromComponents(
    $orderItemStatus as element()?) as xs:string
{
    if (fn:exists($orderItemStatus/oms:OrderItemComponentStatus))
    then
    (
        let $lookupIndex := fn:max($orderItemStatus/oms:OrderItemComponentStatus/oms:MilestoneStatusRecord/oms:Status/oms:Code/@index)
        let $latestMilestoneStatusRecord := $orderItemStatus/oms:OrderItemComponentStatus/oms:MilestoneStatusRecord[oms:Status/oms:Code/@index=$lookupIndex]
        return
            $latestMilestoneStatusRecord/oms:MilestoneCode/text()
    )
    else $o2acomfulfillmentstate:NO_MILESTONE    
};
 
declare function local:getLastMilestoneCodeBeforeCancel(
    $orderItemStatus as element()?) as xs:string
{
    if (fn:exists($orderItemStatus/oms:OrderItemComponentStatus))
    then
    (
        let $lookupIndex := fn:min($orderItemStatus/oms:OrderItemComponentStatus/oms:MilestoneStatusRecord/oms:Status/oms:Code[text()=$o2acomfulfillmentstate:CANCELLED_STATE]/@index)
        let $cancelledMilestoneStatusRecord := $orderItemStatus/oms:OrderItemComponentStatus/oms:MilestoneStatusRecord[oms:Status/oms:Code/@index=$lookupIndex]
        let $milestoneStatusRecordBeforeCancelled := $cancelledMilestoneStatusRecord/preceding-sibling::oms:MilestoneStatusRecord[1] 
        return
            if (fn:exists($milestoneStatusRecordBeforeCancelled))
            then $milestoneStatusRecordBeforeCancelled/oms:MilestoneCode/text()
            else $o2acomfulfillmentstate:NOTSTARTED_MILESTONE            
    )
    else $o2acomfulfillmentstate:NOTSTARTED_MILESTONE
};
 
let $orderItemStatus := .
return
    if ($fulfillmentState = $o2acomfulfillmentstate:CANCELLED_STATE)
    then local:getLastMilestoneCodeBeforeCancel($orderItemStatus)
    else local:getLatestMilestoneFromComponents($orderItemStatus)

ORDERITEM_STATUSCONTEXT Extension Point

This section describes the XQuery script that implements the logic to handle the ORDERITEM_STATUSCONTEXT extension point. This extension point generates the upstream expected description value to the status for order item. The generated value is based on the current composite fulfillment state value of the order item. The implementation for this script is to calculate the status context (Description of status) value (expected by the upstream CRM system) based on the calculated fulfillment state value and the current calculated milestone (The milestone code calculated by the XQuery registered to extension ORDERITEM_MILESTONE).

For fulfillment state value equals to FAILED, the status context is the error message map defined in OracleComms_OSM_O2A_Configuration/solution-config/OrderMessageMap.xml.

For all other fulfillment state, the status context is the milestone code append with the string define in OracleComms_OSM_O2A_Configuration/solution-config/OrderItemStatusContextMap.xml

Table 5-64 lists the input parameters for the extension point XQuery.

Table 5-64 ORDERITEM_STATUSCONTEXT Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$milestoneCode	xs:string	External variable	The current milestone code of the order item
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-65 lists the return parameters for the extension point XQuery.

Table 5-65 ORDERITEM_STATUSCONTEXT Return Parameters

Output Parameter Type	Description
xs:string	Calculated description of the current order item status

Example 5-27 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OrderItemStatusContextForDeliver.xquery that demonstrates the extension implementation.

Example 5-27 ORDERITEM_STATUSCONTEXT XQuery Code Fragment

import module namespace statusctxmapmodule = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/statusctxmapmodule/OrderAndOrderItemStatueContextModule.xquery";
import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
import module namespace osmpiplog = "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog" at "http://xmlns.oracle.com/communications/ordermanagement/pip/omspiplog/LogModule.xquery";
 
declare namespace oms="urn:com:metasolv:oms:xmlapi:1";
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $milestoneCode as xs:string external;
 
declare variable $MODULE_NAME := "OrderItemStatusContextForDeliver";
 
(:
 : For DELIVER, CANCEL fulfilllmentMode order, only return the last reported lifecycle if that is failure.
 :)
declare function local:getLatestFailedMilestoneStatusRecordsFromComponent(
   $orderItemComponentStatus as element()) as element()?
{
   let $lookupIndex := fn:max($orderItemComponentStatus/oms:MilestoneStatusRecord/oms:ExternalFulfillmentStateCode/@index)
   let $latestMilestoneStatusRecord := $orderItemComponentStatus/oms:MilestoneStatusRecord[oms:ExternalFulfillmentStateCode/@index=$lookupIndex]
   return
      if ($latestMilestoneStatusRecord/oms:ExternalFulfillmentStateCode/text()=$o2acomfulfillmentstate:FAILED_STATE) 
      then 
      (
         <oms:OrderItemComponentStatus>
            <oms:componentKey>{ $orderItemComponentStatus/oms:componentKey/text() }</oms:componentKey>
            <oms:componentType>{ $orderItemComponentStatus/oms:componentType/text() }</oms:componentType>
            <oms:systemType>{ $orderItemComponentStatus/oms:systemType/text() }</oms:systemType>
            {
               $latestMilestoneStatusRecord
            }
        </oms:OrderItemComponentStatus>                    
     )
     else ()        
};
 
(:
 : Concatenate all translated error message from all components that is currently failed.
 :)
declare function local:getStatusContextForFailedFulfillmentState(
   $orderItemStatus as element()) as xs:string
{
   if (fn:exists($orderItemStatus/oms:OrderItemComponentStatus))
   then
   (
      let $allOrderItemComponentStatus := $orderItemStatus/oms:OrderItemComponentStatus
      let $allFailedComponent :=
         <oms:AllFailedComponents>
         {
            for $orderItemComponentStatus in $allOrderItemComponentStatus
            return local:getLatestFailedMilestoneStatusRecordsFromComponent($orderItemComponentStatus)
         }
         </oms:AllFailedComponents>
      let $allFailedStatusContext :=
         <oms:AllFailedStatusContext>
         {
            for $failedComponent in $allFailedComponent/oms:OrderItemComponentStatus
            let $failedRecord := $failedComponent/oms:MilestoneStatusRecord 
            return
               if ($failedRecord/oms:Status/oms:Description/text()!="")
               then
               (
                   let $errorMsg := statusctxmapmodule:translateErrorMessage($failedComponent/oms:componentType/text(), $failedComponent/oms:systemType/text(), $failedRecord/oms:Status/oms:Description/text())
                   return
                      <oms:context>{ fn:concat($failedRecord/oms:MilestoneCode/text(),": ", $errorMsg)}</oms:context>
                    )
               else ()
        }
        </oms:AllFailedStatusContext>
     return    
        if (fn:exists($allFailedStatusContext/oms:context))
        then fn:string-join($allFailedStatusContext/oms:context/text(), ", ")
        else ""
  )
  else ""
};
 
let $orderItemStatus := .
return
   if ($fulfillmentState = $o2acomfulfillmentstate:FAILED_STATE)
   then local:getStatusContextForFailedFulfillmentState($orderItemStatus)
   else statusctxmapmodule:getOrderItemStatusContext($fulfillmentMode, $fulfillmentState, $milestoneCode)

REPORT_ORDERITEM_STATUS Extension Point

This section describes the XQuery script that implements the logic to handle the REPORT_ORDERITEM_STATUS extension point. This extension point enhances the upstream expected status value of the given order item. The enhanced value will then be updated to order item status field.

Table 5-66 lists the input parameters for the extension point XQuery.

Table 5-66 REPORT_ORDERITEM_STATUS Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$orderItem	Java Object	External variable	oracle.communications.ordermanagement.fulfillmentstatelifecycle.OrderItemFulfillmentStateLifecycle
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-67 lists the return parameters for the extension point XQuery.

Table 5-67 REPORT_ORDERITEM_STATUS Return Parameters

Output Parameter Type	Description
xs:string	The decorated status value of this order item.

Note:

This extension point is not used in current Order-to-Activate implementation.

REPORT_ORDERITEM_MILESTONE Extension Point

This section describes the XQuery script that implements the logic to handle the REPORT_ORDERITEM_MILESTONE extension point. This extension point enhances the upstream expected milestone value of the given order item. The enhanced value will then be updated to order item milestone field.

The implementation for this script is to override the milestone value which is generated by the XQuery registered to extension ODERITEM_MILESTONE. Due to Oracle AIA requirements, if the order item's fulfillment state is cancelled then the milestone value set to upstream must be empty.

Table 5-68 lists the input parameters for the extension point XQuery.

Table 5-68 REPORT_ORDERITEM_MILESTONE Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$orderItem	Java Object	External variable	oracle.communications.ordermanagement.fulfillmentstatelifecycle.OrderItemFulfillmentStateLifecycle
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-69 lists the return parameters for the extension point XQuery.

Table 5-69 REPORT_ORDERITEM_MILESTONE Return Parameters

Output Parameter Type	Description
xs:string	The decorated milestone value of this order item.

Example 5-28 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OnReportMilestoneDeliver.xquery that demonstrates the extension implementation.

Example 5-28 REPORT_ORDERITEM_MILESTONE XQuery Code Fragment

import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
 
declare namespace orderitem = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.OrderItemFulfillmentStateLifecycle"; 
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $orderItem external;
 
let $fulfillmentState := orderitem:getFulfillmentState($orderItem)
return
    if ($fulfillmentState = $o2acomfulfillmentstate:CANCELLED_STATE)
    then ""
    else orderitem:getLatestMilestoneCode($orderItem)

REPORT_ORDERITEM_STATUSCONTEXT Extension Point

This section describes the XQuery script that implements the logic to handle the REPORT_ORDERITEM_STATUSCONTEXT extension point. This extension point enhances the upstream expected status context (Description) value of the given order item. The decorated value will then be updated to order item status context field.

The implementation for this script is to decorate the status context value which is generated by the XQuery registered to extension ORDERITEM_STATUSCONTEXT.

For DELIVER and CANCEL, if an order item's fulfillment state is FAILED and if the failure is not by the order item itself (Not fail due to its invoking component) then populate a message to indicate the failure is caused by its children, otherwise concatenate the milestone value and the status context value.

Table 5-70 lists the input parameters for the extension point XQuery.

Table 5-70 REPORT_ORDERITEM_STATUSCONTEXT Input Parameters

Name	Type	Scope	Description
$fulfillmentMode	xs:string	External variable	Fulfillment mode of the sales order (DELIVER, CANCEL or TSQ)
$fulfillmentState	xs:string	External variable	The order item's current composite fulfillment state
$orderEventType	xs:string	External variable	The event type when this extension is triggered. ORDER_EVENT_UPDATE and ORDER_EVENT_COMPLETE. ORDER_EVENT_UPDATE is set if this is triggered within the fulfillment function's Sub-process's automation task. ORDER_EVENT_COMPLETE is set if this is triggered within OSM order complete event handler.
$orderOperationType	xs:string	External variable	ORDER_OPERATION_CANCEL is set if the Oracle AIA order is doing a cancel operation no matter the cancel is triggered from upstream or from OSM Web Client, otherwise ORDER_OPERATION_NORMAL is set.
$orderItem	Java Object	External variable	oracle.communications.ordermanagement.fulfillmentstatelifecycle.OrderItemFulfillmentStateLifecycle
.	element()	Context node	The OrderLifeCycleManagement XML fragment

Table 5-71 lists the return parameters for the extension point XQuery.

Table 5-71 REPORT_ORDERITEM_STATUSCONTEXT Return Parameters

Output Parameter Type	Description
xs:string	The decorated status context value of this order item

Example 5-29 is a code fragment from OracleComms_OSM_O2A_Configuration/fulfillment-state-extension/OnReportStatusContextForDeliver.xquery that demonstrates the extension implementation.

Example 5-29 REPORT_ORDERITEM_STATUSCONTEXT XQuery Code Fragment

import module namespace o2acomfulfillmentstate = "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant" at "http://xmlns.oracle.com/communications/ordermanagement/o2acom/fulfillmentstate/constant/FulfillmentStateConstantModule.xquery";
 
declare namespace orderItem = "java:oracle.communications.ordermanagement.fulfillmentstatelifecycle.OrderItemFulfillmentStateLifecycle"; 
 
declare variable $fulfillmentMode as xs:string external;
declare variable $fulfillmentState as xs:string external;
declare variable $orderEventType as xs:string external;
declare variable $orderOperationType as xs:string external;
declare variable $orderItem external;
 
let $fulfillmentState := orderItem:getFulfillmentState($orderItem)
let $milestone := orderItem:getLatestMilestoneCode($orderItem)
let $statusContext := orderItem:getStatusContext($orderItem)
return
    if ($fulfillmentState = ($o2acomfulfillmentstate:FAILED_STATE, $o2acomfulfillmentstate:CANCELLED_STATE))
    then $statusContext
    else
    (
        if (fn:exists($milestone) and fn:exists($statusContext) and $milestone != "" and $statusContext != "")
        then fn:concat($milestone, ": ", $statusContext)
        else ""
    )

Adding a New Service for the Calculate Service Order Solution Option

This procedure describes how to add a new service such as broadband, VoIP, or TV to an Order-to-Activate solution cartridge when you are using the calculate service order option. In this example, the new service would work with new Design Studio elements such as a new product specification, fulfillment pattern, and fulfillment provider. The procedure uses techniques and resources discussed throughout this chapter. For more information about performing the actions in this procedure in Design Studio, see the information about adding a new service in the section on extending component cartridges in the Design Studio Modeling OSM Orchestration Help.

To add a new service using Design Studio:

1. In the workspace containing the central order management cartridges, create a new model project to contain the conceptual model entities for your new service.

   Note:

   If you create a new conceptual model cartridge to contain your new conceptual model entities, you must add that cartridge in the Common Model Entity Container field in an appropriate cartridge. For the Calculate Service Order solution option, add the cartridge to the OracleComms_OSM_O2A_COM_CSO_Model_Container cartridge for a central order management (or combined central order management and service order management) environment, or to OracleComms_OSM_O2A_SOM_CSO_ModelContainer for an environment that contains only service order management.

2. Configure new conceptual model entities as appropriate for the service you are adding. This may include adding a new domain or fulfillment pattern or both, and will include adding a new customer facing service (with a component to create a new named relationship) and adding a new product. For more information about the conceptual model, see Design Studio Concepts.

3. Map your conceptual model product to the appropriate conceptual model fulfillment pattern.

4. In the workspace containing the central order management cartridges, create a new Order and Service Management project to host the new service.

5. In the Order and Service Management Project editor Properties tab, deselect the Standalone check box.

   This allows the cartridge to be referenced in the composite cartridge as part of the solution, rather than as a standalone cartridge with no dependencies.

6. If the new service will communicate with one or more new external systems, create new fulfillment providers for the new systems.

   See "Adding a New Fulfillment Provider" for more information about adding a fulfillment provider.

7. If a new fulfillment provider is introduced for the new service, add decomposition rules for the new service in the topology cartridge, for example OracleComms_OSM_O2A_COM_CSO_Topology.

   Alternatively, modify existing decomposition rules such as, for example, DecompFulfillmentFunction_To_FulfillmentProvider for the new service in the topology cartridge.

8. In the resources/SolutionConfig folder of the Order-to-Activate composite cartridge, for example OracleComms_OSM_O2A_COM_CSO_Topology, make the following modifications:

   • If new milestones are to be introduced for the new service for new fulfillment provider, add a new <MilestoneMap> element to the ComponentMilestoneMap.xml file for the new service without the PONR portion.

     For example:

     <oms:MilestoneMap systemType="BRM" systemName="*" execMode="do redo amend_do">
        <oms:ComponentMilestone>COMPONENT-COMPLETE</oms:ComponentMilestone>
        <oms:Milestone>SYNC CUSTOMER COMPLETE</oms:Milestone>
     </oms:MilestoneMap>
     

   • If a new fulfillment provider is added for the new service, add a new <targetSystem> element for each new fulfillment provider instance to the TargetSystemMap.xml file.

9. If you are using order transformation manager for your new service, do the following:

   1. If you added a new conceptual model domain for your service, add a transformation manager for the domain.

   2. If you want to use a different transformation sequence than the one provided with the Order-to-Activate cartridges, add and configure that transformation sequence.

   3. Create a mapping rule and create mappings for your new named relationship.

10. Create order item parameter bindings from your new conceptual model product to the appropriate order item.

11. Add a new OSM fulfillment pattern that extends from the base specification BaseProductSpec (or its extended fulfillment pattern) to represent the new service in central order management. Ensure that your new fulfillment pattern realizes the appropriate conceptual model fulfillment pattern.

    See "Creating a New Fulfillment Pattern" for more information about adding a fulfillment pattern.

12. Specify the location of the external directory containing the fulfillment pattern. From the Window menu, select Preferences, then expand Oracle Design Studio in the Preferences navigation tree, then select Order and Service Management Preferences, and then select Orchestration Preferences. Enter the YourCartridge/resources/productSpecMapping directory in the Product Specification Mapping field.

13. Add the new central order management cartridge you created for the new service and other cartridges on which it has dependencies to the Dependency tab for the Order-to-Activate composite cartridge, for example OracleComms_OSM_O2A_COM_CSO_Solution.

14. In the workspace containing the service order management cartridges, create new conceptual model entities for the service order management services. These should include:

    • All of the entities created for central order management: If central order management and service order management are in separate workspaces, you may want to export the cartridge containing the new central order management entities from the central order management workspace and import it into the service order management workspace.

    • Additional entities for service order management: These may include resource facing services, resources, and technical actions.

    For more information about the conceptual model, see Design Studio Concepts

15. In the workspace containing the service order management cartridges, in the OracleComms_OSM_O2A_SOM_CSO_FulfillmentPattern cartridge, add a new fulfillment pattern that extends from the base specification SOM_Service.Provision (or its extended fulfillment pattern) to represent the new service in service order management.

    See "Creating a New Fulfillment Pattern" for more information about adding a fulfillment pattern.

16. Add decomposition rules for the new service in the OracleComms_OSM_O2A_SOM_CSO_Topology cartridge for service order management.

    Alternatively, modify existing decomposition rules such as DecompSomProvisionOrder_To_FulfillmentProvider for the new service in the topology cartridge.

17. If the new service will communicate with one or more new external systems, create a new provisioning cartridge similar to OracleComms_OSM_O2A_SOM_CSO_Email_Mapping to provision the service.

18. Add the cartridge you created for the new service and other cartridges on which it has dependencies to the Dependency tab for the Order-to-Activate composite cartridge.

19. (Optional) In the appropriate workspace, add a new role for your service if desired. If you add a new role, you must add an entry to the userConfig.xml file for your composite cartridge by doing the following:

    1. Open the Package Explorer view and expand the package for your solution cartridge, such as OracleComms_OSM_O2A_COM_CSO_Solution.

    2. Expand the userConfig folder and open the userConfig.xml file.

    3. Select the Source tab and scroll to the end. Before the closing the </userConfig> element, add an entry like the following:

       <workgroup name="YourRoleName">                   
          <user>oms-automation</user>
          <user>osmlf</user>             
       </workgroup>
       

20. Ensure that the appropriate orders, fulfillment patterns, and recognition rules are included in the manifest for the central order management solution cartridge.

21. Ensure that the appropriate orders, fulfillment patterns, and recognition rules are included in the manifest for the service order management solution cartridge.

22. Package and deploy the Order-to-Activate composite cartridges for both central order management and service order management.

Adding a New Service for the Service Option Without Calculate Service Order

This procedure describes how to add a new service such as broadband, VoIP, or TV to an Order-to-Activate solution cartridge when you are not using the calculate service order option. In this example, the new service would work with new Design Studio elements such as a new product specification, fulfillment pattern, and fulfillment provider. The procedure uses techniques and resources discussed throughout this chapter. For more information about performing the actions in this procedure in Design Studio, see the information about adding a new service in the section on extending component cartridges in the Design Studio Modeling OSM Orchestration Help.

To add a new service using Design Studio:

1. In the workspace containing the central order management cartridges, create a new model project to contain the conceptual model entities for your new service.

   Note:

   If you create a new conceptual model cartridge to contain your new conceptual model entities, you must add that cartridge in the Common Model Entity Container field in an appropriate cartridge. For the solution option without Calculate Service Order, add the cartridge to the recognition cartridge in your environment or create a new OSM component cartridge to contain the entries.

2. Configure new conceptual model entities as appropriate for the service you are adding. This may include adding a new domain or fulfillment pattern or both, and will include adding a new customer facing service (with a component to create a new named relationship) and adding a new product. For more information about the conceptual model, see Design Studio Concepts.

3. Map your conceptual model product to the appropriate conceptual model fulfillment pattern.

4. In the workspace containing the central order management cartridges, create a new Order and Service Management project to host the new service.

5. In the Order and Service Management Project editor Properties tab, deselect the Standalone check box.

   This allows the cartridge to be referenced in the composite cartridge as part of the solution, rather than as a standalone cartridge with no dependencies.

6. If the new service will communicate with one or more new external systems, create new fulfillment providers for the new systems.

   See "Adding a New Fulfillment Provider" for more information about adding a fulfillment provider.

7. If a new fulfillment provider is introduced for the new service, add decomposition rules for the new service in the topology cartridge, for example, OracleComms_OSM_O2A_TypicalTopology_Sample cartridge for central order management.

   Alternatively, modify existing decomposition rules such as, for example, DecompFulfillmentFunction_To_FulfillmentProvider for the new service in the topology cartridge.

8. In the resources/SolutionConfig folder of the Order-to-Activate composite cartridge, for example OracleComms_OSM_O2A_COMSOM_TypicalSolution, make the following modifications:

   • If new milestones are to be introduced for the new service for new fulfillment provider, add a new <MilestoneMap> entry to the ComponentMilestoneMap.xml file for the new service without the PONR portion.

     For example:

             <oms:MilestoneMap systemType="BRM" systemName="*" execMode="do redo amend_do">
                 <oms:ComponentMilestone>COMPONENT-COMPLETE</oms:ComponentMilestone>
                 <oms:Milestone>SYNC CUSTOMER COMPLETE</oms:Milestone>
             </oms:MilestoneMap>
     

   • If a new fulfillment provider is added for the new service, add a new <targetSystem> entry for each new fulfillment provider instance to the TargetSystemMap.xml file.

9. Create order item parameter bindings from your new conceptual model product to the appropriate order item.

10. Add a new OSM fulfillment pattern that extends from the base specification BaseProductSpec (or its extended fulfillment pattern) to represent the new service in central order management. Ensure that your new fulfillment pattern realizes the appropriate conceptual model fulfillment pattern.

    See "Creating a New Fulfillment Pattern" for more information about adding a fulfillment pattern.

11. Specify the location of the external directory containing the fulfillment pattern. From the Window menu, select Preferences, then expand Oracle Design Studio in the Preferences navigation tree, then select Order and Service Management Preferences, and then select Orchestration Preferences. Enter the appropriate directory, for example, OracleComms_OSM_O2A_FulfillmentPatternMap_Sample/resources/productSpecMapping, in the Product Specification Mapping field.

12. Add the new central order management cartridge you created for the new service and other cartridges on which it has dependencies to the Dependency tab for the Order-to-Activate composite cartridge, for example OracleComms_OSM_O2A_COMSOM_TypicalSolution.

13. In the workspace containing the service order management cartridges, create new conceptual model entities for the service order management services. These should include:

    • All of the entities created for central order management: If central order management and service order management are in separate workspaces, you may want to export the cartridge containing the new central order management entities from the central order management workspace and import it into the service order management workspace.

    • Additional entities for service order management: These may include resource facing services, resources, and technical actions.

    For more information about the conceptual model, see Design Studio Concepts

14. In the workspace containing the service order management cartridges, in the fulfillment pattern cartridge for service order management (for example OracleComms_OSM_O2A_SomBBVoIP_FP_NP_Sample), add a new fulfillment pattern that extends from the base specification SOM_Service.Provision (or its extended fulfillment pattern) to represent the new service in service order management.

    See "Creating a New Fulfillment Pattern" for more information about adding a fulfillment pattern.

15. Add decomposition rules for the new service in the OracleComms_OSM_O2A_SomBBVoIPFulfillmentPattern_Sample cartridge for service order management.

    Alternatively, modify existing decomposition rules such as DecompSomProvisionOrder_To_FulfillmentProvider for the new service in the topology cartridge.

16. If the new service will communicate with one or more new external systems, create a new provisioning cartridge similar to OracleComms_OSM_O2A_SomProvisionVoIP_Sample to provision the service.

17. Add the cartridge you created for the new service and other cartridges on which it has dependencies to the Dependency tab for the Order-to-Activate composite cartridge.

18. (Optional) In the appropriate workspace, add a new role for your service if desired. If you add a new role, you must add an entry to the userConfig.xml file for your composite cartridge by doing the following:

    1. Open the Package Explorer view and expand the package for your solution cartridge, such as OracleComms_OSM_O2A_COMSOM_TypicalSolution.

    2. Expand the userConfig folder and open the userConfig.xml file.

    3. Select the Source tab and scroll to the end. Before the closing </userConfig> element, add an entry like the following:

       <workgroup name="YourRoleName">                   
          <user>oms-automation</user>
          <user>osmlf</user>             
       </workgroup>
       

19. Ensure that the appropriate orders, fulfillment patterns, and recognition rules are included in the manifest for the central order management solution cartridge.

20. Ensure that the appropriate orders, fulfillment patterns, and recognition rules are included in the manifest for the service order management solution cartridge.

21. Package and deploy the Order-to-Activate composite cartridges for both central order management and service order management.

Customizing Service Order Management

The Order-to-Activate cartridges use XQuery resources to perform functions in service order management including formatting request messages, processing faults, tracking external system interactions, and processing external fulfillment states. One way to customize XQueries is to rewrite or add to the out-of-box XQuery module and use the XML catalog to enable URI reference mapping. Extension points are defined for both service order management and central order management. This section contains information about the service order management extension points. For information about the central order management extension points, see "Fulfillment Function Extension Point Interface" and "Fulfillment State Extension Point Interface."

XML catalogs are system-wide entities, which means an XML Catalog specified in one cartridge will be used when processing requests for orders on other cartridges. With the use of solution cartridges, multiple solutions can be deployed to a single system and coexist with each other.

An XQuery extension script must be implemented in a standalone file. The file URI must be registered to the extension configuration.

Service Order Management Extension Point Overview

Table 5-72 lists the XQuery extension points for the service order management Order-to-Activate cartridges.

Table 5-72 Service Order Management Extension Points

Service Order Management Extension Point	Description
SOM-CREATE-SOAP-REQUEST	SOM-CREATE-SOAP-REQUEST at the order level is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for the order. This extension point provides order status to the upstream system. ORDER_STATUS at the order item level is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point provides order item status to the upstream system.
SOM-DETECT-FAULT	SOM-DETECT-FAULT is triggered when the OSM fulfillment state engine finishes evaluation of the composite fulfillment state for the order. This extension point provides order status context to the upstream system.
SOM-GET-FAULT-DATA	SOM-GET-FAULT-DATA is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point provides order item status context to the upstream system.
SOM-CHECK-IS-LAST-RESPONSE	SOM-CHECK-IS-LAST-RESPONSE is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point calculates the order item milestone, taking order cancellation into consideration.
SOM-GET-UPDATE-DATA	SOM-GET-UPDATE-DATA is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order. This extension point overrides the default evaluation of the order composite fulfillment state modeled in COM_OrderStateCompositionRule to support an order with no order items (order items had been dropped during revision), and to support the completion of a cancellation order.
SOM-GET-EXTERNAL-FULFILLMENT-STATE	SOM-GET-EXTERNAL-FULFILLMENT-STATE is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point overrides the default evaluation of the order item composite fulfillment state modeled in COM_OrderItemStateCompositionRule to support an order with no order items (order items had been dropped during revision), and to support the completion of a cancellation order.
SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT	SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT is triggered when the OSM fulfillment state engine finishes calculating the composite fulfillment state for an order item. This extension point is not currently being used in the Order-to-Activate cartridges.
SOM-GET-NEW-CORRELATION-ID	SOM-GET-NEW-CORRELATION-ID is triggered when the OSM fulfillment state engine finishes evaluating the composite fulfillment state for an order item. This extension point overrides the default milestone when handling a cancellation order.

When you customize service order management, you can create an ExtensionPointMap entry for each applicable extension point (such as creating a SOAP request) in the resources\SolutionConfig\SomComponenExtensionPointMap.xml of the Order-to-Activate composite cartridge. You must create a separate XQuery file for each extension point.

SOM-CREATE-SOAP-REQUEST Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-CREATE-SOAP-REQUEST extension point.

Table 5-73 lists the input parameters for the extension point XQuery.

Table 5-73 SOM-CREATE-SOAP-REQUEST Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$context	Java Object	External variable	Java type com.mslv.oms.automation.OrderContext Context of the request
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name

Table 5-74 lists the return parameters for the extension point XQuery.

Table 5-74 SOM-CREATE-SOAP-REQUEST Return Parameters

Output Parameter Type	Description
element()*	Return XML message/payload to be sent to the external system. The external system properties (for example, JMS) must be set by the extension point.

SOM-DETECT-FAULT Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-DETECT-FAULT extension point.

Table 5-75 lists the input parameters for the extension point XQuery.

Table 5-75 SOM-DETECT-FAULT Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-76 lists the return parameters for the extension point XQuery.

Table 5-76 SOM-DETECT-FAULT Return Parameters

Output Parameter Type	Description
element()	Return an XML fragment in the following format if a fault is detected: <oms:FaultCnt><oms:Fault></oms:Fault></oms:FaultCnt> Return an XML fragment in the following format if a fault is not detected: <oms:FaultCnt></oms:FaultCnt>

SOM-GET-FAULT-DATA Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-GET-FAULT-DATA extension point.

Table 5-77 lists the input parameters for the extension point XQuery.

Table 5-77 SOM-GET-FAULT-DATA Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-78 lists the return parameters for the extension point XQuery.

Table 5-78 SOM-GET-FAULT-DATA Return Parameters

Output Parameter Type	Description
element()	Extract, transform, and return fault data from the response message into OrderDataUpdate.

SOM-CHECK-IS-LAST-RESPONSE Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-CHECK-IS-LAST-RESPONSE extension point.

Table 5-79 lists the input parameters for the extension point XQuery.

Table 5-79 SOM-CHECK-IS-LAST-RESPONSE Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-80 lists the return parameters for the extension point XQuery.

Table 5-80 SOM-CHECK-IS-LAST-RESPONSE Return Parameters

Output Parameter Type	Description
element()	Return an XML fragment in the following format if this is the last response: <oms:IsLastResponseCnt><oms:LastResponse/></oms:IsLastResponseCnt> Return an XML fragment in the following format if this is not the last response: <oms:IsLastResponseCnt/>

SOM-GET-UPDATE-DATA Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-GET-UPDATE-DATA extension point.

Table 5-81 lists the input parameters for the extension point XQuery.

Table 5-81 SOM-GET-UPDATE-DATA Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-82 lists the return parameters for the extension point XQuery.

Table 5-82 SOM-GET-UPDATE-DATA Return Parameters

Output Parameter Type	Description
element()	Extract and transform order data from the response message into OrderDataUpdate.

SOM-GET-EXTERNAL-FULFILLMENT-STATE Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-GET-EXTERNAL-FULFILLMENT-STATE extension point.

Table 5-83 lists the input parameters for the extension point XQuery.

Table 5-83 SOM-GET-EXTERNAL-FULFILLMENT-STATE Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-84 lists the return parameters for the extension point XQuery.

Table 5-84 SOM-GET-EXTERNAL-FULFILLMENT-STATE Return Parameters

Output Parameter Type

Description

element()

Return an XML fragment in the following format to pass back the state value that applies to all order items: <oms:ExternalFulfillmentStateCnt> <oms:ComponentFulfillmentState>$StateValue </oms:ComponentFulfillmentState> </oms:ExternalFulfillmentStateCnt> Return an XML fragment in the following format to pass back the state value for individual order items: <oms:ExternalFulfillmentStateCnt> <oms:lineItem index="123456"> <oms:baseLineId>baseLineId</oms:baseLineId> <oms:milestoneCode>Milestone</oms:milestoneCode> <oms:statusCode>Status</oms:statusCode> <oms:statusContext>Description</oms:statusContext> <oms:lineType>LINE_TYPE_NONCSO</oms:lineType> </oms:lineItem> </oms:ExternalFulfillmentStateCnt>

SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT extension point.

Table 5-85 lists the input parameters for the extension point XQuery.

Table 5-85 SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-86 lists the return parameters for the extension point XQuery.

Table 5-86 SOM-GET-EXTERNAL-FULFILLMENT-STATE-AT-FALLOUT Return Parameters

Output Parameter Type

Description

element()

Return an XML fragment in the following format to pass back the state value that applies to all order items: <oms:ExternalFulfillmentStateCnt> <oms:ComponentFulfillmentState>$StateValue </oms:ComponentFulfillmentState> </oms:ExternalFulfillmentStateCnt> Return an XML fragment in the following format to pass back the state value for individual order items: <oms:ExternalFulfillmentStateCnt> <oms:lineItem index="123456"> <oms:baseLineId>baseLineId</oms:baseLineId> <oms:milestoneCode>Milestone</oms:milestoneCode> <oms:statusCode>Status</oms:statusCode> <oms:statusContext>Description</oms:statusContext> <oms:lineType>LINE_TYPE_NONCSO</oms:lineType> </oms:lineItem> </oms:ExternalFulfillmentStateCnt>

SOM-GET-NEW-CORRELATION-ID Extension Point

This section describes the XQuery script that implements the logic to handle the SOM-GET-NEW-CORRELATION-ID extension point.

Table 5-87 lists the input parameters for the extension point XQuery.

Table 5-87 SOM-GET-NEW-CORRELATION-ID Input Parameters

Name	Type	Scope	Description
$log	Java Object	External variable	Java type org.apache.commons.logging.Log Logging level related to server log
$taskInputData	element()	External variable	Task data XML fragment
$executionMode	xs:string	External variable	Task execution mode
$breakpointDebugControl	element()	External variable	Debug control XML fragment
$componentName	xs:string	External variable	Fulfillment function name
$taskName	xs:string	External variable	Task name
.	Context node	Context node	Response message XML fragment

Table 5-88 lists the return parameters for the extension point XQuery.

Table 5-88 SOM-GET-NEW-CORRELATION-ID Return Parameters

Output Parameter Type	Description
element()	Return an XML fragment in the following format to pass back the ID: <oms:NewCorrelationIdCnt>$correlationId</<oms:NewCorrelationIdCnt>

Extending XQuery Modules

This section contains general information about extending XQuery modules.

If it is necessary to extend XQuery modules that reside in a sealed cartridge, you must make a copy of the XQuery file and extend it to include custom business logic using the XML catalog.

To extend an XQuery module:

1. In Design Studio, from the Window menu, select Show View and then select Package Explorer.

2. Copy the XQuery file that you want to extend and modify the copy to include custom logic. It's recommended to put the copy of the XQuery files in the Order-to-Activate composite cartridge.

3. In the Project Explorer view, open the Order-to-Activate composite cartridge and navigate to the xmlCatalogs/core directory.

4. Open the file catalog.xml.

5. Update the catalog.xml file by adding an entry to override the XQuery implementation. The new entry should look like this:

   <rewriteURI uriStartString="http://xmlns.oracle.com/communications/ordermanagement/pip/<path>/<XQuery>.xquery” rewritePrefix="osmmodel:///OracleComms_OSM_O2A_COMSOM_TypicalSolution/1.0.0.0.0/resources/<path>/<XQuery>.xquery"/>
   

Note:

This entry must appear on a single line in the file.

Sending Enriched Data to the CRM System

Data that was not originally supplied in the order from the CRM system must often be sent up to Siebel CRM from a downstream system; this data is referred to as enriched data. Enriched data can be an update to an order header value or an added attribute to a line item that was originally supplied in the order from the CRM system. Enriched data cannot include new line items that were not part of the original order from Siebel CRM (only modifications to existing line items).

In the Order-to-Activate cartridges, downstream systems can send enriched data up to the CRM system using the SpecificationGroup area of each order line item. SpecificationGroup is a structure that contains multiple substructures of the order specification. The Specification.Name and Specification.Value parameters store the enriched data.

The demonstration cartridges OracleComms_OSM_O2A_SomProvisionBroadband_Sample and OracleComms_OSM_O2A_SomProvisionVoIP_Sample provide an example of sending enriched data to the CRM system. These cartridges must populate the EBM type ProcessProvisioningOrderUpdateEBM and send that data to the OracleComms_OSM_O2A_SOM_Base cartridge. The OracleComms_OSM_O2A_SOM_Base cartridge in turn creates another EBM type ProcessFulfillmentOrderUpdateEBM that contains the SpecificationGroup structure and sends that data to the OracleComms_OSM_O2A_COM_Base cartridge. The OracleComms_OSM_O2A_COM_Base cartridge in turn creates the EBM type UpdateSalesOrderEBM and sends that data to the CRM system. The SpecificationGroup structure is defined in all of these EBM types.

For example, when the Provisioning task completes in the OracleComms_OSM_O2A_SomProvisionBroadband_Sample cartridge, the service ID is populated and propagated back to the CRM system, which can now use the service ID to track the asset.

Considerations When Integrating with Oracle AIA

The following points refer to EBO attributes that use domain value maps in Oracle AIA, and how to extend the list of seeded values in the OSM cartridges. You update the validation rule in the OracleComms_OSM_O2A_COM_Base cartridge (either reduce the validation level or include the new values) and describe the extensibility of each such EBO attribute on a case-by-case basis.

Consider the following factors when integrating OSM with Oracle AIA:

• XML tags - some fields are key fields with enumerated values. These values are hard coded in the cartridge so they have to match. These are documented in the data dictionary in the cartridge itself.

• The EBO attribute values can be extended - you can add your own values, but they have to line up in the data dictionary in the cartridge, in the customized rules in the cartridge, for instance, where you choose a billing instance based on a value such as BUSINESS vs. RESIDENTIAL. The value would have to come from ABCS correctly to match. Other custom rules could be created that switch on this value.

• Consumers of OSM generated EBMs such as OSM in its service order management role, and ABCS should not make use of the attributes schemeID, and schemeAgencyID in order identifications, order references, line identifications, and line references. The following are couple of examples:

  <corecom:BusinessComponentID schemeID="SALESORDER_ID" schemeAgencyID="COMMON">
  <corecom:BusinessComponentID schemeID="SALESORDER_LINEID" schemeAgencyID="COMMON">
  

• Queue names have to agree if you add another billing function - you would not have to add more queues if you were not adding more fulfillment functions. But if you do, the queue names have to agree with the ABCS.

  Table 5-89 lists the summary of JNDI names for WebLogic JMS Queues for system interactions included in the Order-to-Activate cartridges. In support of system interactions, OSM central order management and OSM service order management communicate with the ABCS for the fulfillment systems such as Siebel CRM ABCS and Oracle Communications Billing and Revenue Management (BRM) ABCS through posting JMS messages to the queues given below.

  In the WebLogic Server Administration console, queues are found by navigating to: Home /JMS Modules /oms_jms_module.

  Note:

  There must be an alignment of JNDI names between OSM and the ABCSs that communicate with it. You must be aware of this alignment if you add additional queues for new fulfillment functions.

  Table 5-89 WebLogic JNDI Request/Response queues

  System interaction request/response	JNDI name	In-bound/Out-bound
  AIA Customer Order support	oracle/communications/ordermanagement/WebServiceQueue	Siebel CRM ABCS to OSM central order management
  AIA Service Order support	oracle/communications/ordermanagement/WebServiceQueue	In-bound to OSM service order management
  SyncCustomer request	oracle/communications/ordermanagement/WebServiceCreateCustomerQueue	OSM central order management to BRM ABCS
  SyncCustomer response	oracle/communications/ordermanagement/WebServiceCreateCustomerResponseQueue	BRM ABCS to OSM central order management
  InitiateBilling request	oracle/communications/ordermanagement/WebServiceCreateBillingOrderQueue	OSM central order management to BRM ABCS
  InitiateBilling response	oracle/communications/ordermanagement/WebServiceCreateBillingOrderResponseQueue	BRM ABCS to OSM central order management
  FulfillBilling request	oracle/communications/ordermanagement/WebServiceCreateBillingOrderQueue	OSM central order management to BRM ABCS
  FulfillBilling response	oracle/communications/ordermanagement/WebServiceCreateBillingOrderResponseQueue	BRM ABCS to OSM central order management
  ProvisionOrder request	oracle/communications/ordermanagement/WebServiceCreateProvisioningOrderQueue	OSM central order management to Oracle AIA destined for OSM service order management
  ProvisionOrder response (ProcessFulfillmentOrderUpdate)	oracle/communications/ordermanagement/WebServiceUpdateFulfillmentOrderQueue	OSM service order management to Oracle AIA destined for OSM central order management
  CancelProvisioningOrder request	oracle/communications/ordermanagement/WebServiceCancelProvisioningOrderQueue	OSM central order management to OSM service order management
  UpdateSalesOrder	oracle/communications/ordermanagement/WebServiceUpdateSalesOrderQueue	OSM central order management to Siebel CRM ABCS
  CreateTroubleTicket request	oracle/communications/ordermanagement/CreateTroubleTicketRequestQueue	OSM central order management to Siebel CRM ABCS
  CreateTroubleTicket response	oracle/communications/ordermanagement/CreateTroubleTicketResponseQueue	Siebel CRM ABCS to OSM central order management
  UpdateTroubleTicket request	oracle/communications/ordermanagement/UpdateTroubleTicketRequestQueue	OSM central order management to Siebel CRM ABCS
  CreateErrorFault	oracle/communications/ordermanagement/CreateErrorFaultQueue	OSM service order management to Oracle AIA
  Fallout for service order management response	oracle/communications/ordermanagement/WebServiceFalloutLFResponseQueue	OSM service order management to central order management
  Abort order response	oracle/communications/ordermanagement/LFAbortOrderPropagationRespQueue	OSM Provisioning to service order management