About Orchestration

4 About Orchestration

This chapter provides an overview of how Oracle Communications Order and Service Management (OSM) uses orchestration to manage the order fulfillment process. Before reading this chapter, read "Order and Service Management Overview" and "How OSM Processes Orders."

How OSM Generates and Executes an Orchestration Plan

A single order can fulfill multiple products and services. To process an order, OSM needs to run processes and tasks for a variety of functional areas while interacting with multiple systems. To manage all of the orchestration entities and processes, OSM generates an orchestration plan. The orchestration plan decomposes order items into order components, and establishes dependencies between order components and between order items.

Each order has a unique orchestration plan, based on the customer requirements and the tasks required to complete the order. OSM executes the orchestration plan by running the order's default orchestration process. The orchestration process begins the process of selecting the executable order components to run. As order components run their processes and tasks, the orchestration plan manages their dependencies.

Figure 4-1 shows a high-level view of the process flow for generating and executing an orchestration plan:

Figure 4-1 Generating and Executing an Orchestration Plan

Description of "Figure 4-1 Generating and Executing an Orchestration Plan"

The following process flow describes how OSM typically processes an order.

OSM receives the order from the CRM system and uses recognition rules to find the order specification to use when creating the order. Each order specification that you create identifies a default process to run.
OSM starts generating an orchestration plan by running the order's default orchestration process.

The orchestration plan specifies an orchestration sequence. The orchestration sequence specifies the orchestration stages that need to be followed. The stages define the order components that order items need to be organized into; for example, function order components, target system order components, and granularity order components.
OSM converts order line items in the incoming order into OSM order items and their order item properties. For example, the order line item shown below becomes the Firewall order item with the Add order line action property.
```
<im:serviceActionCode>Add</im:serviceActionCode>
<im:name>Firewall</im:name>
```
This order items displays as Firewall [Add] in the Order Management web client.
In addition to creating the order items required for the order, OSM uses the incoming order data to determine:
- The fulfillment mode (Deliver, Cancel, and so on). Fulfillment modes enable you to design different order fulfillment flows depending on whether the order adds a service, qualifies a service, or deletes a service.
- The product, customer-facing service, resource-facing service, or resource specification. A product specification is a group of related products that share common attributes, such as the same service domain. For example, the products Broadband Light, Broadband Medium, and Broadband Ultimate would all belong to the ServiceBroadBand product specification. When processing an order, you can process order items that belong to the ServiceBroadBand product specification differently from order items that belong to the ServiceMobile product specification.
- The product, customer-facing service, resource-facing service, or resource specification order item action. You might have an order with a fulfillment mode of Add that designates products that the customer wants to perform actions on such as add, alter, or move.
Based on the fulfillment mode and the order item's product, customer-facing service, resource-facing service, or resource specification, OSM assigns each order item to a fulfillment pattern.

In general, order items for a given product specification and a given fulfillment mode need similar fulfillment actions. You create fulfillment patterns that organize order items by the combination of fulfillment mode and product, customer-facing service, resource-facing service, or resource specification. For example, you can define a fulfillment pattern that includes order items for orders that deliver a broadband service. In this case, the fulfillment mode is Deliver, and the product specification is ServiceBroadBand.
The fulfillment pattern initiates the first level of decomposition, by decomposing order items into the function order components identified in the fulfillment pattern. For example, order items are organized into Billing, Shipping, and Provisioning order components.
After decomposing order items into function order components, OSM decomposes the order items in each function component into target system order components. For example, the order items that were decomposed into billing function order components might be further decomposed into order components for a wholesale billing system and a retail billing system.
After decomposing order items into target system order components, OSM decomposes the order items in each target system order component into granularity order components. This is typically the final stage of decomposition, although additional stages can be defined.

Granularity order components are usually needed when a single fulfillment system must process commands in a specific way. For example, you might need to fulfill billing requirements for mobile and fixed services. You can use different order components to process the billing requirements for those services separately.

See "About Decomposition" for more information.
After order items have been decomposed as much as required, OSM runs executable order components. Executable order components run processes that in turn run the tasks to complete the order. The tasks that the executable order component runs are the tasks that complete the order items that the order component contains. For example, an order component that includes activation order items runs a process that runs activation tasks. An order component that includes the following order items can run a single provisioning process (and its subprocesses) to complete all of the order items:
- Fixed Line Service [Add]
- Fixed Call Waiting [Add]
- Fixed Caller ID [Add]
OSM uses the dependencies defined in the orchestration plan to process order components in the correct order. A dependency requires a waiting order item and a blocking order item. The blocking order item is the order item that must be completed before the waiting order item is started. See "About Dependencies."
As the order progresses, OSM can communicate with the originating order-source system to provide information about the status of the order. In addition, OSM tracks the status of each order item and order component. You can configure how the order status is reported by modeling fulfillment states and processing states. See "About Order Status" for more information.
When the last task in the order completes, the order transitions to the Completed state.

