Overview of the Order-to-Activate Cartridges

1 Overview of the Order-to-Activate Cartridges

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

About the Application Integration Architecture Order-to-Activate Cartridges

The Order-to-Activate cartridges are pre-built OSM cartridges that support the Oracle Order-to-Activate business process to be used with the Order to Cash Integration Pack for OSM. See "Order-to-Activate Business Process Overview" for a discussion of the Order-to-Activate business process.

Oracle Application Integration Architecture (Oracle AIA) integrates Oracle applications, such as OSM, Siebel Customer Relationship Management (Siebel CRM), Oracle Configure, Price, and Quote Cloud (Oracle CPQ Cloud), and Oracle Communications Billing and Revenue Management (BRM). External systems, such as workforce management applications, can also be included in the solution.

In the Order-to-Activate cartridges:

OSM performs central order management by orchestrating the fulfillment of customer orders coming from Oracle AIA.
OSM performs service order management by orchestrating service orders sent to fulfillment systems.

See OSM Concepts for more details.

Order-to-Activate Business Process Overview

The Oracle Order-to-Activate business process is at the core of business and operational support systems for any Communications Service Provider (CSP). The process extends from the time a quote or order is created to the time when the goods and services are delivered and properly billed. The Order-to-Activate cartridges can be used in an architecture that has Siebel CRM, Oracle CPQ Cloud, or both together.

The following are the steps for the functional flow of the Order-to-Activate business process for orders coming from Siebel CRM:

A customer order is captured in Siebel CRM. For some orders, the order may require technical qualification, such as validating that the network has enough capacity to offer the purchased products. After an order capture is complete and the order is validated in Siebel CRM, the system submits it to OSM in the central order management role for delivery.
Customer orders (both Qualify and Deliver request types) received in OSM in the central order management role are first recognized (as Oracle AIA customer orders), mapped to fulfillment patterns, and enriched with fulfillment metadata.
OSM in the central order management role decomposes (and transforms, if the calculate service order solution option is used) the customer order, dividing it into suborders, called order components, which have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific demands of the CSP.
The outcome is an order orchestration plan that is uniquely generated to match the fulfillment needs of that order. The fulfillment flow that is produced orchestrates fulfillment requests to different fulfillment providers (such as fulfillment system instances or stacks) using preconfigured fulfillment functions, like sync customer, initiate and fulfill billing, and provision order. OSM Order-to-Activate cartridges provide out of the box ready-to-use automatic integration to Oracle AIA web services. When the BRM pre-built integration option is in use, it takes the billing related requests (Sync Customer, Initiate and Fulfill Billing) made by OSM in the central order management role to Oracle AIA, from Oracle AIA to BRM. The Sync Customer Oracle AIA process integration also uses the Siebel CRM pre-built integration option to get customer account details.
OSM in the central order management role manages Order Lifecycle Management (OLM) events. For cancel and revision requests, OSM generates and executes compensation plans to efficiently match a change. OLM manages order data and status updates, and order fallout.
Throughout the fulfillment process, OSM in the central order management role maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. The status management capability updates Siebel CRM with relevant customer status and milestone values. OSM updates Siebel CRM when order lines reach their point-of-no-return (PoNR) to prevent the submission of new revisions. It also updates Siebel CRM with any enrichment to order lines that may have occurred during fulfillment. Errors may occur for many reasons. Oracle AIA reports such errors to OSM for fallout management. Additionally, validation logic in OSM may raise fallout incidents.
OSM detects, reports, and resolves order fulfillment fallout incidents such as system, validation, and fulfillment errors. The Oracle approach creates trouble tickets in Siebel CRM to take advantage of the rich notification, reporting, and management capabilities of Siebel CRM.

The following are the steps for the functional flow of the Order-to-Activate business process for orders coming from Oracle CPQ Cloud:

