Modeling Milestone Events

17 Modeling Milestone Events

This chapter describes how to model milestone events in an Oracle Communications Order and Service Management (OSM) solution.

Before reading this chapter, read the following to learn about general OSM concepts:

See the following topics for details about Model-driven Milestones:

About Milestones and Model-driven Milestones

For order fulfillment, milestone represents an achievement of the process being reached. While an order state mainly represents the fixed operation state of the order such as in-progress, completed, cancelled, amending and so on, it does not represent the complexity and the variation of order fulfillment in different business domains. OSM uses fulfillment states that provide flexible modeling to define the order fulfillment achievement for a domain. Fulfillment state is a mechanical evaluation of the order fulfillment process as it relates to an order item or to the whole order.

Model-driven Milestone considers a specific fulfillment state for a specific order item or order, or the external fulfillment state that triggers the fulfillment state evaluation to declare that as a business-specific checkpoint being reached during order fulfillment. Milestones have meaning to the overall solution as they provide a progress report on an order that is consumable by human users and external systems. Milestones are propagated from downstream system, when an order item reaches PONR or a specific fulfillment state, or when a whole order reaches a specific fulfillment state.

Figure 17-1 illustrates an example of a sequence of five milestones propagated from OSM COM to an upstream system (CRM).

Figure 17-1 Milestone Interaction

Description of "Figure 17-1 Milestone Interaction"

Usage of Milestone Events

Milestone propagation from OSM to upstream system allows upstream systems (such as a CRM system) to keep track of the order fulfillment progress. The current milestone of a fulfillment order may trigger interaction between an upstream system and other edge systems or customer interaction. Upstream systems also rely on milestones to decide the type of orchestration action that can be submitted to alter the orchestration process. These orchestration actions include cancel order, amendment order and follow-on order.

For example, when an upstream system is required to amend an in-progress order fulfillment, the milestone will be used to decide whether an in-flight amendment should be sent (if PONR is not reached) or a follow-on order should be sent (if PONR is reached). For cancelling, the same PONR milestone may be used to decide whether an in-flight cancel order should be sent (if PONR is not reached) or a disconnect order is needed (if PONR is reached). The upstream system creates a new version of assets after receiving a milestone with details of the product which may also be enriched with network resource.

Without Model Driven Milestones, the milestone declaration, detection and propagation have to be implemented by cartridge code, which runs within the automation plugin. For example, the receiver plugin needs to check the response data from the downstream system to scan for an expected external fulfillment state value. Such external fulfillment state value may be hard coded or stored in a freeform metadata outside of OSM. The detected milestone is then sent to the upstream system by the same automation plugin that processes the response message. The implementation of detection and propagation is usually added on top or combined with the normal processing logic of the automation plugin, resulting in a more complicated code.

Note:

Message propagation should always be executed in the same transaction of the automation plugin so the current order data reflects the snapshot of this time. Using the data changed or the notification event that is executed in a new transaction is not recommended, since additional data may be updated by the other transaction that is committed prior to the new transaction.

Model-Driven Milestones provide the following:

A design-time milestone declaration
A design-time milestone detection
A design-time milestone propagation and configuration

This allows all implementation related to the milestone activities to be excluded from the automation plugin. If an existing milestone defined is not valid for a new order fulfillment pattern, then disabling, removing or updating the configuration of the milestone can be managed efficiently.

Modeling Model-driven Milestones

A model driven milestone configuration consists of:

Milestone detection
Order data associated with the milestone
Message routing configuration

Milestone Detection

For milestone detection, OSM uses the external fulfillment state, order item fulfillment state, order fulfillment state and order item PONR as the valid data element to trigger the milestone. If update to the state mentioned early and the value matches the configuration, then the milestone propagation process is triggered.

For example, consider automation plugin updating an external fulfillment state value as "Provision Design" with the following path:

/ControlData/Functions/ProvisionOrderFunction/orderItem/ExternalFulfillmentState

Milestone propagation is triggered if model-driven milestone is defined for the following:

For external fulfillment state with Provision Design" and for fulfillment function with "ProvisionOrderFunction".
For fulfillment state with "Design" for order Item under fulfillment function with "ProvisionOrderFunction", and the external fulfillment state map with "Provision Design" to fulfillment state with "Design".
For order item PONR for fulfillment pattern which invokes fulfillment function "ProvisionOrderFunction", the PONR is reached and fulfillment state "Design" is reached.

Order data associated with the milestone

The milestone propagation process creates a payload that describes the details of the milestone. The content is driven by the order data. To support that, the configuration for the second item consists of an xquery or xslt script, which is executed by the milestone propagation process with the order data supplied by an order view. The xquery or xlst script is responsible to create the data payload sent to an upstream system. The implementation details of the xquery or xlst script are the same as automation. For more details, see the "Using Automation" section in the OSM Developer's Guide.

Message routing configuration

Message routing configuration contains the target system's JMS queue name. The milestone propagation process delivers the milestone message into this JMS queue.