About Decomposition

To process order items that are fulfilled for different functions, and by different target fulfillment systems, OSM organizes order items into order components, a process known as decomposition.

Decomposition occurs in stages. Order items are organized into types of order components from general to specific:

Function order components organize order items by functions; such as billing, provisioning, and activation.
Target system order components organize order items by fulfillment systems; for example, an activation system for DSL and an activation system for VoIP.
Granularity order components separate order components that are fulfilled on the same fulfillment system.

The following examples show how decomposition works.

Before decomposing order items into order components, OSM creates order items from order line items in the incoming order. Figure 4-2 shows how order line items for two fixed services and handsets are derived from the order. In addition to separate order items for adding services and shipping handsets, there are different regions defined for each service and handset (Ontario and Quebec).

Figure 4-2 Order Line Items and Order Items

Description of "Figure 4-2 Order Line Items and Order Items"

The first decomposition stage (Determine Functions) organizes order items according to function. Figure 4-3 shows how the order items derived in Figure 4-2 are organized into three function order components: Provisioning, Shipping, and Billing. The fixed-line services require provisioning, the handsets require shipping, and all order items require billing, so all order items are included in the Billing order component.

Figure 4-3 Function Order Components

Description of "Figure 4-3 Function Order Components"

After decomposing order items into function order components, OSM decomposes the order items in each function component into target system order components, and then into granularity order components. These stages are called Determine Target System and Determine Granularity.

Figure 4-4 shows how the order component for the billing function is composed further into two levels of decomposition:

Order items for the Ontario and Quebec regions are decomposed into target system order components. This sends the billing fulfillment process to the correct region, Ontario or Quebec.
For each region, the fixed-line service must be billed separately from the handset. Therefore, order components for each target system are further decomposed into granularity components.

Figure 4-4 Function Order Component Decomposed into Target and Granularity Order Components

Description of "Figure 4-4 Function Order Component Decomposed into Target and Granularity Order Components"

As shown in Figure 4-4, you configure decomposition by modeling decomposition rules.

Figure 4-5 shows how order items are organized across all three orchestration stages.

Figure 4-5 Order Items Decomposed into Order Components

Description of "Figure 4-5 Order Items Decomposed into Order Components"

About Dependencies

An orchestration plan is based on two main factors: decomposition, which organizes order items into order components, and dependencies, which dictate when the executable order components are allowed to run.

Some services might require that some fulfillment tasks are completed before others. For example, you need to complete provisioning order items before you can process activation order items. Dependencies are relationships in which a condition related to one order item must be satisfied before another item can be processed successfully. For example, a piece of equipment must be shipped to a location before the action to install it at that location can be taken.

Dependencies can be between order components in the same order (intra-order dependencies) or between order components in different orders (inter-order dependencies). Inter-order dependencies are particularly common in situations that involve amendments or follow-on orders. For example, the order items in a follow-on order for VoIP provisioning might depend on the execution of the order items in the original order for DSL provisioning. See "About Follow-on Orders."

Dependencies are configured in Design Studio and determined for an order when OSM generates its orchestration plan.

You can model the following types of dependencies. In each of the dependencies below, you can also model a delay after the condition is met. For example, you may want the installation order items to start two days after the shipping order items have completed.

A Completion dependency means that the dependent order item requires that another order item complete before it can begin. For example, the Provisioning order component for the VoIP Service order item cannot begin until the Provisioning order component for the High Speed Internet Service order item is complete.
A Data Change dependency indicates that an order item has a dependency on data in another order item. For example, the status of the Provisioning order component for the VoIP Service order item must be set to Designed before the Ship Order order component for the same order item can begin.
An Order Item dependency indicates that an order item is dependent on the completion of another order item in another order. Because orders can contain many order items, an order component of an order can contain many Order Item dependencies. Order Item dependencies support follow-on orders. Follow-on orders always have at least one order item that has a dependency on an order item in a base order. The line item in the base order must be completed before the line item in the follow-on order can begin processing.

Orders can have combinations of these types of dependencies. For example, an Installation order component may have a Data dependency on the status of a Ship Order order component as well as Order Item dependencies among its order items and order items in other orders.

Although dependencies exist logically between order items, they are managed by order components. In other words, if any item in a component has a dependency, the component as a whole cannot be started until the dependency is resolved. In the Order Management web client, order items include dependency IDs to indicate items whose dependencies are managed together. See Order Management Web Client User's Guide for more information.

About Order Items and Order Components

As described in "How OSM Generates and Executes an Orchestration Plan," orchestration is the process of decomposing order items into order components, which then run based on their dependencies.

Because order items are hierarchical, a single parent order item can include child order items that can be decomposed into multiple function order components. Figure 4-6 shows the order items that can be decomposed into Provisioning, Shipping, and Billing order items.

