Skip Headers
Oracle® Communications Order and Service Management Developer's Guide
Release 7.2.2

Go to Documentation Home
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

2 Planning and Designing the OSM Implementation

This chapter provides an overview of planning and design considerations for your Oracle Communications Order and Service Management (OSM) implementation.

Planning the Solution

Before you model your order fulfillment process, you must complete a planning phase, in which you analyze your business and system requirements. These requirements may include systems outside OSM, in order to ensure that the solution works as a complete system. The results of this analysis help you determine how to model your order processing.

This phase can include the following:

Integration Design

Every order management implementation involves integration between multiple systems as a part of the end-to-end fulfillment lifecycle. To plan how to integrate OSM with external systems, do the following:

Configuration Design

Table 2-1 lists the considerations you must take into account, and the entities and configurations you use to implement them in Oracle Communications Design Studio.

Table 2-1 Order Processing Considerations and Related Metadata Elements in OSM

Question Metadata Element

What are the data elements related to the incoming order?

What additional data is generated by the applications that are a part of the fulfillment process; for example, billing data?

What are the data elements needed by individual tasks?

Data dictionary

How is the order data organized?

How will the order be displayed to your order management personnel?

Order template and Behaviors

How will the incoming order format be recognized?

Order recognition rules

How can I validate specific content on the incoming order data?

Order recognition rule and Validation X-Query

How will OSM identify and understand the structure of the individual line items on the order?

Order item specifications

How will OSM determine the fulfillment actions that need to be performed for line items on the order?

Product specifications

How will OSM recognize which set of fulfillment actions need to be performed for an order?

Fulfillment modes

What are the fulfillment actions involved in the processing? Fulfillment actions include actions such as delivering a service, canceling a service, and qualifying a service.

Order component specifications - Fulfillment actions

Which systems are involved in the fulfillment life cycle?

Order component specifications - Fulfillment target systems

What is the processing granularity for each target fulfillment system? For example, is it:

  • One line item per request.

  • Bundle of line items per request.

Order component specifications - processing granularity

How will the order fulfillment actions be realized? Does the action need to be manual or can it be automated?

Processes and tasks

What are the steps in decomposing the sales order into a set of fulfillment requests to be executed by the different fulfillment systems?

Orchestration stages

What is the sequence in which the decomposition should happen?

Orchestration sequences

What are the teams and groups of people involved in executing the fulfillment actions?

Roles (called Workgroups in the Administrator application)

What are the policies that control the execution of the order, concerning which items can be modified, and when, and who is authorized to make modifications.

Order lifecycle policies

Is there a specific order in which the fulfillment actions must be performed?


Is there a stage in processing beyond which no revision to an in-flight order can be allowed?

Point of no return

What actions need to be performed when an in-flight order is revised?

Compensation configuration

How will external systems be notified of status changes or order data changes in OSM?

How will OSM order processing personnel be notified if an order is in jeopardy.


What are the key data elements of the order that need to be tracked? Changes to these data elements might need to be communicated to external systems.

Order Data Changed Notifications. Line item data fields returned from fulfillment, status and milestones on the order data

How can I customize the appearance and functionality of the Task Web client?

How will data be validated?

Behaviors (called View Rules in previous releases)

How will OSM integrate with external applications to exchange data and invoke commands to execute the fulfillment actions?

Automation plug-ins

Cartridge Packaging Design

When you model OSM entities, you can define separate cartridges and combine them in a single solution. This allows you to create individual cartridges for specific purposes, and to create a library of cartridges which can be shared across multiple solutions. This approach can result in lower maintenance, better performance, and easier collaboration within the implementation team.

While each deployment has its own specific considerations, Oracle recommends that you consider the following guidelines:

Status Update Design

Status values for an order item and for the whole order often need to be sent to the upstream system that submitted the original request. There are a number of ways to achieve this.

Status Update Strategies

  • Use an event notification triggered by a change to order data, or when an order reaches an order milestone; for example, completed. The notification runs an automation plug-in that sends a status message to the upstream system. The automation plug-in should have all of the values for status data defined in its view, in order to calculate an aggregated status value.

    Be aware that there can be race conditions if multiple status updates are executed in parallel. Since each update is taking a snapshot at a particular moment, it is possible that none of the status updates will have a snapshot that includes all of the final values. This strategy is better used when there are no multiple concurrent status updates.

  • Configure an automation to generate a status message whenever the order changes state. Because order state changes are generally less frequent than data changes, this may be a higher performance option.

  • It is possible to configure status update functions as order components and make them first-class members of the orchestration plan. However, it is not desirable to do this in most circumstances, because this can quickly lead to a large increase in the number of tasks in the cartridge. If used, this option will only work if status updates are only sent at a specific point in the orchestration plan, for example as the last function after provisioning and billing.

Completing an Automation Task That Handles Concurrent Status Updates

An automated task can process multiple responses from external systems. For example, an activation task might receive the status for each service on the activation request. The activation task needs this information to determine when the activation has been completed by the external system, at which point the task can transition to the Completed state.

  • The external system can include data that indicates that all of the requests have been completed. Typically, this is a message indicating that the response is the last response, and there will be no further messages.

  • If the external system cannot report that the last request has been processed, the automation task must ensure that a response has been received for each request sent to the external system.

When OSM must determine the last response, there are special considerations for concurrent status updates. If the automated task needs to track the status of all responses, and multiple responses are processed concurrently, the automation receiver instances executing concurrently do not have visibility to status updates from the other receivers. The receiver may never execute with the task data that contains all status updates and so never encounters a condition where it can complete the task.

This situation can be handled by configuring an automated notification plug-in that monitors the status fields and creates a notification whenever the data changes.

Figure 2-1 Sequence Diagram for Concurrent Status Update Notification Process

Sequence diagram depicting the flow described in the text.

The notification plug-in is triggered every time the status field is updated by the automation receiver. The notification plug-in executes in a separate transaction after each receiver update, and can check the status responses to determine if all responses have been received for each action request. When all responses are received, the notification plug-in can generate a message to trigger an automation receiver. This receiver is correlated to the original sender by means of an ID set by the sender specifically for tracking the status updates. The receiver is then run with the task data that contains all of the status responses and it can complete the task.

Organizing Design Studio and Naming Conventions

Oracle recommends that you determine a set of naming conventions for the Design Studio entities being created and a directory structure to contain those elements that is appropriate to your implementation. Following is an example set of naming conventions for selected configuration elements within Design Studio. However, each project team should determine what conventions are suitable for a particular project.

Table 2-2 Suggested Design Studio Naming Conventions

Metadata Element Naming Convention Sample

Order recognition rules

Use the convention of OrderTypeORR



Order item specifications

Use the convention of OrderItemTypeItemSpec


Product specifications

Use a name that indicates the fulfillment flow being supported.

For example: PS_FulfillmentType_SpecType


Fulfillment modes

Use names that clearly identify the type of action to be taken




Order component specifications: Fulfillment actions

Use names that indicate the function of the fulfillment action; for example, Billing, or Shipping.




Order component specifications: Fulfillment target systems

Use names that indicate the function of the target system; for example, Billing, or Shipping.




Order component specifications: Processing Granularity

Use names that correspond to the order structure defined in the product catalog; for example, Item, Bundle, and Order.




Orchestration stages

Use names that describe the stages.




Orchestration sequences

Use the convention CartridgeNameSequence


Decomposition rules

Use the naming convention DR_FunctionName_To_SystemName for system decomposition rules

Use the naming convention DR_DetermineGranularity_For_FunctionName for granularity decomposition rules