Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

E35415-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

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

6 About OSM Order Life-Cycle Management

This chapter describes how to use minimum processing duration, life-cycle policies, and order events to manage the life cycle of Oracle Communications Order and Service Management (OSM) orders.

Before reading this chapter, read "Order and Service Management Overview" to learn about basic OSM concepts.

About Managing the Order Life Cycle

The order life cycle controls when the order starts, and how the order transitions between order states; for example, the conditions that allow an order to be amended.

To manage the order life cycle, you can do the following:

About OSM Order Fulfillment Timeline

OSM can process orders at different times. In many cases, a customer wants an order to be completed as soon as possible, in which case OSM can start processing the order immediately. However, in some cases, the start date of an order should be delayed until a future date. For example:

In addition, there may be groups of order items within an order that need to be fulfilled at different times. For example, an order might contain three services, such as internet, IPTV, and VoIP. The internet and IPTV services might have an immediate requested delivery date, but the VoIP service might only be required at the end of the month, after the customer's current phone service plan has expired. In this case, you can enable OSM to calculate a time to start fulfilling the VoIP service at a future date that would allow the service to be activated by the requested delivery date: at the end of the month. For more information about enabling calculated start dates, see "About Calculated Order Component Start Dates".

Different groups of order items may have orchestration dependencies configured that have an impact on when a service gets fulfilled. For example, the internet service might be required before you can activate an IPTV or VoIP service. These dependency scenarios are fixed and take precedence over honoring requested delivery dates. In other words, OSM will only honor a requested delivery date for a service if there is enough time to fulfill that service given the time it takes to perform the fulfillment tasks and any dependencies that might exist between one service and another. In such a scenario, the order completion date will be later than the delivery date requested by the customer.

To accurately calculate when an order should start so that it can meet a requested delivery date, you must determine how long it takes to perform certain tasks contained in the order and you must know when a customer wants a service.

Important:

Orders must have an orchestration plan to be able to calculate the order completion date.

When viewing an entire order in the Order Management Web client Summary tab General area, you see the following fields:

These fields are used in, or derived from, an orchestration plan algorithm. This algorithm, at its highest level, uses the Order Creation Date (for orders that start immediately) or the Expected Order Start Date (for future dated orders) in conjunction with the Expected Order Duration to determine whether there is enough time to achieve the Requested Order Delivery date. If there is enough time, then the Expected Order Completion Date is the same date as the Requested Order Delivery Date. If there is not enough time, then the Expected Order Completion Date is later than the Requested Order Delivery Date.

When viewing a specific order item in the Order Management Web client Summary tab General area, you see the following fields:

The following sections describe the design-time and run-time elements that you must model so that the orchestration plan algorithm can generate an order fulfillment timeline.

About Order Item Requested Delivery Date and Order Components

The following sections describe order item requested delivery dates and aspects of order components that relate to how OSM attempts to honor these requested delivery dates.

How OSM Decomposes and Processes Order Items in Order Components

OSM calculates the order component start dates based on the requested delivery date for order line items in customer orders. This requested delivery date order line item value must be mapped to an order item specification requestedDeliveryDate order item property in Oracle Communications Design Studio.

You can model the decomposition of order items into order components that typically share the same function, are destined for the same fulfillment system, and share the same processing granularity. The entity that ultimately processes order items is an executable order component that is linked to a process that contains a sequence of manual and automated tasks that fulfill every order item in the order component.

For example, a group of six order items might be gathered in an executable component that is linked to a process that contains an automated task that generates and sends a service request to an activation system. The service request that the automated task builds would contain all the information from the six order items that the activation system requires to activate services that correspond to the order items in the network.

When OSM has determined the order component start date, all order items in the order component begin processing immediately (regardless of their requested delivery date). Although this can mean that some order items might be delivered early, it ensures that no order items are delivered late.

About Grouping Order Items in Order Components by Date Range

If order items belong to the same function and go to the same fulfillment system need to be fulfilled on substantially different dates, you can model different order components in Design Studio that execute at different stages or within the same stage, but that have different start dates.

In addition, OSM provides Java functions that can be used along with order item hierarchies to further delineate and group order component IDs based on order item requested delivery date. For more information about creating custom component IDs using Java function, see "About Component Specification Custom Component IDs XQuery Expressions".

Modeling Order Component Minimum Processing Duration

When you model orders in Design Studio, you need to provide OSM with enough information to be able to meet the order item requested delivery dates with as much accuracy as possible. To do so, you specify a minimum processing duration value that defines how long it typically takes to fulfill all order item within an executable order component. You can model this value at the order component level (see Figure 6-1) or at the product specification order component level (see Figure 6-2). OSM always uses the larger of the two values. This duration should take into account the total duration of any manual or automated tasks involved in completing the process. For example, if you know that it takes one week to ship a telephone, you specify one week for the minimum processing duration for an order component that is used for shipping a telephone.

You can specify a different minimum processing duration for each fulfillment mode in the product specification. For example, the Deliver fulfillment mode can have a different duration than the Cancel fulfillment mode.

Figure 6-1 shows the duration defined for an order component.

Figure 6-1 Processing Duration Defined for an Order Component

Shows duration defined for an order component

Figure 6-2 shows the processing duration assigned to an order component when it is used in a product specification Order Components tab, Selected Order Components sub-tab.

Note:

The Duration tab displayed beside the Order Components tab and Dependencies tab in Figure 6-2 is no longer used. This tab still appears in Design Studio to support OSM cartridges that target pre-OSM 7.2.2 servers.

Figure 6-2 Processing Duration Defined for an Order Component as Used in a Product Specification

Graphic is described in surrounding text.

The minimum processing duration of an order may vary greatly depending on a number of factors:

  • The kinds of products or services. Orders for mobile services typically have a very short processing duration, whereas a complex business-to-business order might take weeks.

  • What must be done to fulfill the actions on the product or service, such as shipping or installation work.

  • Any dependencies within and between the products and services. For example, PSTN provisioning must complete before ADSL provisioning starts.

