Order Orchestration Process Definition and related info

Order Orchestration Process Definition

•A Orchestration is the automated sequence of fulfillment steps for processing an order. Orchestration processes are defined to mirror the actual business processes, much like a blueprint.

•Orchestration Process Definition includes sequence of service calls, planning details, change management parameters and status conditions.

Process Step

•Process step is the building block of an orchestration process definition which specifies which task layer service to call or which sub-process to launch. It represents a step in a given business process

Step Type

•Step type is a classification that indicates the usage of the step. Step type is used to control the user interface conditional read-only behavior for some attributes. It is also used during validation and building of the Business Process Execution Language (BPEL) artifacts from the orchestration process definition.

•Process Display Name – This name will be seen in orchestration process name field of Order under fulfillment line section.

Process Class –

Change Mode – always preferred and recommended as advanced until have the server space issue. This allows to handle the change management

• None - Do not record the state of the orchestration process, and do not allow a change.

• Simple - Record the state of the orchestration process when it starts and at the step where the orchestration process receives the change.

• Advanced - Record the state of the orchestration process at each orchestration process step.

Set – it is a set of business groups or individual business group this orchestration process will be applicable.

Cost of change rule – it is at header level as well o capture the condition or criteria to apply cost

Parent process – if this check box is checked, then the process is parent process. Otherwise it is considered as a sub process. And the sub process can be used as a part of parent process. When parent process is executed during run time, all steps or tasks under sub process are followed as a part of parent process.

Task Type

•Task types are groupings of related fulfillment tasks. Each task type contains a selection of services that can be used to communicate with a specific type of fulfillment system

Task(Task Name)

•A task is a specific activity that must be carried out to complete a given Orchestration process.

Service

•Services send information to downstream fulfillment systems and interpret the responses/updates from those systems. It represents the types of actions that are being requested of the fulfillment system, such as creating the shipping request or canceling it.  For example, a ship order process calls the task layer service Create Shipment request to send a shipment request to the shipping system. 

Step Type

•Conditional: Conditional node of the orchestration process. This is the point where one of two or more orchestration paths is executed, based on the results of a logical condition. You must specify a branching condition on a step that directly follows a conditional step.

•Parallel: Parallel node of the orchestration process. This is the point where two or more orchestration paths are executed concurrently. You don’t need to include conditions because all paths are executed.

•Merge: Point where two or more orchestration paths reunite. 

•Service: Step where you define a service. The services that appear depend on the Task Type you select.

•Sub process: Set of steps that are defined by your organization so that they can be added as a unit to one or more orchestration processes. At run time, the steps behave as if they were added individually to the process

Task Type

Task types are groupings of related fulfillment tasks. Each task type contains a selection of services that can be used to communicate with a specific type of fulfillment system.

Oracle Fusion Order Management provides the following predefined task types:

•Schedule: Set of services that enable scheduling of a fulfillment line

•Reservation: Set of services that enable reservation of items of a fulfillment line

•Shipment: Set of services that communicate with a shipping fulfillment system to ship the items on a fulfillment line

•Invoice: Set of services that communicate with a billing system to create invoices against an order line by line 

•Activity: Set of services that communicate with a fulfillment system to cause a human activity, such as an installation.

•Return: Set of services that communicate with a fulfillment system to return items of a fulfillment line

•Fulfill: Set of services that enable integration between Oracle Fusion Order Management and an enterprise resource planning (ERP) system. Note that the fulfillment task layer is not atomic like the other task layers, you can have multiple fulfillment actions through a single request, such as shipment and invoicing.

•Pause: Set of services that temporarily pause processing to wait until a particular date or event before going to the next step. This task can be used to coordinate processing across the lines in an order.

•Procurement: Set of services that enable sourcing and shipping of items of a fulfillment line from an outside organization

•Supply: Set of services that communicate with Oracle Fusion Supply Chain Orchestration to enable more complex sourcing of items on a fulfillment line.

•Branching

Branching involves placing a switch in the business process flow which enables splitting the process into two or more branches.

Types of Branching:

•Parallel branching: Allows you to create multiple sequences (branches) of orchestration process steps that are executed at the same time. You don’t need to include additional parameters to set up parallel branching.

•Conditional branching: Allows you to create orchestration process steps that are executed under certain conditions. For example, your company might want to require that if quantity is greater than or equal to 10, then reserve the quantity.

•Orchestration process Class – Define the orchestration process class. When this process class is selected while defining the orchestration process. All the statuses under this process class will be available for defining the orchestration process and process statuses.

Status Rule Set

•Status rule sets apply a set of sequential statuses to the fulfillment line that is processed by the orchestration process.

•A status rule set is a set of rules that govern the conditions under which status codes are assigned to fulfillment lines.

•When you create a status rule set, you determine the status to assign to a fulfillment line at each stage of the process.

•

  For example, if a task has a status of Unsourced, then you can create a rule that is used at   run time to set the fulfillment line status to Unscheduled. A status rule set streamlines   administration by enabling you to use a rule set with any number of fulfillment lines, rather   than by entering separate rules for each fulfillment line. You can also apply the same logic t  to multiple categories. 

