3 How OSM Creates Orders

This chapter provides an overview of how Oracle Communications Order and Service Management (OSM) receives and creates orders. Before reading this chapter, read "Order and Service Management Overview" and "How OSM Processes Orders."

How OSM Receives and Creates Orders

To enable order processing, you need to configure your order-source systems to send orders to OSM. For example, if you use Siebel as a customer relationship management (CRM) system, you configure Siebel to send a sales order to OSM. A single OSM instance can receive orders from multiple order-source systems.

OSM receives and creates orders as follows:

1. The order is captured in a CRM system; for example, as a Siebel sales order.

2. The CRM system sends the sales order to OSM by using the OSM CreateOrder web service operation. The OSM Web Service API is the primary API for external clients that you can use to communicate with OSM (see OSM Developer's Guide for more information).

3. OSM receives the incoming sales order as an XML message in a Java Message Service (JMS) queue managed by Oracle WebLogic Server. Incoming orders are processed directly by the OSM server from the queue.

4. Because a single instance of OSM can process multiple types of orders, OSM needs to determine which type of order to create. For example, if you have created different order specifications for different services, OSM needs to find out which service needs to be fulfilled to know which order specification to use when creating the order.

   To identify the order specification, OSM uses recognition rules. Recognition rules read the data in the incoming order; for example, the type of service, the fulfillment mode (the action to carry out, such as add a service or cancel a service), or the type of customer can all be used to identify the correct order specification. See "About the Data in an OSM Order."

   In most cases, you use one generic order type to create all orders. You can use orchestration to define the order fulfillment process for different service domains and other processing requirements. Oracle recommends having one standard order type that accepts all incoming orders with other order types for only very specific uses, such as a fallout management order type that can extract information about a failed order.

   You typically model a different order specification when the structure or order data is different from any existing order type, or when there are specific and different fulfillment requirements.

5. After the order specification has been identified, OSM uses validation rules to perform order validation. For example, you can use validations rules to:

   • Ensure that all mandatory fields are populated.

   • Ensure that valid characters (numeric or alphanumeric) are used as needed.

6. Following order validation, OSM uses transformation rules to perform order transformation. Order transformation does the following:

   • Normalizes data; for example, ensure that telephone number formats are correct. If there are multiple different CRM systems sending orders with different data structures, you can transform each order into the target order format.

   • Adds data needed for order processing. This data is part of the creation task. The creation task is used by OSM in the order process; for example, when an order is canceled, the order is returned to the creation task. The creation task is required in all orders.

   • Sets the order priority. The order priority defines the processing priority of the order in relation to other orders in the system.

   • Sets the order reference number. The order reference number is used as an identifier to external systems; for example, between the COM order that generated a child SOM order, or between two sibling SOM orders within an OSM SOM instance.

7. OSM creates the order and runs the default orchestration process to generate the orchestration plan. Every order includes a default process that is run when the order is created.

   Note:

   If an order does not require orchestration, it can run a process directly, not an orchestration process. Most orders require orchestration.

8. OSM executes the orchestration plan to process the order. See "About Orchestration."

Figure 3-1 shows how OSM receives and creates orders. To identify the order specification, you create multiple recognition rules. Each rule is assigned a relevancy. OSM uses the highest relevancy first, until an order specification is found. You can create a catch-all recognition rule (relevancy = 0) to allow OSM to accept any order, even if it cannot process it. This allows you to troubleshoot how orders are received.

Figure 3-1 Receiving and Creating an Order

Description of "Figure 3-1 Receiving and Creating an Order"

About the Data in an Incoming Order

Incoming sales orders typically include the following data:

• The order header information, which contains information that is applicable to the entire order; for example, the sales order number, the order action (Add, Cancel, Delete, and so forth), and customer account information.

• The order line items, which contain information about the products and services on the order.

Figure 3-2 shows part of a sales order, received from a CRM system.

Figure 3-2 Example of a Sales Order

Description of "Figure 3-2 Example of a Sales Order"

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 or cancels products and services for a customer. For example, the following line from an incoming sales order specifies that the order adds services:

<im:typeOrder>Add</im:typeOrder>

The order action is used in an orchestration plan as the fulfillment mode. Fulfillment modes enable OSM to generate an orchestration plan based on whether a service needs to be added, changed, canceled, or qualified, such as validating that the network has enough capacity to offer the purchased products.

Whereas the order header typically contains data that pertains to the entire order, the order line items describe the individual fulfillment actions that need to be carried out. Figure 3-3 shows one of the order line items in its expanded form. Included in this order line item are the requested delivery date and the action to take (Add).

Figure 3-3 Example Order Line Item in a Sales Order

Description of "Figure 3-3 Example Order Line Item in a Sales Order"

Order line items include details about the services that the order must fulfill. They can include:

• The offers, bundles, and products being ordered by the customer, the services these products ultimately resolve to, and the resources that deliver them.

• Information about the services; for example, speed, storage size, and requested service date

Each order line item in an incoming sales order that OSM receives specifies an action to perform. Order line item actions are typically one of the following:

• Add a product, service, or resource.

• Change an existing product, service, or resource

• Delete a product, service, or resource.

• Update attributes of a product, service, or resource.

• Cancel an existing product, service, or resource

• Move a product, service, or resource.

• Suspend or resume a product, service, or resource.

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.

Incoming order item lines also include data that is used later in the service fulfillment process, but not needed by the initial customer order that OSM creates. For example, a customer's street address might not be needed until a technical order is processed to assign a local loop.

About the Data in an OSM Order

When a sales order is captured in an 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 sales order that is sent to OSM; for example, the customer information and the order line items that specify the offers, bundles, and products, and the actions that must be performed on them.

When you model the data in an order specification, you specify the mandatory and optional data that OSM uses to fulfill the service. For example, in an order for a telephone service, the order must include a telephone number. The data an order can contain is called order data, and is defined in the order template. You can define data in data dictionaries and then import these elements into order templates. Modeling data in data dictionaries enables you to reuse the same data definitions across a solution.

The metadata that you model in the order template defines the data that the order can include at runtime. For example, a runtime order can include the following data:

• Information about the order. For example:

  • The type of order, such as a request for a new service or a change to an existing service.

  • Order creation date.

  • Expected completion date.

• Information about the customer; for example, name and address.

• Information about the services being requested; for example, upload speed, download speed, and quality of service.

• The order components, order items, processes, tasks, and dependencies that are required to fulfill the order.

• Status information. For example:

  • If the order is still in flight, or if it has completed.

  • State of the tasks that need to be performed.

• Tracking information; for example, remarks, notifications, and order history.

The data in customer orders, service orders, and technical orders is typically different for each type of order:

• Customer orders include information about the customer, such as their location, the product offerings that the customer purchased, and the product requirements, such as download speed.

• Service orders include information about the customer-facing services that need to be provisioned, including the technical requirements such as bandwidth and quality of service, and the customer's location.

• Technical orders include information about the resources and resource-facing services that need to be activated, and the equipment that needs to the shipped or installed. Resources and resource facing services are identified by the SRM system from customer-facing services that OSM SOM sends to the SRM system.

Data Used for Processing an Order

In addition to data such as the customer's address and phone number, an OSM order includes information that defines how the order is run. This includes:

• Control data. Control data provides information about order items, order components, and dependencies required to generate the orchestration plan. This includes status and requested delivery dates for its order items and components. You can also track order and order item fulfillment states and order item processing states in control data.

• Behaviors. You can use behaviors to manipulate data and to control how data is displayed in the Task web client. For example, you can specify the minimum and maximum times that a data element can be used in an order. See "About Using Behaviors to Customize the Task Web Client."

• Notifications. You can use notifications to alert users and external systems to events that occur in the order as it processes or to tell users that an action must be carried out. See "About Notifications."

• Lifecycle policy. The lifecycle policy defines the states that an order can have; for example, In Progress and Suspended, and the rules governing transitions between states. See "About the Order Lifecycle Policy."

About the Order Lifecycle Policy

Every order specification you create must be associated with an order lifecycle policy. The lifecycle 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.

OSM allows any number of order lifecycle policies to be configured. You can create a custom policy for each order type or one general policy that is applied to many order types. The default order life cycle contains the minimum set of order state and transaction combinations assigned to all roles defined in the system.

Customizing an order lifecycle policy enables you to control the following:

• You can specify conditions that need to be met before an order can transition from one state to another. A common example is specifying the point of no return for revision orders, which controls the transition from the In Progress state to the Submit Amendment and Process Amendment states, effectively causing OSM to reject any further revision orders for the base order.

• You can specify a grace period that allows the order to complete processing tasks before performing a transition to another order state.

• You can specify the roles that are allowed to perform a transaction. Transactions typically transition an OSM order from one order lifecycle state to another. For example, the suspend order transaction causes an OSM order to transition from the In Progress state to the Suspended state.

• You can specify the error message and severity to use when a transition condition is not met.

In addition, you can configure an order to publish common events at specified order lifecycle milestones, such as when an order is first created in OSM, when the order state has changed, or when the order begins amending. These events can be used to trigger notifications. See "About Notifications."