Because a single order can have multiple values for the minimum processing duration, defined in multiple order components and at the order level, OSM compares all of them (if they are defined) to find the longest processing duration for the order:

  1. OSM compares the two possible values of the minimum duration for an order component:

    • The duration specified in the order component itself.

    • The duration assigned to the order component in its product specification.

    OSM uses the larger of the two values as the order component minimum processing duration.

  2. OSM adds the calculated durations for all of the order components in the order. OSM takes into consideration dependencies between order components. For example, if the order component that provisions a service depends on the order component that processes billing, the minimum processing duration for both components must be used.

  3. OSM calculates the order duration based on the expected order completion date minus the start date.

About Minimum Processing Duration Inheritance in Product Specifications

For the minimum processing duration that is assigned to an order component by a product specification, the minimum processing duration for the order component is inherited in product specifications extended from the parent product specification. For example:

  1. In the BaseProductSpec product specification, the BillingFunction order component is assigned a duration of 2 days.

  2. The Service.Fixed product specification is extended from the BaseProductSpec product specification. Therefore, if you do not specify a duration for the BillingFunction order component in the Service.Fixed product specification, it inherits the duration of 2 days from the BaseProductSpec product specification.

Figure 6-3 shows how the duration is inherited from a parent product specification.

Figure 6-3 Minimum Processing Duration for an Order Component Inherited in a Product Specification

Graphic is described in surrounding text.

About Minimum Processing Duration Expressions

In addition to specifying a fixed amount of time as the duration, you can use an XQuery expression. The following expression returns a duration of three hours:

PT3H0M0S

You typically use a duration expression if you have an external system that keeps track of processing duration and the load levels of systems. You can write a duration expression that uses this information dynamically. For example, the calculation can take into account peek activity periods.

Calculating the Earliest Order Component Start Date (Order Start Date)

The first order component to start processing can contain one or more order items. OSM uses the order item with the earliest requested delivery date to calculate the order component start date. If there were only one level of order component decomposition in the orchestration plan and there were no dependencies between order components, OSM would calculate the order component start date by taking the earliest order item requested delivery date and subtracting the configured minimum processing duration for the order component. This calculated start date would also be the order start date.

In the scenario, the following order component start dates are possible:

  • If the component start date (also the order start date) is in the future, OSM does not start the order component until the future date. In the Order Management Web client, you would see:

    • The expected order start date would be later than the order creation date.

    • The order component Expected Start Date would be the same as the expected order start date.

    • The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.

    • The expected order completion date and the requested order delivery date would be identical.

  • If the component start date is in the past, OSM starts the order immediately. In the Order Management Web client, you would see:

    • The order component Expected Start Date would be the same as the expected order start date.

    • The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.

    • The requested order completion date would be before the expected order delivery date.

  • If no minimum processing duration was configured for the order component, then the order component would start on the same day as the requested delivery date, assuming that day was a future date. In the Order Management Web client, you would see:

    • The expected order start date would be later than the order creation date.

    • The order component Expected Start Date would be the same as the expected order start date.

    • The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.

    • The requested order completion date would be on the same date as the expected order delivery date.

  • If the order item contained no value for the requested delivery date property, then OSM starts the order immediately.

About Calculated Order Component Start Dates

The first order component in an order and any initial order component that does not depend on another order component always uses a calculated start date based on order item requested delivery date values. If the order items do not have values for the requested delivery date, then the order begins processing immediately.

Dependent order items start in the following ways:

  • Any dependent order components start immediately after the first or initial order component completes and all dependencies are resolved. This is the default behavior for order components.

  • You can enable calculated start dates for dependent order components by selecting the Use Calculated Start Date check box in the Order Component Specification (see Figure 6-4). Dependent order components use the calculated start date based on the earliest order item requested delivery date in the order component, minus the order component duration. See "Modeling Order Component Dependencies and Requested Delivery Dates"for more information about configuring dependent order component calculated start dates.

    Figure 6-4 Enabling Order Component Calculated Start Dates

    Surrounding text describes Figure 6-4 .

    For a three stage orchestration cartridge with function, system, and granularity components, you can enable calculated start dates at the function level if you wanted all components related to that function to use a calculated start date. Or you can enable calculated start dates at the system level. In this second scenario, one function might decompose to more than one system level component and a calculated start date might only be required for one of them.

Modeling Order Component Dependencies and Requested Delivery Dates

An OSM orchestration cartridge can have several order components with dependencies configured between them. OSM always honors any order component dependency wait condition before starting a new order component. You can configure dependent order components to start immediately after the blocking order component is complete and all dependencies have been met, or you can use the calculated start date. See "About Calculated Order Component Start Dates" for more information.

This scenario assumes that the dependency between the order component order items are between different order items. For example, order item 1 is only processed by order component A (the blocking order component) and order item 2, which is dependent on order item 1, is only processed by order component B (the waiting order component).

The following dependent calculated order component start date scenarios are possible:

  • If the component start date is in the future, and the blocking order component is complete with all dependencies met, then OSM does not start the order component until the calculated start date arrives.

  • If the component start date is calculated to a date before the blocking order component is complete and all blocking order component dependencies are met, then OSM ignores the calculated start date. The order component begins immediately after the blocking order component completes and all dependencies are resolved.

  • If the order item contained no value for the requested delivery date parameter, then OSM starts the order immediately.

Modeling Order Items Processed by Multiple Dependent Order Components

If OSM processes an order item in more than one executable order component, and there is a dependency between these executable order components, then OSM calculates the order component start dates for the first order component by subtracting the duration from the longest chain of order component durations involved in processing the order item from the earliest order item requested delivery date. This ensures that all order components can be delivered by the requested delivery date. All dependent order components in this scenario would start immediately after the previous order component was resolved. For example, if order item 1 is processed by order component A, B, and C, and B and C depend on A, then the order component start date for A would be the requested delivery date for order item 1 minus the duration of either order components B or C (whichever was longer) and A. Or, if B was dependent on A, and C was dependent on B, then OSM would subtract the total duration of A, B, and C from the requested order delivery date of order item 1 to determine the start date for order component A.

