3 Modeling Order Life-Cycle Policies

This chapter describes how to model order life-cycle policies in an Oracle Communications Order and Service Management (OSM) solution.

Modeling Order Life-Cycle Policy 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:

An order is created in the Not Started state.
When processing begins on the order, the state transitions to the In Progress state.
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:

Stops all processing on the order
Transitions the order to the Suspended state

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 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 3-1 shows the life-cycle policy for the Process Amendment transition. In this case, it returns true, so it is always allowed to transition.

Figure 3-1 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 PONR for amendment processing. See OSM Concepts 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 Oracle Communications 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 3-2 shows the target order displayed in the Task web client.

Figure 3-2 Target Order Displayed in the 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 3-3 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 3-3 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 3-4 shows life-cycle permissions configured in Design Studio.

Figure 3-4 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 3-1 shows the OSM order states.

Table 3-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. A completed order can be canceled, updated, or deleted. 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	The order is not ready to start because it is future-dated or blocked by another order. See "About the Waiting 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 3-2 shows transactions that are included in the order life-cycle policy and the operations they perform.

Table 3-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 service 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 3-5 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 3-5 OSM Order States and Transactions

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
- Waiting for Revision
- Canceled
- Failed
Open - Running
- In Progress
Open - Running - Compensating
- Amending
- Cancelling
Closed
- Completed
- Aborted

Figure 3-6 shows the order state categories.

Figure 3-6 Order State Categories

Common Order State Transitions

A typical order processing scenario uses the following order states:

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.
When the last task has completed, the order transitions to the Completed state.

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

Figure 3-7 Simple Order Processing Flow

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

The base order is submitted and transitions to the In Progress state.
The revision order is submitted and transitions to the In Progress state.
The base order transitions to the Amending state.
The revision order, after it has amended the base order, transitions to the Completed state.
After processing the amendment, the base order returns to the In Progress state.
When the last task has completed, the base order transitions to the Completed state.

Figure 3-8 shows the order states used for a revision order.

Figure 3-8 Order States Used When Processing a Revision Order

A follow-on order uses the following order states:

The base order is submitted and transitions to the In Progress state.
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.
The order item in the base order completes. The base order can continue processing, or it can complete and transition to the Completed state.
Since the order item in the base order has completed, the dependency has been met and the follow-on order begins processing.
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:

The order is submitted, but OSM determines that there is a future start date. The order transitions to the Not Started state.
When the order start date is reached, the order transitions to the In Progress order state.
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 3-3 shows the order states and their transactions.

Table 3-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 Process Amendment Raise Exception Resume Order Update Order	Abort Order Manage Order Fallout Submit Amendment Suspend Order
Canceled	None	Complete Task Fail Order Manage Order Fallout Process Amendment Raise Exception Resume Order Submit Amendment Suspend Order	Abort Order Delete Order Update Order Cancel 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 Manage Order Fallout
Completed	None	Abort Order Complete Task Fail Order Process Amendment Raise Exception Resume Order Submit Amendment Suspend Order	Delete Order Update Order Cancel 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 Resume Order	Abort Order Cancel Order Fail Order Manage Order Fallout 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 Process Amendment Raise Exception Suspend Order	Abort Order Cancel Order Fail Order Manage Order Fallout Resume Order Submit Amendment Update Order
Waiting	None	Complete Task Delete Order Process Amendment Raise Exception	Abort Order Cancel Order Fail Order Submit Amendment Suspend Order Update Order
Waiting for Revision	None	Complete Task Delete Order Process Amendment Raise Exception Suspend Order	Abort Order Cancel Order Fail Order Manage Order Fallout 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 Service 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 3-9 shows the order states that can transition to or from the Aborted order state.

Figure 3-9 Order States that Can Transition to or from the Aborted Order State

About the Amending Order State

An order in the Amending state is undergoing compensation.

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 and that there are no life-cycle rules that prevent the order from being amended until a condition is met. For example, although an order in the Suspended state can receive amendments from the Submit Amendment transaction, the order must be resumed before it can process the amendments.

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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

Figure 3-10 shows the order states that can transition to or from the Amending order state.

Figure 3-10 Order States that Can Transition to or from the Amending Order State

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 3-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 3-11 shows the order states that can transition to or from the Cancelled order state if the order has an orchestration plan.

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

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

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

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
Completed
Suspended
Waiting
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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

Figure 3-13 shows the order states that can transition to or from the Cancelling order state.

Figure 3-13 Order States That Can Transition To Or From the Cancelling Order State

About the Completed Order State

The order has been fulfilled. There are no live tasks and processing is complete.

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.
Cancel Order: Allows the order to be canceled.

Figure 3-14 shows the order states that can transition to or from the Completed order state.

Figure 3-14 Order States that Can Transition to or from the Completed Order State

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 or during order recognition when validating the incoming order data.

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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

Figure 3-15 shows the order states that can transition to or from the Failed order state.

Figure 3-15 Order States that Can Transition to or from the Failed Order State

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 Service operation. See the discussion of the Update Order transaction in Table 3-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 3-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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

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

Figure 3-16 Order States That Can Transition To Or From the In Progress Order State

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 3-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 3-17 shows the order states that can transition to or from the Not Started order state.

Figure 3-17 Order States that Can Transition to or from the Not Started Order State

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: Submits an amendment (typically from an external CRM system) to the amendment queue. Typically, the Submit Amendment transaction is followed by the Process Amendment transaction, which transitions the order to the Amending state. However, an order in the Suspended state must be resumed with the Resume Order transaction before amendments can be processed. After the order is resumed, the Process Amendment transaction is run on the latest amendment in the queue and the order 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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

Figure 3-18 shows the order states that can transition to or from the Suspended order state.

Figure 3-18 Order States That Can Transition To Or From the Suspended Order State

About the Waiting Order State

This state indicates orders that have been created but are not ready to start. The reasons orders can enter this state are:

The order is future-dated
The order is a follow-on order whose predecessor has not completed
The order is subject to inter-order dependencies that have not completed

The Waiting order state is usually entered from the Not Started state and transitions to the In Progress state when the blocking condition listed above has been resolved, for example the start date for a future-dated order has been reached.

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 3-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.

The entrance transactions for the Waiting order state are:

Resume Order: Transitions from the Suspended state.
Resolve Failure: Transitions from the Failed state.

An order can transition from the Not Started state to the Waiting state when the order is ready for processing, but is either future-dated or blocked by another order as described earlier in this section.

The exit transactions for the Waiting order state are:

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.

An order can transition from the Waiting state to the In Progress state when the future date is reached or the blocking by another order is resolved.

Figure 3-19 shows the order states that can transition to or from the Waiting order state.

Figure 3-19 Order States that Can Transition to or from the Waiting Order State

Surrounding text describes Figure 3-19 .

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.

You can also enable the Manage Order Fallout transaction for this state that controls the following for managing tasks in the failed state:

RetryOrder and ResolveFailure OSM Web Service operations
Retry Order and Resolve Order Failure Order Management web client actions

See OSM Developer's Guide, OSM Order Management Web Client User's Guide, and OSM Task Web Client User's Guide for more information.

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

Figure 3-20 Order States that Can Transition to or from the Waiting for Revision Order State

Surrounding text describes Figure 3-20 .

About Deleting Orders

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