A customer order is captured in Oracle CPQ Cloud. After an order capture is complete and the order is validated in Oracle CPQ Cloud, the system submits it to OSM in the central order management role for delivery.
Customer orders received in OSM in the central order management role are first recognized (as Oracle AIA customer orders), mapped to fulfillment patterns, and enriched with fulfillment metadata.
OSM in the central order management role decomposes (and transforms, if the calculate service order solution option is used) the customer order, dividing it into suborders, called order components, which have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific demands of the CSP.
The outcome is an order orchestration plan that is uniquely generated to match the fulfillment needs of that order. The fulfillment flow that is produced orchestrates fulfillment requests to different fulfillment providers (such as fulfillment system instances or stacks) using preconfigured fulfillment functions, like sync customer, initiate and fulfill billing, and provision order. OSM Order-to-Activate cartridges provide out of the box ready-to-use automatic integration to Oracle AIA web services. When the BRM pre-built integration option is in use, it takes the billing related requests (Sync Customer, Initiate and Fulfill Billing) made by OSM in the central order management role to Oracle AIA, from Oracle AIA to BRM. The Sync Customer Oracle AIA process integration also uses the OSM Account Manager pre-built integration option to get customer account details.
OSM in the central order management role manages Order Lifecycle Management (OLM) events. For cancel and revision requests, OSM generates and executes compensation plans to efficiently match a change. OLM manages order data and status updates, and order fallout.
Throughout the fulfillment process, OSM in the central order management role maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. The status management capability updates Oracle CPQ Cloud with relevant customer status and milestone values. OSM updates Oracle CPQ Cloud when order lines reach their point-of-no-return (PoNR) to prevent the submission of new revisions. It also updates Oracle CPQ Cloud with any enrichment to order lines that may have occurred during fulfillment. Errors may occur for many reasons. Oracle AIA reports such errors to OSM for fallout management. Additionally, validation logic in OSM may raise fallout incidents.

The Order-to-Activate business process is a sub-process within the Order to Cash business process. The Order to Cash Integration Pack for OSM pre-built integration provides CSPs deployment and integration accelerators that build on forward-looking industry methodology and best practices. The Order to Cash Integration Pack for OSM automates Business Support Systems (BSS) Concept to Launch and BSS Order-to-Activate processes across Siebel CRM, Oracle CPQ Cloud, OSM, BRM, and Oracle Product Hub for Communications. For more information about the Order to Cash business process see Oracle Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management in the Oracle Application Integration Architecture documentation.

Overview of the Order-to-Activate Cartridges

The Order to Cash Integration Pack for OSM solution integrates several Oracle applications that play particular roles in order processing:

Siebel CRM for order capture and trouble ticketing
Oracle CPQ Cloud for cloud-based order capture
OSM for order processing and service fulfillment
Oracle Communications Design Studio for product specification definition including fulfillment metadata and order line to fulfillment pattern mapping
BRM for rating, billing, and revenue management
Oracle AIA Error handling Framework for Fallout management

The order is captured by Siebel CRM or Oracle CPQ Cloud and is sent to OSM (in its central order management role) for processing. Using the recognition rules and other entities provided by the OSM cartridges in the Order to Cash Integration Pack for OSM solution, OSM decomposes the order and dynamically generates an orchestration plan that is used to manage the fulfillment of the customer's order across other enterprise systems.

To manage service fulfillment, OSM in the central order management role creates service orders that it sends to OSM in the service order management role. Depending on the order, recognition rules can be used again to process the order. Each service order is decomposed into processes and tasks that handle the order fulfillment.

In the Oracle AIA solution, OSM does not directly interact with billing, CRM, or Provisioning systems. It interacts with Oracle AIA which in turn uses BRM Application Business Connector Service (ABCS) for billing and CRM ABCS for Siebel CRM.

For more details on Oracle AIA, Siebel CRM, Oracle CPQ Cloud and Oracle AIA interactions, see OSM Concepts and Oracle Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management.

Figure 1-1 illustrates the integration between the systems. The integration includes the following:

Customer order submission from Siebel CRM and Oracle CPQ Cloud to OSM and updates from OSM to Siebel CRM and Oracle CPQ Cloud
Siebel CRM or Oracle CPQ Cloud creates or updates customer assets internally in response to status messages from OSM
Customer data synchronization and order billing from OSM to BRM
Service provisioning from OSM central order management to OSM service order management
Trouble ticket logging for fallout from OSM to Siebel CRM

Figure 1-1 Order-to-Activate Cartridges System Interactions Flow

Description of "Figure 1-1 Order-to-Activate Cartridges System Interactions Flow"

Order-to-Activate Cartridge Solution Options

The Order-to-Activate cartridge solution has two options.

Calculate Service Order: This solution option includes conceptual model entities, the order transformation manager, and Calculate Service Order. It provides access to the latest improvements in OSM and enhances the functionality of the solution. For more information about the order transformation manager and Calculate Service Order, see OSM Concepts.
Non-Calculate Service Order: This solution option does not include the order transformation manager or Calculate Service Order. It is like the pre-2.1.0 versions of the Order-to-Activate cartridges, but it also includes the conceptual model entities that were not available before.

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

The two options cannot be used together, so you must use the central order management cartridges and service order management cartridges from the same option.

OSM Cartridge Types Supporting the Order to Cash Integration Pack for OSM Solution

There are two categories of cartridges that support the Order to Cash Integration Pack for OSM solution in OSM: productized cartridges and demonstration cartridges.

Productized cartridges are customized cartridges supplied by Oracle. They support integration with other applications.

Demonstration cartridges demonstrate the capabilities of OSM and are preconfigured with fulfillment patterns either in Simple or Typical topologies. See "About Fulfillment Topologies" for more details on topologies.

Demonstration cartridges complement productized cartridges to provide a working end-to-end sample set of product specifications and fulfillment patterns. See "Extending the Cartridges" for more details.

OSM central order management orchestrates the fulfillment of customer orders by mapping them to the product specifications of the demonstration cartridges.

OSM entities (recognition rules, tasks, roles, decomposition sequences, and others) play a vital role in the Order to Cash Integration Pack for OSM solution. For more information on an entity in a cartridge, open the entity in Design Studio and click the Information icon.

The cartridges are subclassified into central order management cartridges, or service order management cartridges depending on the fulfillment functions they perform.

Extending the Cartridges

Using Design Studio, OSM enables you to extend the functionality of a productized cartridge to have required functionality.

You can consider a demonstration cartridge as a starting point to understand the capabilities it can offer and then plan to extend the productized cartridge according to your requirements. You can extend a productized cartridge by adding product specifications, inheriting from existing specifications, fulfillment patterns, decomposition sequences, and modifying other entities.

See "Extending Order-to-Activate Cartridges" for more information on extending cartridges.

Example

If you have productized cartridges and demonstration cartridges in different namespaces with corresponding product specification type entities, you can create a customized product specification. To do this you can modify the product specification type entity in the demonstration cartridge and mapp it to the appropriate product specification type entity in the productized cartridge.

To facilitate this customization, OSM derives the ProductSpec name from the property ProductSpecMappingProperty of the OrderItemSpecifcation entity. You can then map it to the appropriate entity in the productized cartridge under the same namespace.

Note:

A namespace is a unique qualifier that logically binds related entities, cartridges, and specifications. To view the namespace and other details about an entity, open the entity in Design Studio and click the Information icon.

Time Zones in Order-to-Activate Cartridges

OSM supports orders and users in multiple time zones. The time zone used by OSM is configured on the server at system installation, and is used to time-stamp incoming and outgoing orders and to schedule work for groups. See OSM Installation Guide for more details.

When OSM uses Order-to-Activate cartridges, the OSM server accepts and processes only those orders that have time stamps in the Coordinated Universal Time (UTC) in the GMT time zone (also called the Z convention). For example, 2010-03-12 08:23Z.

The Order-to-Activate cartridges support only Z convention-based fields, except for the RequestedDeliveryDateTime field.

The RequestedDeliveryDateTime field on the ProcessSalesOrderFulfillmentEBM (incoming customer order) is mapped to the web service API's date time field for initial order creation. This field allows the use of the +/-hh:mm convention along with the Z convention.