Revisions of Future-Dated Orders

You can submit revision orders to future-dated orders. The revision order can have a different requested delivery date than the base order or the same requested delivery date. In either case, OSM re-calculates the start date for the revision order based on its requested delivery date and on the minimum processing durations of the revised order components.

Note:

Future-dated orders that cancel a future-dated base order are special cases. In this situation, the base order is canceled immediately, regardless of the requested delivery dates.

You can submit a future-dated revision order for an order that has already started processing. Only order components that have not started can have new calculated start dates applied. The new requested delivery date will trigger a compensation only if the order item specification requestedDeliveryDate order item property is marked as significant. Any task compensation required (for example, in previous completed order components) also happens immediately.

As a result of changing a significant order item requested delivery date, OSM calculates a new orchestration plan. Order components that have compensation tasks set with undo, redo, or amenddo compensation strategies are executed based on the dependency graph of the revised base order orchestration plan. The order item requested delivery date modification may change the calculated start date of the order component that is processing the order item and, by extension, may also change the expected order completion date.

Examples of Calculating the Expected Start Date

The following examples show scenarios for calculating the expected start date for an order and order components.

Example 1: Calculating Start Dates for Order Components with No Dependencies

In this example:

  • A billing function order component has a duration of 2 days and processes order item 1 with a requested delivery date of January 3rd.

  • A provisioning function order component has a duration of 3 days and processes order item 2 with a requested delivery date of January 5th.

  • There are no dependencies between order components.

The start date for each order component is calculated as follows:

  1. The calculated start date for the Billing order component is calculated using the following logic:

    • Order item 1 requested delivery date January 3th

    • Minus Billing order component duration 2 days

    • The Billing order component start date is January 1st.

    Because there are no dependencies between the order components, OSM calculates the start date for each order component separately.

  2. The calculated start date for the Provisioning order component is calculated using the following logic:

    • Order item 1 requested delivery date January 5th

    • Minus Provisioning order component duration 3 days

    • The Provisioning order component start date is January 2nd.

Example 2: Calculating Start Dates for Order Components with Dependencies

OSM always uses the final set of order components for in an orchestration plan to determine the start date for the order component. A final order component has no successor order components. For example, Figure 6-5 shows the order component processing flow for three order items. Order components C and E are final order components.

Figure 6-5 Order Component and Order Item Processing Flow

Surrounding text describes Figure 6-5 .

OSM calculates start dates for each order component starting with the requested delivery date of the final order components minus the order duration and any dependency condition wait delay duration. In this example:

  • Order component C processes order item 1 and 2. Order item 1 has a requested delivery date of January 8, while order item 2 has a requested delivery date of January 10. OSM always uses the earliest requested delivery date to calculate the start date for the order component, which means the January 8 date is used. Because order component C is configured with a duration of 2 days, then order component C starts on January 6th.

  • Order component E processes order item 3 that has a requested delivery date of January 18. Because order component E is configured with a duration of 2 days, then order component E would start on January 16th.

OSM calculates the start date of order component B by subtracting the configured duration for order component B (2 days) minus the start date for order component C (January 6th) resulting in a start date for order component B of January 4th.

OSM uses order component C instead of order component E to calculate the start date for order component B because order component C is a final order component with an order item that has the earliest requested delivery date. OSM does this to ensure that all order items being processed by an order component are not started late, even though they may start early. In other words, those order items being processed in order component B complete earlier than order component E needs them, but those order items destined for order component C complete with sufficient time for order component C to meet order item 1's requested delivery date of January 8th.

Finally, OSM calculates the start dates for order components A and D. Order component A has a configured duration of 3 days minus the start date for order component B (January 4th) resulting in a start date of January 1st. Order component D has a configured duration of 2 days resulting in a start date of January 2nd.

The order start date is the earliest of all starting order components. In this example, the earliest order component start date is January 1st for order component A.

About Managing Order States and Transitions

Every order has an order state, which indicates the current condition of the order; for example, In Progress, Amending, or Completed. These OSM order states control the progress of the order. For example, an OSM user cannot work on tasks while the order is in the Suspended state, and an order in the Aborted state cannot be restarted.

Note:

The order state represents the technical processing state of the order in the OSM system, not the state of the order as defined in a CRM system, or the fulfillment state defined in a fulfillment system. OSM order states are typically not equivalent to the states of the order in the CRM system or other order-source system, which might have different states for the customer order, as well as states for order line items on the order.

A typical order uses the following states:

  1. An order is created in the Not Started state.

  2. When processing begins on the order, the state transitions to the In Progress state.

  3. When the order is complete, it transitions to the Completed state.

Changes from one order state to another order state are called transitions. Each order state has a set of allowable transitions. For example, when an order is completed, it transitions from the In Progress state to the Completed state.

Transitions are controlled by transactions. A transaction is an action taken by the OSM system. For example, the Suspend Order transaction performs the following actions:

Most transactions perform transitions that change the state of the order. However, some transactions do not perform a transition to another state. For example, the Update Order transaction can make changes to an order without changing the order's state.

About Modeling Life-Cycle Policies

You can customize how an order transitions from one state to another by customizing the order's life-cycle policy. Every order type that you model must be associated with an order life-cycle policy. Customizing an order life-cycle 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. See "About Modeling Transition Conditions" for more information.

  • You can specify a grace period that allows the order to complete processing tasks before transitioning to another order state. See "About Modeling Transition Grace Periods" for more information.

  • You can specify the roles that are allowed to perform a transaction. See "About Modeling Transition Permissions" for more information.

  • You can specify the error message and severity if a transition condition is not met. See Design Studio online Help.

