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.
