|Oracle® Communications Order and Service Management Concepts
Part Number E35415-02
|PDF · Mobi · ePub|
This chapter provides conceptual information about Oracle Communications Order and Service Management (OSM) orders.
Before reading this chapter, read "Order and Service Management Overview" to find out about basic OSM concepts.
An order in OSM contains all the data necessary to fulfill the products and services requested by an incoming customer order.
When a customer order is captured in a CRM or other order-source system, it includes data such as the customer's name and contact information, customer billing information, the products that the customer is ordering, and the requested date of delivery. A subset of that information is included in the customer order that is sent to OSM; for example, the customer information and the order line items that specify the service actions that need to be performed.
After the order is created in OSM, the order includes the data needed for processing the order, as well as information that specifies how to complete the order; for example, the default process to run and the order life-cycle policy. See "What an Order Contains" for more information.
This section introduces the terminology used in the OSM documentation when describing orders:
Customer order: An order request received by OSM to obtain a product or products, typically generated by the CRM or some other order-source system. OSM converts the customer order to OSM format after which it is referred to as an order. Sometimes called an in-bound order or a sales order.
Order: An order in the OSM format. You model orders by creating order specifications in Design Studio.
Service order: An order received by an OSM instance acting in the service order management role. A service order is sometimes called a provisioning order.
Revision order. An order that modifies a previously submitted order that is still being processed. For example, a customer may want to switch to a higher level of service before an order is completed.The system can process revision orders until the original order reaches its point of no return. A revision order is sometimes called a supplemental order.
Follow-on order. An order that is submitted to modify a completed order. Follow-on orders are not processed until their order-item dependencies on the in-flight orders allow them to proceed. Follow-on orders are also used for sequencing orders.
Orders that are submitted to OSM typically have a specific purpose that is defined as an order action. This information is usually included in the order header to indicate if the order adds, deletes, or moves a service. For example, the following line from an incoming customer order specifies that the order adds services:
In addition to orders that manage services in different ways, you can create orders for specific order-management purposes. For example:
An order that is created to manage fallout handling.
An order that communicates with a single external system to provision and activate a specific service. For example, to manage a certain configuration, you might create two order types:
An order that is processed by OSM in the central order management role, which handles all of the fulfillment functions.
A service order that is created by OSM in the central order management role and is sent to an instance of OSM acting in the service order management role. This order type would manage the fulfillment requirements specific to the provisioning system.
You typically model a different order type when the structure or order data is different from any existing order type, or when there are specific and different fulfillment requirements.
You can use multiple order specifications to create multiple order types. Each order specification that you create defines a different order type. See "About Modeling Order Specifications" for more information. In addition, you can use inheritance to manage common configurations between orders. See "Re-Using an Order Specification" for more information.
Each order line item in an incoming customer order that OSM receives specifies an action to perform. Order line item actions are typically one of the following:
Add a product or service.
Change an existing product or service.
Delete a product or service.
Update attributes of a product or service.
Cancel an existing product or service.
Move a product or service.
Suspend or resume a product or service.
An order can contain a mix of actions for different products or services. For example, an existing customer might request to add some new products, change some existing products, and remove other products. These can all be included on the same order. See "About Order Items" for more information.
Each order type uses a different order specification. When you model order specifications, you can define the following:
The order data. The data an order can contain is defined in the order template. (See "About the Order Template" for more information.) The order data is initially populated by the creation task. The creation task is used to create an order instance and define its required data. The creation task is required in all orders. See "About Modeling Order Data" and "About the Creation Task" for more information.
The default process that is run when the order is started. See "About the Default Process" for more information.
The order life-cycle policy. Every order type you create must be associated with an order life-cycle policy. The life-cycle policy defines the states that an order can be in, (such as In Progress or Canceled), the rules governing the transitions between those states, and who is authorized to initiate those transitions. For example, you can specify that an order can be transitioned to the Suspended state only when it is in the In Progress state, and only by OSM users of a designated role. See "About OSM Order Life-Cycle Management" for more information.
The order priority range. An order priority value is used by OSM at run time to determine which orders should be given more processing resources when the system is under maximum load. See "About Specifying the Order Priority" for more information.
Order rules. The rules in an order control how various actions take place; for example, when to trigger a jeopardy notification and how delays in the order process should be handled. See "About Order Rules" for more information.
Order fallout definitions. Order fallout definitions enable you to identify specific order data that can cause fallout, and to use order change management to compensate for the error and proceed with processing the order.
For example, it might be common for a task that activates a port to return an error that the port is already in use. The fallout definition can identify the port ID as the data that needs correcting. This allows OSM to undo the resource assignment task in the inventory system, so the task can be redone and the port ID corrected. The order can then resume processing with the corrected data.
See "Order Fallout Management" for more information.
Order-based behaviors. You can use behaviors to manipulate data and to control how data is displayed in the Task Web client. For example, you can validate data, specify the contents of a list, calculate values, or create tooltips for fields. See "About Behaviors" for more information.
Notifications to send when specified events occur, when the order is in jeopardy, or when specific order data has changed. Users can display notifications on the Task Web client Notifications page or receive them in email. You can use notifications with automation plug-ins to send messages to other systems or perform other business logic. See "About Notifications" for more information.
Order permissions. Order permissions control the actions that workgroups can perform on orders. See "About Setting Permissions for Orders" for more information.
At run time, an order includes the data needed for service fulfillment, as well as information about how to process the order. An order includes the following:
The order data. The data an order can contain is defined in the order template. The order template also includes control data. Control data is used by OSM to create the orchestration plan and includes order item data and the structure of the function order components, which represent the first level of decomposition. See "About Modeling Order Data" for more information.
The orchestration plan. The orchestration plan includes the order components, order items, the dependencies between them, and the order in which order items need to be processed.
You do not specify an orchestration plan when you create an order specification. You define the default process, which, for orchestration orders, is an orchestration process. See "About the Default Process" and "Understanding Orchestration" for more information.
You can display the orchestration plan, and the order components and order items included in it, in the Order Management Web client.
The tasks run by the order. You can display information about tasks in the Task Web client. You can also display historical information about the tasks.
When you create a new order model in Oracle Communications Design Studio, you can base the order on an existing order. When you extend an order specification, the extended specification inherits all of the data, tasks, rules, and behaviors of the base specification. You can add new data and behaviors to define unique order specifications and functionality. When you modify a base order specification, the order specifications extended from it are also modified. This means that you can make changes in one place, in the base specification, and those changes apply to the orders that are extended from the base specification.
For example, you might have three order specifications that share a common set of data. You can create a base order that includes configurations common to all three orders. You can then add configurations to each of the three order specifications for the data that is unique to each order specification.
When defining an order specification that is inherited from a base order specification, you cannot edit the inherited order data. For example, you cannot remove or rename data elements inherited from the base order specification. To implement changes to the inherited data, you must edit the data in the base order specification. Design Studio automatically implements those changes among all of the extended order specifications.
When you model the data in an order, you specify the data that the order must include to fulfill the service. For example, in an order for a telephone service, the order must include telephone number data.
The data elements that you can use in an order are defined in the Design Studio Data Dictionary. When you define order data, you can use data elements that already exist in the Data Dictionary data schemas, or you can create new data elements and add them to the Data Dictionary. See "About Importing the Incoming Customer Order Data into the Data Dictionary" for more information.
You can specify alias names for data elements. For example, you might have a data model that contains two instances of a data element called EmployeeID: one defined as a string (defined by the employee's name and a two-digit number), the other defined as an integer (defined by a 6-digit number). To avoid data type collisions in the run-time environment, you can rename one instance of the EmployeeID data element at the order level.
The data model defined in an order specification is called the order template. An order template is the part of an order specification that defines the order data that OSM uses to process and fulfill an order. For example, the order template defines the data required for order items as well as the data required in an order header.
Figure 2-1 shows an order template.
OSM uses the order template when processing the order. For example:
OSM adds the input message to the order template automatically. See "Adding the Input Message to the Order Template" for more information.
You can use data in the order template to manage orders; for example, you can create order keys used by amendment processing. See "About Order Keys" for more information.
You can specify which data in the order template should be considered for amendment processing (data significance). See "About Data Significance" for more information.
You can assign behaviors to data in the order template. See "About Behaviors" for more information.
The data in the order template defines the data that must be present when the order is created and the data that is generated during order processing. Design Studio generates the order-level order template by aggregating the order template definitions for the order item specifications and order components with any data defined at the order level.
Figure 2-2 shows the structure of customer data in the order template.
The order template includes control data. Control data is used by OSM to generate the orchestration plan. Control data is used only for orchestration.
There are typically two areas of the order control data:
ControlData/OrderItem provides the data and structure of order items received in the incoming customer order. Figure 2-3 shows order item data in the order template control data.
ControlData/Functions stores the structure of the function order components generated by the first level of decomposition. Figure 2-4 shows function components represented in the order template. The types of functions (BillingFunction, MarketingFunction, and so on) represent the function-level order components.
You manually model the order control data of order items in Design Studio. Control data for function order components is automatically generated by Design Studio. See the Design Studio Help for information on how control data is modeled and generated.
You can configure the order template to hold status data returned from external systems. Figure 2-5 shows an order template structure that holds status data.
You can also store status data in the order item data and in the function data. Figure 2-6 shows a structure for storing status data. In this example:
The LineID data element provides a reference to the order line item in the incoming customer order.
The SystemInteraction data element stores data about status events; for example, a status code, description, and timestamp.
Figure 2-7 shows a structure for storing status data for functions. In this example:
The componentKey data element provides a reference to the order component instance.
The Response data element stores the message from the external system, as well as the timestamp, description, and status code.
Before OSM can receive an order from an order-source system, you need to create the OSM Data Dictionary.
The Data Dictionary is the repository of data elements used in Design Studio. The Data Dictionary defines data types and structures that can be used within OSM orders. For example, you can define a simple type that represents an IP address or a phone number, or more complex types representing addresses, product attributes and so on.
Data elements in a Data Dictionary are used as building blocks of an OSM order. The data elements within a Data Dictionary project can be referenced by other projects in a work space.
Design Studio automatically creates a Data Dictionary when you create an OSM cartridge project. You can use this default Data Dictionary or create multiple data schemas to add data elements or structure within the same project.
Figure 2-8 shows a list of data schemas in Design Studio.
Each data schema includes a set of data relevant to the function that the data is used with. Figure 2-9 shows the data elements for the mobile Data Dictionary, with mobile-related data such as IMSI and MSISDN.
Figure 2-10 shows data elements for the incoming customer order data.
To import the Data Dictionary for the data received in orders, you import the XSD file for that incoming customer order into OSM. The elements in the XSD file are loaded into the Data Dictionary as OSM data elements. Example 2-1 shows part of an XSD file that includes some of the elements shown in Figure 2-10.
<element name="order" type="im:OrderType"/> <element maxOccurs="1" minOccurs="1" name="numSalesOrder" type="string"> </element> <element maxOccurs="1" minOccurs="1" name="typeOrder"> </element>
For each data element, you specify attributes about the data element; for example, the data type and display name. Figure 2-11 shows the configuration for the requestedDeliveryDate data element.
Child XML elements are imported as child data elements. The Path field shows the parent data elements. In this example, the parent data element of requestedDeliveryDate is SalesOrderLine.
In addition to the order data, the Data Dictionary contains information about the data structure of each incoming customer order. For example, it contains information about the hierarchy of sales item lines, which can consist of offers, bundles, products, and so on. This data structure information can be used to manage the data when it is passed between different fulfillment systems.
When you define an order specification in Design Studio, you must model a creation task. The creation task is a required task. It specifies the required and optional data to be present when the order is created.
The creation task data is used as follows:
The creation task defines the data that must be present when the order is created.
When an order is canceled, the order is returned to the creation task.
If an order includes an orchestration plan, the Cancelled state is the final state. The order cannot be resumed. If the order does not have an orchestration plan, the canceled order is returned to the creation task for the order, and can be re-submitted to be processed again.
When performing compensation, OSM compares the creation task data of the base order with the creation task data of the revision order.
The creation task differs from other tasks as follows:
It is not modeled explicitly as part of a process, but is identified in the order specification.
When an order manager is manually editing an order at the creation task, the order has not been submitted to a process and has had no work completed. The order manager submits the order and at that point the default process is started and the order enters the first task in the process. Prior to submitting the order from the creation task, an OSM user with appropriate privileges may delete the order. Accordingly, the creation task has two task states, submit and delete.
Tip:When modeling a creation task, create a manual task, even if the order is intended to be processed automatically. Using manual tasks as creation tasks ensures that task behaviors are supported at run time if you manually create an order. This can be useful for testing purposes.
When an order is created, some data must be populated to the creation task data. To populate the data, you use a transformation rule, defined in a recognition rule. See "Understanding Order Transformation" for more information.
For orders that require an orchestration plan for fulfillment, (called orchestration orders), the default process is an orchestration process. For orders that do not use orchestration, the default process is a workflow process or workstream process. See "About Workflow Processes and Workstream Processes" for more information.
When an orchestration order is submitted to OSM, the following occurs:
OSM processes the order by running the orchestration process that is specified in the order specification.
The orchestration process specifies the orchestration sequence to use, which in turn specifies the first orchestration stage, which starts the orchestration process.
When the orchestration plan is complete, OSM runs the executable order components in the order specified in the orchestration plan. The order is based on dependencies between the order components and order items.
When the last task in the order completes, the order transitions to the Completed state.
Orchestration orders are typically used by OSM in the central order management role, where multiple fulfillment systems need to be managed and there are dependencies between the fulfillment actions.
Figure 2-12 shows the process flow for an orchestration order.
See "Understanding Orchestration" for more information.
For orders that do not require an orchestration plan for fulfillment, (called process-based orders), the default process is an OSM process, which includes tasks such as Activate_DSLAM. When a process-based order is submitted to OSM for processing, the following occurs:
OSM starts the process that is defined as the default process.
The default process can start subprocesses that run sequentially or in parallel.
After the last task has completed, the order transitions to the Completed state.
Figure 2-13 shows the process flow for a process-based order.
See "About Tasks and Processes" for more information.
It is common for an order to be fulfilled by both orchestration orders and process-based orders. For example:
OSM receives an orchestration order, which generates the orchestration plan, and begins running the executable order components.
One of the executable order components runs a process that spawns a separate, process-based order. The order is sent to a separate OSM instance that is configured to interact with a provisioning system.
The OSM instance configured for provisioning accepts the order, processes it, and returns the status to the originating order.
Figure 2-14 shows an orchestration order running a process-based order.
You assign the default process in the order specification. You specify an orchestration process the same way that you specify any other process. Figure 2-15 shows a default orchestration process in an order specification.
Figure 2-16 shows a default process defined in an order specification.
OSM uses order priority to determine which orders should be given more OSM system resources when the system is under heavy load. This ensures that orders that have higher priority are not starved for resources by lower priority orders.
Order priority does not prevent all lower priority orders from completing until all higher priority orders have completed. OSM is a multi-threaded system and processes as many orders as possible concurrently. You can use follow-on orders to manage inter-order dependencies.
You can specify two values to set the order priority:
The order priority in the recognition rule that specifies which order specification to use.
The order priority range in the order specification.
The order priority in the recognition rule defines the priority of the order in relation to other order types. The default order priority is 5. You can enter a number between 0 and 9, inclusive, or you can include an XQuery expression that sets the order priority based on data in the incoming customer order. For example, the XQuery shown in Example 2-2 retrieves the order priority (as a number) from the FulfillmentPriorityCode data element:
declare namespace fulfillord="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V2"; //fulfillord:ProcessSalesOrderFulfillmentEBM/fulfillord:DataArea/fulfillord:Proces sSalesOrderFulfillment/fulfillord:FulfillmentPriorityCode/text()
The order priority is typically set on the order submitted to OSM from the order-source system, and it is mapped to the OSM priority when transforming the order. An order's priority also can be modified programmatically or manually by using the Task Web client.
Important:Because OSM is typically one of several systems involved in fulfilling orders, order priority must be supported in all systems and middleware for it to be the most effective.
The order priority range specifies the acceptable range of numeric priority (between 0 and 9) that orders of a single type may use. For example, this could allow you to configure a fixed-line order type with a lower range (0 to 4) and a mobile order type with a higher priority range (5 to 9), ensuring that mobile orders are prioritized higher than fixed-line orders.
You create an order priority range by specifying a minimum and maximum priority for the order. OSM rounds priority values up or down to ensure they conform to the order priority range. For example, if you specify a priority range of 5 to 7 and an order is created with a priority of less than 5, the system assumes the intent is to provide the lowest priority allowed for the order, and the priority value of the order is set to 5. Similarly, if a priority higher than 7 is provided for another order of the same type, the system assumes the intent is to provide the highest priority allowed for the order, and the priority value of the order is set to 7.
Table 2-1 shows examples of how the order priority is set by using the order priority from the recognition rule, and the order priority range from the order specification.
|Order Priority Range||Recognition Rule Order Priority 1||Recognition Rule Order Priority 5||Recognition Rule Order Priority 9|
Order Priority Range 1 - 3
Priority = 1
Priority = 3
Priority = 3
Order Priority Range 3 - 5
Priority = 3
Priority = 5
Priority = 5
Order Priority Range 5 - 9
Priority = 5
Priority = 5
Priority = 9
Figure 2-17 shows how to set the order priority range in the Design Studio order editor.
The order priority value is also considered when an order's tasks are run, so that automated tasks are run according to order priority. This requires that Java Messaging Service (JMS) message priority settings are configured for the JMS queues.
You can change the order priority of an in-flight order by using the Order Management Web client. You can specify permissions for which roles can change the priority. See the discussion of changing order priority in OSM Order Management Web Client User's Guide.
Order rules control how various actions take place; for example, when to trigger a jeopardy notification and how delays in the order process should be handled. Rules are used in process flow decisions, conditional transitions, subprocess logic, delay activities, jeopardies, and events.
OSM evaluates order rules by comparing data to data, or data to a fixed value. Figure 2-18 shows an order rule in Design Studio. This rule identifies residential customers in a specific city. This is an example of a rule that might be used to send a fallout notification to a regional fallout manager.
OSM Web client users are assigned roles, which you can use to manage who works on different types of orders, and different types of tasks. When you assign permissions to orders, you define the following for each role:
You can specify if the OSM users belonging to the role can create the order in the Task Web client.
You can specify the data that OSM users can see in the Task Web client Query filter for the associated order. To do so, you can define flexible headers in Design Studio. Figure 2-19 shows the typeOrder field configured as a flexible header in an order specification. This allows the Order Type field to display in the Task Web client Query filter.
Flexible headers are typically used when there are one or more fields on an order that contain information that is the same for multiple orders and which can be used to query and find related orders. Examples of this are external reference numbers, customer numbers, and telephone numbers. Flexible headers can be used to allow order managers to query these data fields across orders in different cartridges as long as they have the same mnemonic path in their order templates. The Task Web Client query screen allows you to input search criteria once. It returns all orders that match the flexible header search values.
You can specify which data OSM users can display in the OSM Web clients. See "About Query Tasks for OSM Clients" for more information.
You can specify the orders that OSM users of the role can see, based on data in the order. Use the Order editor Permissions Filters subtab to limit the orders a role can view. For example, you specify that OSM users see only orders from a region or for a specific type of service.
Figure 2-20 shows conditions defined in Design Studio that allows OSM users in the role to see only orders from customers who have the 408 and 510 area codes.
See "About OSM Roles" for more information.
As an order runs tasks, the data that is available at each task should be the minimum subset of order data necessary for the task to be performed. You can choose the data to display in the OSM Web clients using the following methods:
Use task data to specify which data to display in the Task Web client for manual tasks.
Use behaviors to specify how OSM displays the task data within a manual task; for example, to hide or show task data or to make data read only. See "About Behaviors" for more information.
Use query tasks to specify which data to display in the Order Management Web client Summary tab and Data tab. Query tasks are manual tasks that specify which data to display in the Task Web client when opening an order from a query result rather than from a task in the worklist. A query task is associated with a role that has permissions to view an order and should be limited to the subset of an order specification's data that the particular role is allowed to view. See "About Query Tasks for OSM Clients" for more information.
Order management personnel can display orders in the Task Web client and in the Order Management Web client. You can specify which data is displayed by assigning query tasks to an order. The data that is specified in the query task data is the data that is displayed.
You can select any task as the query task. You can also create special tasks whose only function is to specify which data to display.
Figure 2-21 shows the Permissions tab in the Design Studio Order Editor. The upper screen shows the permissions for the provisioning role, with the provisioning function task as the query task. For the billing role, the billing function task is assigned as the query task.
The Order Management Web client uses two types of views to display orders; a summary view in the Summary tab and a detailed view in the Data tab. When you model a query task, you can specify which of those views (either or both) to display the query task data in.
You can use multiple tasks as query tasks for an order. When you do so:
For the summary view, all the data is displayed in the Order Management Web client Summary tab.
For the detailed view, the data from the query tasks appears as options in the Order Management Web client Data tab View field; each option presents the OSM user with a different view, each containing a specific set of data.
To display the query task in the Task Web client, select the Default checkbox, as shown in Figure 2-21.
In addition to defining the data that can be displayed, you can specify who can see it by using roles. Each role that is associated with an order can be assigned different query tasks. For example, if your order management personnel includes a role for billing specialists, you can create query tasks that show data specific to their activities.
The data that is available for each automation plug-in should be the minimum subset of order data necessary for the plug-in to be performed. You can choose the data to provide to automation plug-ins using the following methods:
Use the task data contained in an automation task to specify which data to provide to an automation plug-in.
Use query tasks to specify which data to provide to an automation plug-in associated to order notification, events, and jeopardies. A query task is a manual task that is associated with a role that has permissions to use some or all order data to run an automation plug-in. See "About Query Tasks for OSM Clients".
In automated tasks, the data that is available to automation plug-ins associated to automated task is already defined in the Task Data tab. However, automation plug-ins used with order notifications, events, and jeopardies do not have immediate access to this task data, and, as a result, must reference a manual task called a query task that defines the task data and behavior data available to the automation plug-in.
You can select any manual task as the query task. You can also create special tasks that are only used as query tasks. Their only function is to specify which data to provide to an automation plug-in.
Figure 2-21 shows the Permissions tab in the Design Studio order editor. The upper screen shows the permissions for the provisioning role, with the provisioning function task as the query task. For the billing role, the billing function task is assigned as the query task.
To associate a query task with an automation plug-in, use the Default checkbox, as shown in Figure 2-21.
Figure 2-22 shows an event notification with an automation plug-in that uses the ProvisioningFunctionTask query task that is defined as the default query task for the provisioning role. This role must be associated to the Run as OSM user that runs the automation plug-in as shown in the Properties Details tab. For more information about associating roles to OSM users, see the OSM Administrator Application User's Guide.