OSM allows any number of order life-cycle 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.

About Modeling Transition Conditions

Transition conditions are Boolean expressions that specify if a transition from one state to another is allowed. For example, for the Submit Amendment state, you can prevent the Process Amendment transition from occurring until a condition is true.

Figure 6-6 shows the life-cycle policy for the Process Amendment transition. In this case, it returns true, so it is always allowed to transition.

Figure 6-6 Order Life-Cycle Policy for the Process Amendment Transition

Graphic is described in surrounding text.

A common scenario for configuring permissions is when you set the point of no return for amendment processing. See "About Point of No Return" for more information.

When specifying conditions, the minimum set of required order states is Not Started, In Progress, and Completed. The life cycle must allow an order to transition to those states.

OSM uses more transactions than those shown in Design Studio. Design Studio shows only the transactions that you can assign permissions on and set conditions for. For example, the Complete Task transaction can transition an order to the Completed state, but that transaction cannot be customized.

About Modeling Transition Grace Periods

The transition grace period specifies the amount of time that OSM should wait before transitioning the order. For example, if a Suspend Order transaction is run on an In Progress order, a grace period can allow the order processing to reach a definitive state for all currently executing tasks before transitioning to the Suspended state. In this case, OSM waits until all active tasks are in the Received, Completed, or user-defined Suspended task state. (An active task is a task that is in the Accepted state.) If the grace period expires before all tasks move out of the Accepted task state, OSM transitions the order state.

During the grace period, the target order state header in the Task Web client displays the order state the order is transitioning to. The target order state is populated only when an order is in grace period. Figure 6-7 shows the target order displayed in the Task Web client.

Figure 6-7 Target Order Displayed in the Task Web Client

Shows target order displayed in task web client.

You can specify a grace period for certain transactions, such as Suspend Order, Process Amendment, Cancel Order, and Fail Order. For other transactions, a grace period is unnecessary or not permitted, such as for Submit Amendment, Update Order, and Abort Order.

You can define the following grace period parameters:

  • The length of time to wait (minimum and maximum, or indefinite)

  • How often to generate a jeopardy event during the grace period

Figure 6-8 shows how you can customize the order life cycle in Design Studio. In this figure, the Cancel Order exit transaction for the In Progress order state is selected. A grace period for transitioning to an order cancellation is set for a minimum of one day, and a maximum of five days. A jeopardy event is triggered every hour.

Figure 6-8 Order Life Cycle in Design Studio

Shows order life cycle in Design Studio.

About Modeling Transition Permissions

You can specify the roles that are allowed to perform a transaction. For example, while an order is in the In Progress state, your customer service role might need to perform the Update Order and Cancel Order transactions, whereas your fallout specialist role might perform only the Raise Exception transaction.

Figure 6-9 shows life-cycle permissions configured in Design Studio.

Figure 6-9 Life-Cycle Permissions

Shows life cycle permissions in Design Studio.

OSM Order States and Transactions

OSM includes a standard set of order states and transactions. You cannot add states or transactions, but you can control how the order transitions between states.

Table 6-1 shows the OSM order states.

Table 6-1 Order States

Order State Description

Aborted

The order has been permanently stopped. This is a final state. An order in the aborted state cannot transition to another order state.

See "About the Aborted Order State" for more information.

Amending

The order is being amended. OSM identifies which tasks are affected by the amended data and compensates the order as necessary.

See "About the Amending Order State" for more information.

Cancelled

The order has been canceled. All tasks have been undone back to the creation task.

If an order includes an orchestration plan, the Cancelled state is the final state. The order cannot be resumed.

If the order does not have an orchestration plan, the canceled order is returned to the creation task for the order. The order can be re-submitted to be run again.

See "About the Cancelled Order State" for more information.

Cancelling

The order is being canceled. At least one task is running to perform amendment processing for the cancellation. While the order is in the Cancelling state, OSM undoes all completed tasks to return the order to the creation task. When OSM is finished, the order transitions to the Cancelled state

See "About the Cancelling Order State" for more information.

Completed

The order has been fulfilled. There are no tasks running and processing is complete. This is a final state. An order in the Completed state cannot transition to another order state.

See "About the Completed Order State" for more information.

Failed

The order has failed during processing. The Failed state is not a final state; the order can be resumed when the problem is fixed.

See "About the Failed Order State" for more information.

In Progress

The order is actively running. Future-dated orders have an In Progress state while they wait for dependencies to be resolved.

See "About the In Progress Order State" for more information.

Not Started

The order has been created but has not started. There are no tasks running.

See "About the Not Started Order State" for more information.

Suspended

The order has been suspended and all processing on the order in OSM has been halted. No task can be updated or transitioned while the order is in this state.

See "About the Suspended Order State" for more information.

Waiting for Revision

The order is waiting for a revision. This state is common following compensation to an order for fallout, when the order is awaiting a revision from the order-source system to correct something that caused a failure in the originally submitted order.

See "About the Waiting for Revision Order State" for more information.


Table 6-2 shows transactions that are included in the order life-cycle policy and the operations they perform.

Table 6-2 Order State Transactions

Transaction Description

Abort Order

Immediately and permanently stops order processing. Transitions the order state to Aborted.

In the Order Management Web client and the Task Web client, Abort Order transactions are identified as "Terminate Order".

Cancel Order

Transitions the order to the Cancelling state. After OSM performs the necessary tasks to cancel the order, the order transitions to the Cancelled state.

In Design Studio, you can specify a grace period to wait for all accepted tasks to complete before transitioning the order.

Complete Task

Completes a task and allows the transition to the next task. Completing the last active task implicitly transitions the order to a Completed state.

This transaction is not configurable in the life-cycle policy.

Copy Order

Copies an order; for example, when you create an order in the Task Web client by copying an order. This transaction does not change the order state. It is not configurable.