Pausing Orchestration Processes

A pause task temporarily stops an orchestration process from running so that it can wait for a condition to be met. When the condition is met, the orchestration process releases this pause task, and then proceeds to the next orchestration process step.

A pause task can be used in the following business scenarios –

•Pause an orchestration process until an event occurs

•Pause an orchestration process until time elapses

•Pause an orchestration process until a dependency resolves

You can use a pause task to wait between tasks, and to specify when to release the pause and begin the next orchestration process step.

•Release automatically – Create a scheduled process that releases the pause task.

•Release manually – Navigate to the Orchestration Process details page, and then click Release Pause Task. One must possess the Order Orchestration Error Recovery Manager role.

An orchestration process can be defined that uses a pause task to temporarily stop it from running so that it can wait for an event to occur.

Assume you work for a publisher who will release a new book at some point in the future, and that you need to provide your Gold customers an opportunity to order the book before your company releases it to the general public.

The following condition can be created –

•If the customer demand class is Gold, then use a scheduled process named Release Pause Tasks. This scheduled process searches for the condition that releases the pause task.

The following rules can be created –

•If the conditions are true, then pause the task.

•If the conditions of the first rule are not true, then skip the pause task.

You can define an orchestration process that uses a pause task to temporarily stop the orchestration process from running so that it can wait for time to elapse.

In this example, you define an orchestration process that pauses before it ships preordered items.

You create the following condition:

•If the source system is Legacy, then release the pause on ShipDate minus two.

You create the following rules:

•If the condition is met, then release the pause on a date.

•if the condition is not met, then release the pause immediately.

This example describes how to coordinate orchestration processes to make sure that Order Management Cloud invoices all the order lines that a sales order contains at the same time, even if the shipment dates vary. The orchestration process uses the same sequence of steps to process each fulfillment line, but these lines might not be synchronized.

Assume a school district places a sales order for 600 new history books and requires that they receive the invoice for this sales order only after Order Management ships all the books.

•Fulfillment line 1 gets 80 books from the Seattle warehouse

•Fulfillment line 2 gets 400 books from the Denver warehouse

•Fulfillment line 3 gets 120 books from the Chicago warehouse

You define an orchestration process that processes the order lines, pauses them until all of these lines are shipped, and then sends them to billing.

Using a Public Service to Release Paused Tasks

An external application can call a public service named Release Paused Tasks to release a pause task. You can use the settings of this service to identify the pause tasks to release. The event handler calls the service to release the pause tasks according to the settings that you specify.

To get the attributes that the sales order references, you can use the order capture service that requests the order details.

Sending Notifications From Order Management Cloud to External Systems: Procedure

Order Management Cloud uses a connector to communicate with your external system. The connector specifies the URL that locates your external system and the security credentials that your external system requires during communication. You must configure this connector, and then associate it with the business event that sends notifications to your external system.

Order Management monitors the conditions that your business events specify during order fulfillment. If Order Management determines that it must send a notification according to one of these business events, then it communicates this information to the endpoint URL for each connector that you associate with the event trigger point. For example, if you add a check mark to the Notify External System option for the Shipped status value on a status rule set, then Order Management communicates a business event any time it sets a fulfillment line status to Shipped, and it sends this business event to the endpoint URL of the connector that you associate with a business event named Fulfillment Line Status Update. For details about this option, see Adding Status Conditions to Fulfillment Lines: Procedure.

Summary of the Work

To configure Order Management to send notifications to external systems, do the following work:

1.Configure the connector.

2.Manage business event trigger points.

Configure the Connector

Configure the connector that Order Management uses to communicate with your external system:

1.In the Navigator, click Setup and Maintenance.

2.On the Setup and Maintenance page, search for, and then open Manage External Interface Web Service Details.

3.On the Manage Connector Details page, click Actions, , click Add Row, and then set the following values.

Field  Description 

Target System  Select the system that must receive the notification. This system subscribes to the business event.

Connector Name  Enter text that describes the purpose of the connector. For example, to indicate that you use this connector to send notifications to a legacy 

  system, enter LEG_Notification.

Connector URL  Specify an endpoint URL. This URL is the address of a web service that you deploy on the subscriber system. Order Management will call this

  web service, and the web service must accept the event payload that Order Management sends.

  User Name  Enter the user name that the subscriber system requires.

  Password  Enter the password that the subscriber system requires.

Manage Business Event Trigger Points

Manage the business event trigger points that determine when to communicate business events to your external system:

1.On the Search page, search for, and then open Manage Business Event Trigger Points.

2.On the Manage Business Event Trigger Points page, choose a trigger point.

At runtime, if an order reaches the trigger point that you specify, then Order Management calls the web service that you referenced in the Connector URL field. This web service then sends details of the business event to the subscriber system. For example, to send a notification when a fulfillment line closes, choose the Fulfillment Line Closed trigger point.