The other Oracle AIA-relevant date and time fields that follow the Z convention are:

ActualDeliveryDateTime
ExpectedDeliveryDateTime
EarliestDeliveryDateTime
StartDateTime
EndDateTime
ServiceUsageStartDateTime
PurchaseDate
CycleStartDateTime

Order Creation in the Order-to-Activate Cartridges

In the course of processing a customer order that has been received and created by the Order-to-Activate cartridges, the following additional orders are created automatically, in this order:

CloseCreationFailedTroubleTicketOrder: An order of this type is created when the customer order is created. It determines whether there are any open trouble tickets for previous revisions of this order. If it finds any open trouble tickets for the order, it closes them. This order is then closed automatically.
ResumePendingInBoundMessage: An order of this type is created when the customer order transitions to the In Progress state. This order checks to see whether any messages are waiting for the order that might have been received when the order was temporarily in a Suspended state. If any such messages are found, they are rerouted to the normal message queue for the provisioning order. This order is then closed automatically.
CloseCreationFailedTroubleTicketOrder: Another order of this type is created when a customer order is completed successfully. It determines whether there are any open trouble tickets for the customer order (for example, if someone has recovered from fallout manually and not closed the trouble ticket manually). If it finds any open trouble tickets for the order, it closes them. This order is then closed automatically.

Order-to-Activate Emulators

Emulators are included with the Order-to-Activate cartridges. These emulators enable you to perform testing before all of the solution components are connected. An Ant build file is used to build and deploy emulators, which are enterprise applications built and deployed into WebLogic for central order management and service order management. There are different sets of emulators available with the Order-to-Activate cartridges:

The Oracle AIA emulators emulate responses from Oracle AIA when a central order management cartridge is used in a standalone (without integration with other applications) environment.
The Inventory emulators emulate responses from the Unified Order Management (UIM) software. These responses are used when service order management is used without a connection to a live UIM system for inventory requests.
The technical order management emulators emulate responses from a technical order management system, such as responses to activation commands. These responses are used when service order management is used without a connection to a live technical order management system.

About Fulfillment Topologies

A fulfillment topology defines the arrangement of various network elements, processes, systems, and software that are used to perform a complete service. The Order to Cash Integration Pack for OSM solution comes with three sample fulfillment topology definitions:

Simple fulfillment topology: This topology, available for both versions of the Order-to-Activate solution supports a single instance of each fulfillment system.
Typical fulfillment topology: This topology supports one Siebel CRM or Oracle CPQ Cloud system, three BRM system instances, and three provisioning system instances. See "Order-to-Activate Cartridge Solution Options" for more information about solution types.
Complex fulfillment topology: This topology supports multiple instances of all fulfillment systems. See "Order-to-Activate Cartridge Solution Options" for more information about solution types.

You can use the sample fulfillment topologies as examples for configuring your own topologies for providing order fulfillment services. You can build your own topologies depending on the systems and instances required. Generally your fulfillment topology includes all of the systems that participate in the order capture and order fulfillment.

OSM uses fulfillment patterns named Danube and Nile (code names for sample fulfillment patterns), for Simple and Typical topologies, respectively. These fulfillment patterns:

Match the number of fulfillment system types used in each of the fulfillment topology scenarios
Stay agnostic to the number and domain of fulfillment providers, that is, the fulfillment pattern is independent of the number of system instances participating (For instance, even if there are three billing system instances, the fulfillment pattern for each product specification remains the same)
Provide fulfillment pattern variations that collectively provide significant coverage of requirements

See OSM Concepts for more details on topologies.

Simple Fulfillment Topology

The Simple fulfillment topology uses one Siebel CRM or Oracle CPQ Cloud system, one BRM system, and one provisioning system in the process of fulfilling an order.

The sample demonstration cartridge adopts the Simple fulfillment topology and Danube fulfillment pattern in fulfilling an order. That is, in Simple fulfillment topology, the relationship between Siebel CRM or Oracle CPQ Cloud, BRM, and central order management is set to support communication using the Danube fulfillment pattern in fulfilling an order.