Create Order

Creates an instance of an order.

The transaction starts the order in either the Not Started state or the In Progress state.

This transaction is not a configurable transaction in the OSM life-cycle policy. Permissions for creating an order are not set in the life-cycle policy. Instead you assign an order creation permission to roles and assign permissions on the orders.

Delete Order

Removes an order from the system.

To delete orders, use the orderPurge command. See OSM System Administrator's Guide for more information. If the order does not have an orchestration plan, you can delete an order using the Task Web client when the order is at the creation task.

Fail Order

Transitions the order to the Failed state. Processing on the order is stopped.

In Design Studio, you can specify a grace period to wait for all accepted tasks to complete before transitioning the order.

Fallout Order

Compensates an existing order based on error data identified during provisioning.

This transaction is not configurable in the life-cycle policy.

Manage Order Fallout

Transitions the order to the state it had before it failed. Processing on the order resumes.

This transaction enables Task Web client users to locate orders with errors that require manual intervention, analyze the order to determine the cause of the errors, and take the corrective action to correct errors allowing the order to continue to process normally.

Process Amendment

Transitions the order to the Amending state. This transaction is always preceded by the Submit Amendment transaction. See "About the Amending Order State" for more information.

In Design Studio, you can specify a grace period to wait for all accepted tasks to complete before transitioning the order.

Raise Exception

Raises an exception. The system can be configured to initiate fallout compensation with this transaction. In this situation the order transitions to the Amending state while it compensates tasks. From the Amending state, it can transition to the Failed, In Progress, or Waiting for Revision states.

For backwards compatibility this transaction can also trigger a preconfigured exception process. Exception processes are incompatible with OSM's built-in compensation. An order for which an exception process is triggered cannot have compensation applied for revisions, cancellations, or fallout. In this case, the order remains in the In Progress state.

In Design Studio, you can specify a grace period to wait for all accepted tasks to complete before transitioning the order.

Resume Order

Transitions the order to the In Progress state, typically from the Suspended state.

Submit Amendment

Submits an amendment but does not change the order state. This transaction is followed by the Process Amendment transaction, which changes the order state to Amending.

See "About the Amending Order State" for more information.

Suspend Order

Transitions the order to the Suspended order state. Processing on the order halts.

In Design Studio, you can specify a grace period to wait for all accepted tasks to complete before transitioning the order.

Update Order

Allows changes to order data, remarks, and attachments outside the context of a task. The Update Orders can add new data elements, delete existing data elements, or change existing data element. Update Orders can be sent from locations such as:

  • The Task Web client.

  • Automation plug-in XSLT or XQuery automators.

  • Web Services or XML API requests.

In most situations, Update Order does not allow the state of the task to change; for example, when updating an order that is in the Aborted state. When an order is in the Not Started state or the Cancelled state, the Update Order transaction can start or resume the order by running the creation task.

To use Update Order to start or resume an order, you need to use the startOrder flag in the Update Order transaction, in an automation plug-in, a Web services operation, or through the Task Web client. You cannot specify to start or resume an order by configuring the order life-cycle policy in Design Studio.


Figure 6-10 shows OSM order states and transactions.

  • The transactions shown are those that perform transitions between order states. Some transactions, such as Update Order, do not always perform a transition.

  • In this figure, a Resume Order transaction is shown from the Cancelled state to the In Progress state. This transaction is only possible for orders that do not have an orchestration plan. If the order has an orchestration plan, the Cancelled state is a final state and cannot be resumed.

  • Some order state transitions are performed internally by OSM, not by running a transaction.

  • The transition from Not Started to Completed occurs when an order is submitted for a revision to an in-flight order. In this case, all that the revision order must do is submit an amendment. When the revision order is processed, the Submit Amendment transaction places the revision order in the amendment queue. After doing so, the revision order itself requires no further processing because compensation happens to the base order, so the revision order is transitioned directly to the Completed state automatically by OSM, without going to the In Progress state.

    Note:

    Because the transaction from Not Started to Completed for revision orders is required by OSM and is performed by the system, you cannot define permissions or conditions for it. Therefore, it is not shown as a transaction from the Not Started state in Design Studio.

Figure 6-10 OSM Order States and Transactions

Graphic is described in surrounding text.

About Order State Categories

Order states can be categorized by the overall condition of the order that they apply to; for example, if the order is open, closed, or running:

  • Open - Not Running

    • Not Started

    • Suspended

    • Waiting for Revision

    • Canceled

    • Failed

  • Open - Running

    • In Progress

  • Open - Running - Compensating

    • Amending

    • Cancelling

  • Closed

    • Completed

    • Aborted

Figure 6-11 shows the order state categories.

Figure 6-11 Order State Categories

Shows order state categories.

Common Order State Transitions

A typical order processing scenario uses the following order states:

  1. The order is submitted to the Not Started state and transitions to the In Progress state. The order remains in the In Progress state while processing occurs.

  2. When the last task has completed, the order transitions to the Completed state.

    Figure 6-12 shows the states, state categories, and transactions for a basic order processing flow.

    Figure 6-12 Simple Order Processing Flow

    Graphic is described in surrounding text.

The process for revising an order uses the following order states:

  1. The base order is submitted and transitions to the In Progress state.

  2. The revision order is submitted and transitions to the In Progress state.

  3. The base order transitions to the Amending state.

  4. The revision order, after it has amended the base order, transitions to the Completed state.

  5. After processing the amendment, the base order returns to the In Progress state.

  6. When the last task has completed, the base order transitions to the Completed state.

Figure 6-13 shows the order states used for a revision order.

Figure 6-13 Order States Used When Processing a Revision Order

Graphic is described in surrounding text.