3.Click Actions, and then click Add Row.

  Note that some trigger points include an Associated Connectors tab in the details area. If this tab displays, then click it to add the connector.

4.   Set the following values.

  Field  Description 

  Connector Name  Select the connector that you configured in the Configure the Connector topic.

  Override Default Visibility  Set one of the following values:

Contains a check mark. Send notifications about each sales order even if the system that receives the notification possesses no knowledge about this sales order.

Does not contain a check mark. Do not send notifications about each sales order to systems that do not already possess knowledge about this sales order.

Assume your implementation includes Source System 1 and Source System 2, and that each of these systems can send a source order to Order Management Cloud. Assume that Source System 2 has no knowledge of source orders that originate in Source System 1, and that you do not want to notify Source System 2 when an event occurs that is associated with a source order that originates in Source System 1. In this situation, if Override Default Visibility does not contain a check mark, then Order Management Cloud will not call the connector service for the subscriber system, and Source System 2 will not receive the notification.

7. Optional. Repeat step 3 through step 4.

  You can associate the same connector with multiple business events, as necessary.

9. Optional. Repeat step 2 through 5 for each trigger point that you must administer.

10. Click 

Save and Close.

Hold

•If a hold is not immediately effective, for example, if the hold applies to a future task, then Order Management communicates a business event when the hold becomes effective, not when the request to add the hold occurs.

•If change management releases or applies a hold, then Order Management does not communicate a business event.

Order Attribute Update

•Each attribute that the Order Update: Attributes That Trigger Events area displays can trigger a business event. These attributes are predefined. You can also configure an extensible flexfield that modifies these attributes. If you do configure an extensible flexfield, then Order Management displays it in the Select and Add: Attributes That Trigger Events dialog. If you select one or more segments, and then click OK or Apply, then Order Management displays the segments that you select in the Order Attribute Update: Attributes That Trigger Events area.

•If Order Management updates more than one attribute of the Order Attribute Update business event at the same time, then it sends only one notification. This notification includes information about the attributes that it updated.

•The status values on the Order Header Status Update: Status Values That Trigger Events area start the Order Header Status Update business event. These values are predefined. You cannot add status values in this area.

Change Attributes : Order attributes that identify change, also known as change attributes, are the attributes that, if changed by order capture or an Order Orchestration work area user, triggers compensation.

Some changes do not require compensation. For example, a change order is sent with an updated Sold-to Contact ID when an orchestration process is on the Ship Goods step. The changed Sold-to Contact ID does not affect the orchestration process in any way, so there is no need to trigger compensation. However, you may want to trigger compensation when a change to an attribute as significant as Inventory Item ID arrives when the orchestration process is on a shipping task. You designate these attributes on the Manage Order Attributes That Identify Change page. Some attributes are selected by default. You can’t remove them, but you can add more.

Compensation Pattern : Compensation refers to how the orchestration process is adjusted to respond to the change. By default, each step is compensated by updating it with the new information from the change order. You can override this default behavior by specifying a compensation pattern for a particular step.

Planning Default Branch : If the orchestration process has multiple conditional branches, then the step you mark as the default branch is used for planning until one of the branches is selected during execution. The steps in the planning default branch are the ones that will appear in the Order Orchestration work area when the orchestration process is first assigned to a fulfillment line. If a different branch is taken, then the process is replanned and the display adjusted to match the new picture.

•Fulfillment Completion Step: Select the step that marks completion of the task from the customer’s standpoint. The chronological last step may not be the last step the customer cares about. For example, the orchestration process is planned with the requested ship date as the completion date for the step identified in the orchestration process as the last step. Planning dates available on the order:

•Requested Ship Date

•Requested Arrival Date

•Required Fulfillment Date

•Default Lead Time/Lead Time UOM Lead time is the expected duration for a given unit of work to be completed. If a lead-time expression is not defined for a step, then the default lead time is used. If this field is left blank, then it defaults to zero, and 0 is assumed during calculations.

•Lead-Time Expression Define lead times using Oracle Business Rules. This method provides flexibility when defining complex lead-time expressions.

•Next Expected Task Status This is used for displaying the expected status transitions in the status details tab of the orchestration plan on the Order Management work area

•Jeopardy indicates the severity of the delay of a task in an orchestration process. Jeopardy indicators appear in the Order Management work area, so that an order manager can quickly identify the fulfillment lines in which issues exist.

•It Is based on forward and backward planning across an orchestration process, which calculates the accurate promise dates for each task. When one of these tasks is delayed, jeopardy indicates how severe the delay is, based on the jeopardy settings.

•It Is calculated when planning runs. You can use it on planned dates, as well as actual dates. This means that an order manager can learn about jeopardy conditions before they actually happen, so that the order manager can provide remedies to maintain customer satisfaction. 

Release the orchestration process definition by selecting Release from the Actions menu. Validation runs, and the release process stops if errors occur. You can use the messages to determine what needs to be fixed and then try to release the process.

After the process is released, deploy the process to the associated SOA server by selecting Deploy from the Actions menu.