Figure 4-6 Hierarchical Order Items

Description of "Figure 4-6 Hierarchical Order Items"

The offers, bundles, and products would first be decomposed into function order components for Provisioning, Shipping, and Billing. Therefore, even though all the child order items share a parent order item, they do not necessarily share function order components.

The provisioning order items might be further decomposed into system order components with the following order component IDs:

Provisioning.Voip
Provisioning.Email
Provisioning.Media

The provisioning order items for VoIP might be decomposed into granularity order components with the following order component IDs:

Provisioning.Voip.WholeOrder
Provisioning.Voip.Bundle
Provisioning.Voip.Offer

At runtime, OSM creates an order component ID based on the sum of all order components used in the decomposition. For example, the order component Billing.BillingSystem.FixedBundle represents:

A Billing function order component
A BillingSystem target system component
A FixedBundle granularity component

The Billing.BillingSystem.MobileBundle order component represents:

A Billing function order component
A BillingSystem target system component
A MobileBundle granularity component

Orchestration and COM, SOM, and TOM

As described in "About Customer Orders, Service Orders, and Technical Orders," you can use OSM in the COM, SOM, and TOM roles to run customer orders, service orders, and technical orders in a single service fulfillment process. Each type of order uses orchestration, but each type of order uses different order items.

In the COM role, OSM receives a sales order from the order-source system and creates a customer order. The order items in a customer order typically describe the products, bundles, and offers that customers have purchased; for example, Add Gold Broadband Bundle or Add Triple-Play Plus Offer. Services are generally identified generically, such as a Add Email Service or Add Video Service.

Because a customer order works with order items that describe the products and bundles that customers purchase, OSM in the COM role typically runs executable order components that work directly with billing systems. (A customer who purchases a product needs to be billed for it.)

To manage provisioning order items, such as Email Service [Add] or Video Service [Add], a customer order runs provisioning order components that send data to OSM in the SOM role.

In the SOM role, the order items in the sales order describe customer-facing services; for example Broadband Internet Service [Add] or Video Service [Cancel]. The data in the order contains the provisioning data required to transform the customer-facing services into resource-facing services. For example, the provisioning data might include the customer's location, the bandwidth requirements, and so on.

The executable order components in a service order interact with a service and resource management (SRM) system such as Oracle Communications Unified Inventory Management (UIM). These order components send the provisioning data that describes the service requirements to the SRM. The SRM system returns the data required to activate the services. The executable order components in the service order then send the data to OSM in the TOM role to create a technical order to activate services and ship equipment.

OSM in the TOM role processes a technical order to activate the resource-facing services and interact directly with shipping and workforce management systems. The order items describe resources and resource-facing services such as DSL Service [Add] or Firewall [Add].

The executable order components in a technical order interact with the activation and shipping systems. They send the service requirements, and receive confirmation that the services were activated and equipment shipped.

Figure 4-7 shows examples of the order items that are processed in COM, SOM, and TOM.

Figure 4-7 Order Items in COM, SOM, and TOM

Description of "Figure 4-7 Order Items in COM, SOM, and TOM"

About Order Item Transformation

As described in "Orchestration and COM, SOM, and TOM," OSM in the COM role processes a customer order to transform order items for products into order items for customer-facing services. You can use order item transformation to enable OSM to automatically identify the order items for customer-facing services. To configure order item transformation, you configure the following:

The order items to transform from.
The order items to transform to.
The rules that govern which customer-facing service needs to be implemented.

Figure 4-8 shows how OSM in the COM role runs a customer order to calculate a service order. In this example, OSM can transform the Broadband product order items into the Internet service order items.

Figure 4-8 Order Items Transformed by OSM SOM

Description of "Figure 4-8 Order Items Transformed by OSM SOM"

About the Design Studio Conceptual Model

The Design Studio conceptual model functionality helps you model an order fulfillment process by using the known aspects of your business requirements. Instead of using Design Studio to manually create entities for Oracle Communications ASAP, UIM, and OSM, you provide Design Studio with information about your products, services, and resources, and Design Studio creates entities required for the service fulfillment process.

The conceptual model takes as input such entities as:

Customer-facing services
Resource-facing services
The actions required to fulfill services
Resources on your network
Products in your product catalog
Customer locations

Conceptual model entities represent abstractions of services that are converted into application model entities. This conversion process is called realization. The conversion starts with an abstract conceptual model entity and creates a real application model entity. You include the realized application model entities in application projects, and then deploy the application projects that contain the realized entities to runtime environments.

The application entities that are realized are such entities as:

UIM service configurations. These are the service configurations that OSM needs to design a service.
UIM inventory resources. These are used by OSM to assign resources to services.

You can use the output from a conceptual model as a starting point to model your OSM runtime solution.

See Design Studio Concepts for more information about conceptual model projects. See OSM Modeling Guide for more information about using conceptual model entities to map order items to fulfillment patterns.