A follow-on order uses the following order states:

  1. The base order is submitted and transitions to the In Progress state.

  2. The follow-on order is submitted and transitions to the In Progress state, but it must wait until an order item in the base order completes before it can be processed.

  3. The order item in the base order completes. The base order can continue processing, or it can complete and transition to the Completed state.

  4. Since the order item in the base order has completed, the dependency has been met and the follow-on order begins processing.

  5. When the last task in the follow-on order has completed, it transitions to the Completed state.

A future-dated order uses the following order states:

  1. The order is submitted, but OSM determines that there is a future start date. The order transitions to the Not Started state.

  2. When the order start date is reached, the order transitions to the In Progress order state.

  3. When the last task has completed, the order transitions to the Completed order state.

Optional, Mandatory, and Prohibited Transactions

Transactions for each order state can be optional, mandatory, or prohibited. Optional transactions can either be allowed or prohibited based on conditions and permissions defined in the order life-cycle policy.

Table 6-3 OSM Order Transactions

Order State Mandatory Transactions Prohibited Transactions Optional Transactions

Aborted

None

  • Abort Order

  • Cancel Order

  • Complete Task

  • Fail Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Submit Amendment

  • Suspend Order

  • Delete Order

  • Update Order

Amending

Process Amendment

  • Cancel Order

  • Complete Task

  • Delete Order

  • Fail Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Update Order

  • Abort Order

  • Submit Amendment

  • Suspend Order

Canceled

None

  • Cancel Order

  • Complete Task

  • Fail Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Submit Amendment

  • Suspend Order

  • Abort Order

  • Delete Order

  • Update Order

Canceling

None

  • Cancel Order

  • Complete Task

  • Delete Order

  • Fail Order

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Submit Amendment

  • Update Order

  • Abort Order

  • Suspend Order

Completed

None

  • Abort Order

  • Cancel Order

  • Complete Task

  • Fail Order

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Submit Amendment

  • Suspend Order

  • Abort Order

  • Delete Order

  • Update Order

Failed

None

  • Complete Task

  • Delete Order

  • Fail Order

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Suspend Order

  • Abort Order

  • Cancel Order

  • Manage Order Fallout

  • Submit Amendment

  • Update Order

In Progress

Complete Task

  • Delete Order

  • Manage Order Fallout

  • Resume Order

  • Abort Order

  • Cancel Order

  • Fail Order

  • Process Amendment

  • Raise Exception

  • Submit Amendment

  • Suspend Order

  • Update Order

Not Started

Complete Task

  • Cancel Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Resume Order

  • Submit Amendment

  • Abort Order

  • Delete Order

  • Fail Order

  • Suspend Order

  • Update Order

Suspended

None

  • Complete Task

  • Delete Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Suspend Order

  • Abort Order

  • Cancel Order

  • Fail Order

  • Resume Order

  • Submit Amendment

  • Update Order

Waiting for Revision

None

  • Complete Task

  • Delete Order

  • Manage Order Fallout

  • Process Amendment

  • Raise Exception

  • Suspend Order

  • Abort Order

  • Cancel Order

  • Fail Order

  • Resume Order

  • Submit Amendment

  • Update Order


About the Aborted Order State

An order can be transitioned to the Aborted order state when an unrecoverable error or condition has stopped the processing for the order and the order cannot return to a valid processing state through a revision or fallout management activity within OSM. It can be considered a last resort to prevent any further execution of an order.

An order can be terminated manually from the Order Management Web client or from the Task Web client. (In the Web clients, the command Terminate Order moves the order to the Aborted order state.) You can also transition to the Aborted order state programmatically by using the OSM Web services API or by using an automated task.

The Aborted order state is a final state; the order has been permanently stopped. An order in the Aborted state cannot transition to another state.

Terminated orders may require manual intervention in an OSM Web client to compensate for tasks that have completed or that were in the process of completing. For example, you may be required to release port assignments, delete accounts in billing systems, and so forth.

The entrance transaction to the Aborted order state is Abort Order. This transaction can be run from all order states except the Completed order state.

The exit transaction from the Aborted state is Delete Order, which removes the order from the OSM system.

The Update Order transaction is used when the order is updated manually, outside of the order processing.

Figure 6-14 shows the order states that can transition to or from the Aborted order state.

Figure 6-14 Order States that Can Transition to or from the Aborted Order State

Graphic is described in surrounding text.

About the Amending Order State

An order in the Amending state is undergoing compensation. See "Managing Changes to Orders" for more information.

The transactions that cause an order to move to the Amending state are the Submit Amendment transaction (as a result of a revision order) and the Raise Exception transaction (as a result of fallout for which compensation is needed). The order can be amended from the following order states:

  • In Progress

  • Failed

  • Suspended

  • Waiting for Revision

To transition an order to the Amending state, OSM uses two transactions: Submit Amendment and Process Amendment. These transactions work together to make sure that the order is in a condition that can be amended and that the amendment is allowed.

Each revision to an order uses the Submit Amendment transaction to place the amendment in a queue. The Submit Amendment transaction does not change the order state. Instead, it makes sure that the order is ready to be amended. For example, there might be life-cycle rules that prevent the order from being amended until a condition is met.

When the order is able to process the amendment, the Process Amendment transaction is run on the latest amendment in the queue, and the transition is made to the Amending state. Not every order in the queue is processed:

  • A revision for the same order might have been received while the order is queued. In that case, the later revision is used instead.

  • Restrictions in the life-cycle policy might prevent an amendment from being processed by the Process Amendment transaction.

Unless multiple revisions are common and frequent, the order state transition to Amending will happen almost immediately after the Submit Amendment transaction.

The configurable exit transactions for the Amending state are:

  • Submit Amendment: An order can process a Submit Amendment transaction while the order is in the Amending state. This can occur because additional revision orders can be submitted while the order is in the Amending state. In this case, the Submit Amendment transaction adds the amendment to the amendment queue.

  • Suspend Order: Transitions to the Suspended state.

  • Abort Order: Transitions to the Aborted state.

An order can transition from the Amending state to the In Progress state, but there is no transaction involved. This transition is handled internally by OSM.