The Danube Fulfillment Pattern

The Danube fulfillment pattern is used with the Simple fulfillment topology in the OSM fulfillment process. Figure 1-2 illustrates a smaller portion of a sample Danube fulfillment pattern.

Figure 1-2 Danube Fulfillment Pattern

Description of "Figure 1-2 Danube Fulfillment Pattern"

The main fulfillment functions in Figure 1-2 are represented in a box and are indicated by the bold item underlined. The activity name is followed by the target fulfillment system instance in square brackets. For example, InitiateBilling[BRM-ALL].
The arrows between the fulfillment functions and the fulfillment pattern represent the dependency for starting the activity at the arrowhead end on the indicated milestone. For example, COMPLETED.

Note:

Milestones track the progress of the order fulfillment process. You can configure the milestones for each fulfillment pattern in various topologies. OSM sends the status updates to Siebel CRM or Oracle CPQ Cloud that include the details of the last reached milestone for each order line item.
Dependencies are established at the order line level. For readability purposes, Figure 1-2 combines all dependencies between two order components into a single arrow.
SyncCustomer is sensitive to only the Add(A), Update(U), and Move-Add (MA) fulfillment functions.
Note:

Each customer order line in the incoming customer order has an action code. Some fulfillment functions process order lines only with specific action codes.

For example, SyncCustomer processes UPDATE order lines only when there are significant updates (certain fields have updated values). The following are some of the action codes:
- Add: Adds a new instance
- Update: Updates the current instance with the revised details
- Move-Add: Adds a new instance after moving existing customer details to a new location. For example, you can add a new service to an existing customer after moving its details.
- Delete: Deletes the current instance
- Resume: Resumes the current instance
- Suspend: Suspends the current instance
- Move-Delete: Deletes an instance as part of moving the existing customer details.
The relevant order line item actions indicated in Figure 1-2 are a property of the fulfillment function and not the fulfillment pattern.

Typical and Complex Fulfillment Topologies

The Typical fulfillment topology uses one Siebel CRM or Oracle CPQ Cloud system, three BRM system instances, and three provisioning system instances in the process of fulfilling an order.

The Complex fulfillment topology allows for multiple instances of any external system.

To fulfill an order in a Typical fulfillment topology, the Nile fulfillment pattern is used.

The Complex topology is similar to the Typical topology, and has one or more instance of each type of external system, depending on options selected while installing the Order-to-Activate cartridges.

The Nile Fulfillment Pattern

The Nile fulfillment pattern is used with the Typical and Complex fulfillment topologies in the OSM fulfillment process. The exact systems included depend on the options selected when installing the Order-to-Activate cartridges. Figure 1-3 depicts a smaller portion of the actual fulfillment pattern for the Typical topology.

Figure 1-3 Nile Fulfillment Pattern

Description of "Figure 1-3 Nile Fulfillment Pattern"

The main fulfillment functions in Figure 1-3 are represented in a box and are indicated by the bold item underlined. The activity name is followed by the target fulfillment system instance in brackets. For example, SyncCustomer[BRM-REZBDB].
The arrows between the fulfillment functions and the fulfillment pattern represent the dependency for starting the activity at the arrowhead end on the indicated milestone. For example, COMPLETED.
Dependencies are established at the order line item level. For readability purposes, Figure 1-3 combines all dependencies between two order components into a single arrow.
Service Bundle (FulfillBilling processing granularity) is set to WholeItem FulfillBilling and OSM produces a single invocation in this case.
SyncCustomer accepts all line items, and ProvisionOrder accepts all line items except billing-only line items.
SyncCustomer is sensitive to only the Add(A), Update(U), and Move-Add(MA) fulfillment functions.
The relevant order line actions indicated in Figure 1-3 are a property of the fulfillment function and not the fulfillment pattern.
For Initiate - Fulfill billing fulfillment patterns, OSM fulfillment patterns are required to compute the new and prior values for the Start Cycle Date, Start Usage Date, and Purchase Date.