An order can transition from the Amending state to the Waiting for Revision state. However, there is no transaction required to transition from the Amending state to the Waiting for Revision state. This transition happens when fallout occurs, and OSM has found that the fallout is caused by the submitted order. In that case, OSM cannot use further compensation (redo/undo) to fix the problem. Instead, OSM waits for a revision to be submitted from the upstream order-source system to fix the problem.

Figure 6-15 shows the order states that can transition to or from the Amending order state.

Figure 6-15 Order States that Can Transition to or from the Amending Order State

Graphic is described in surrounding text.

About the Cancelled Order State

When an order is in the Cancelled state, all tasks have been undone back to the creation task.

The actions allowed when an order is in the Cancelled state are different depending on if the order has an orchestration plan:

  • If an order has an orchestration plan, the Cancelled state is the final state. The order cannot be resumed.

  • If the order does not have an orchestration plan, the order can be resumed at the In Progress state, either by manually opening the order at the creation task and submitting it or by programmatically transitioning the order state using the OSM APIs.

The transaction that causes the Cancelled state is the same Cancel Order transaction that was used for canceling the order.

If the order includes an orchestration plan, the configurable exit transactions are:

  • Update Order: Allows the order data to be changed but does not transition the order to another order state.

  • Abort Order: Transitions to the Aborted state.

  • Delete Order: Removes the order from the OSM system.

If the order does not have an orchestration plan, the configurable exit transactions are:

  • Resume Order: Transitions to the In Progress state.

  • Update Order: Allows the order data to be changed. This transaction can also transition the order to the In Progress state if the startOrder option is used. See the discussion of the Update Order transaction in Table 6-2, "Order State Transactions" for more information.

  • Abort Order: Transitions to the Aborted state.

  • Delete Order: Removes the order from the OSM system.

Important:

When resumed after being canceled, the order begins again at the beginning of the execution; it is not resumed at the point in the execution it was in when canceled.

Figure 6-16 shows the order states that can transition to or from the Cancelled order state if the order has an orchestration plan.

Figure 6-16 Order States that Can Transition to or from the Cancelled Order State if the Order Has an Orchestration Plan

Graphic is described in surrounding text.

Figure 6-17 shows the order states that can transition to or from the Cancelled order state if the order does not have an orchestration plan.

Figure 6-17 Order States That Can Transition To Or From the Aborted Order State if the Order Does Not Have an Orchestration Plan

Graphic is described in surrounding text.

About the Cancelling Order State

When an order is in the Cancelling state, at least one live task is running in a cancellation compensation mode. OSM undoes all completed tasks to return the order to the creation task. When OSM has finished, the order transitions to the Cancelled state

The entrance transaction for the Cancelling order state is the Cancel Order transaction. An order can be canceled from the following order states:

  • In Progress

  • Suspended

  • Waiting for Revision

  • Failed

The configurable exit transactions for the Cancelling order state are:

  • Suspend Order: Transitions to the Suspended state.

  • Abort Order: Transitions to the Aborted state.

Figure 6-18 shows the order states that can transition to or from the Cancelling order state.

Figure 6-18 Order States That Can Transition To Or From the Cancelling Order State

Graphic is described in surrounding text.

About the Completed Order State

The order has been fulfilled. There are no live tasks and processing is complete. This is a final state. An order in the Completed state cannot transition to another state.

The entrance transaction for the Completed state is the Complete Task transaction. It transitions from the In Progress state.

The Complete Task transaction is used internally whenever the last task is completed in the order, which is determined automatically by OSM. Therefore the Complete Task transaction is not shown as part of the life-cycle policy in Design Studio.

The transition from the Not Started state to the Completed state is specific to revision orders. When a revision order that has been submitted and accepted transitions to the Completed state directly, because the compensation for the revision happens on the base order being revised.

The configurable exit transactions for the Completed order state are:

  • Delete Order: Removes the order from the OSM system.

  • Update Order: Allows the order data to be added, changed, or deleted but does not transition the order to another order state.

Figure 6-19 shows the order states that can transition to or from the Completed order state.

Figure 6-19 Order States that Can Transition to or from the Completed Order State

Graphic is described in surrounding text.

About the Failed Order State

If an order is the Failed state, the order failed during fulfillment, after the order was submitted by the order-source system.

The entrance transaction for the Failed order state is the Fail Order transaction. An order can transition to the Failed state from the following states:

  • Not Started

  • In Progress

  • Suspended

  • Waiting for Revision

The configurable exit transactions for the Failed order state are:

  • Manage Order Fallout: Transitions back to the state that the order was in when the Fail Order transaction occurred. For example, if the order was in the Not Started state and then failed, the Manage Order Fallout transaction returns the order to the Not Started state. It can exit to the following states:

    • Not Started

    • In Progress

    • Waiting for Revision

  • Suspend Order: Transitions to the Suspended state.

  • Update Order: Allows the order data to be added, changed, or deleted but does not transition the order to a different order state.

  • Submit Amendment/Process Amendment: Submits an amendment and is followed by the Process Amendment transaction and transitions the order to the Amending state.

  • Cancel Order: Transitions to the Cancelling state.

  • Abort Order: Transitions to the Aborted state.

Figure 6-20 shows the order states that can transition to or from the Failed order state.

Figure 6-20 Order States that Can Transition to or from the Failed Order State

Graphic is described in surrounding text.

About the In Progress Order State

An order in the In Progress state is actively running. Future-dated orchestration orders have an In Progress state while they wait for dependencies to be resolved.

The entrance transactions for the In Progress state are:

  • Update Order: Transitions from the Not Started state or Cancelled state when the startOrder option is used. Programmatic creation of an order typically begins the execution of the order, transitioning it to the In Progress order state when the startOrder option is set to true on the CreateOrder or CreateOrderBySpecification OSM Web services operation. See the discussion of the Update Order transaction in Table 6-2, "Order State Transactions" for more information.

  • Resume Order: Transitions from the following states:

    • Suspended

    • Waiting for Revision

    • Canceled

    Tip:

    The Cancelled state returns the order to the creation task, so the Resume Order transaction does not resume from the state it was in when canceled. Instead, it resumes at the beginning of the process.
  • Manage Order Fallout: Transitions from the Failed state.

An order can transition from the Amending state to the In Progress state, but there is no transaction involved. This transition is handled internally by OSM.

The exit transactions for the In Progress order state are:

  • Update Order: Allows the order data to be added, changed, or deleted.

  • Submit Amendment/Process Amendment: Submits an amendment (typically from an external CRM system) and is followed by the Process Amendment transition. Transitions to the Amending state.

  • Suspend Order: Transitions to the Suspended state.

  • Cancel Order: Transitions to the Cancelling state.

  • Fail Order: Transitions to the Failed state.

  • Abort Order: Transitions to the Aborted state.

  • Raise Exception: The Raise Exception transaction is a special type of transaction from the In Progress state. For order fallout scenarios, the Raise Exception transaction can transition the order to the Amending state to perform compensation for the error. However, for backward compatibility with orders that use process exceptions, the Raise Exception transactions starts an exception handling process, but the order remains in the In Progress state. See the discussion of the Raise Exception transaction in Table 6-2, "Order State Transactions" for more information.

  • Complete Task: Transitions from the In Progress state, but only when the last task in the order is completed. This transaction is also used internally whenever a task is completed in the order. It is not shown in the life cycle display in Design Studio.

Figure 6-21 shows the order states that can transition to or from the In Progress order state.

Figure 6-21 Order States That Can Transition To Or From the In Progress Order State

Graphic is described in surrounding text.

About the Not Started Order State

When an order is in the Not Started state, the order has been created but has not started. There are no live tasks other than the creation task.

The entrance transactions for the Not Started state are:

  • Resume Order: Transitions from the Suspended state if the order was in the Not Started state when it was Suspended.

  • Manage Order Fallout: Transitions from the Failed state if the order was in the Not Started state when the Fail Order transaction occurred.

The exit transactions for the Not Started state are:

  • Update Order: Allows the order data to be added, changed, or deleted. Can also transition the order to the In Progress state if the startOrder option is used. See the discussion of the Update Order transaction in Table 6-2, "Order State Transactions" for more information.

  • Suspend Order: Transitions to the Suspended state.

  • Fail Order: Transitions to the Failed state.

  • Abort Order: Transitions to the Aborted state.

  • Submit/Process Amendment: Transitions to the Completed state. This transition is specific to revision orders. When a revision order is submitted, if it is accepted it transitions to the Completed order state directly, because the compensation for the revision happens on the base order being revised.

  • Delete Order: Removes the order from the OSM system.

Figure 6-22 shows the order states that can transition to or from the Not Started order state.

Figure 6-22 Order States that Can Transition to or from the Not Started Order State

Graphic is described in surrounding text.

About the Suspended Order State

In the Suspended state, all processing on the order has been halted. No task can be updated or transitioned.

The only entrance transaction for the Suspended state is the Suspend Order transaction. Orders can be suspended from the following order states:

  • Not Started

  • Failed

  • Canceling

  • In Progress

  • Amending

The exit transactions for the Suspended order state are:

  • Resume Order: Transitions the order to the state that it was in when it was suspended.

  • Submit Amendment/Process Amendment: Submits an amendment (typically from an external CRM system) and is followed by the Process Amendment transition. Transitions to the Amending state.

  • Update Order: Allows the order data to be added, changed, or deleted.

  • Cancel Order: Transitions to the Cancelling state.

  • Fail Order: Transitions to the Failed state.

  • Abort Order: Transitions to the Aborted state.

Figure 6-23 shows the order states that can transition to or from the Suspended order state.

Figure 6-23 Order States That Can Transition To Or From the Suspended Order State

Graphic is described in surrounding text.

About the Waiting for Revision Order State

This state is common following compensation to an order for fallout, when the order is awaiting a revision from the order-source system to correct something that caused a failure in the originally submitted order.

The entrance transaction for the Waiting for Revision order state is the Manage Order Fallout transaction, which runs from the Failed state.

An order can transition from the Amending state to the Waiting for Revision state. However, there is no transaction required to transition from the Amending order state to the Waiting for Revision order state. This internal transition is triggered by the Raise Exception transaction and it happens when fallout occurs and OSM has found that the fallout is generated by the submitted order instead of by a task in the process. Therefore, OSM cannot use compensation (redo/undo) to fix the problem. Instead, OSM waits for a revision to be submitted from upstream to fix the problem.

The exit transactions for the Waiting for Revision order state are:

  • Submit Amendment/Process Amendment: Submits an amendment (typically from an external CRM system) and is followed by the Process Amendment transition. Transitions to the Amending state.

  • Update Order: Allows the order data to be added, changed, or deleted.

  • Resume Order: Transitions to the In Progress State

  • Cancel Order: Transitions to the Cancelling state.

  • Fail Order: Transitions to the Failed state.

  • Abort Order: Transitions to the Aborted state.

Figure 6-24 shows the order states that can transition to or from the Waiting for Revision order state.

Figure 6-24 Order States that Can Transition to or from the Waiting for Revision Order State

Graphic is described in surrounding text.

About Deleting Orders

You cannot use either of the OSM Web clients or any Web services operation to delete orders from the OSM system. Instead, use the orderPurge command. See OSM System Administrator's Guide for more information.

Order Life-Cycle Events

You can configure orders to publish events when any of the following occurs:

Order life-cycle events are published as Java Message Service (JMS) messages containing order identification and state information. You can configure which life-cycle events you want to be generated for an order type in Design Studio.

Figure 6-25 shows the events you can publish.

Figure 6-25 Order Events in the Order Specification

Shows the events that you can publish.