Workflow - Step by Step for Order Management

Subhash V. V. Koppana
KPMG Consulting

Introduction
The order processing is now carried out using workflows in Oracle Order Management (11i) in place of order
cycles. Not enough details are available in Oracle manuals or in the training classes to setup and customize Order
Management transaction types and associated workflows. This paper will provide users and developers a "step by
step approach" to setup and customize the order-processing workflows.

Building Blocks of Oracle Workflow

The major components of Oracle Workflow include Workflow Builder, Workflow Engine, Notifications System and
Workflow Monitoring Tool.

Workflow Builder is used extensively in customizing workflows along with other Oracle database tools such as
Sql*Plus. It is a graphical tool to create, view and modify the business processes and other workflow objects with
simple drag-drop operations. You can work with Workflow Builder in stand-alone mode, without connecting to the
database.

Workflow Engine executes the workflows. It is embedded in Oracle database. It monitors the workflow status and
coordinates the routing of activities in process. Background Workflow Engine is sub-function of Workflow Engine
that manages deferred and timed-out processes.

Notifications system sends notifications to the users and processes the responses.

Workflow Monitoring Tool will help in tracking the status of the execution and administer the errors and exceptions
occurred during the process.

Order Management Workflows

Oracle Order Management is packaged with mainly three seeded types of workflows i.e. OM Order Header, OM
Order Line and OM Generate Cost of Goods Sold Account workflows, which are generic and complex in nature.
These generic workflows consume system resources, although many activities are not used by the businesses. In
most situations, very simple workflows can do the job. By simply removing some unused activities or by
rearranging the activities in the generic processes, efficiency of the order processing can be improved significantly.
Custom workflows with few simple custom coded functions will also reduce the complexity of the workflow and
improve the order processing notably.

Customizing Workflows
The steps involved in customizing workflows are as follows: planning workflow customizations; making local copy
of the seeded workflows from OM database; optionally redefining exiting activities with more meaningful names
that represent the business; defining new workflow functions, notifications, processes and other objects using Oracle
Workflow Builder; writing custom code for functions, if required; validating definitions; saving changes to the
database as well as to the local file; setting up order transaction types and relating them to the workflows.
Extent of Customization
Level of customization depends upon the business requirements. You can customize the workflows by creating
processes using seeded activities, simply rearranging them, by creating processes using seeded and redefined
activities, by creating processes using seeded and redefined activities with external PL/SQL triggers and by creating
processes using any combination of standard, redefined and simple custom coded functions.

Planning Customization
Plan customizations well before start using Workflow Builder. Based on the requirements, design the processes and
decide on workflow objects that are required to construct those processes.

A simple business case is presented here to understand the customization process easily.

A service company offers field service and depot service to all the registered customers at a fixed price per type of
the unit repaired. The customer service representatives take orders and determine the type of repair.

For field service orders, they assign a filed engineer. The customer can also order additional spare parts. The field
engineer performs the service and communicates back to the company. He/she also informs details of the parts used
in the service that may not be covered under the service agreement. The order line is updated with service date (say,
a descriptive flexfield segment). The parts used are entered as additional lines on the order. These additional lines
can be shipped on the system and the customer can be billed accordingly.

Depot service is performed at the company's depot facility, which uses a legacy system for keeping track of the
repair activity. The depot orders are interfaced periodically to the legacy repair system from the order management
system. The customer ships the defective unit to the depot. The depot receives it against the order, repairs and ships
it back to the customer. The shipments are interfaced back to the order management system. For simplicity, assume
that the parts used information is not passed to the order management system as the price is fixed for repairing each
type of unit.

To accomplish these two processes, two custom line workflows are needed; one for field service orders and another
for depot service orders.

The field service workflow, "Line Flow - Field Service (custom)" uses a custom coded function to check
completeness of service "Is service Completed?", custom ship-line process "Ship - Line, Manual (custom) process)"
and other seeded activities to take care of non-shippable service and shippable spare parts. Also, uses two lookup
types: "Ship Results" to branch the process from "Ship-Line, Manual (custom)" and "Service Results" to branch the
process from "Is Service Completed?" function.

The depot repair workflow, "Line Flow - Depot Repair (custom)" uses two redefined functions: "Interface Orders to
Depot (Redef)" and "Interface Shipments from Depot (Redef)". These are defined using WF_STANDARD.BLOCK
function that stops the process until external trigger moves it to the next activity. Custom PL/SQL stored procedures
are used to interface data between the order management system and legacy repair system. These stored procedures
are coded to move the redefined functions to the next activity.

To create service orders one order transaction type (SERVICE ORDER) and two line transaction types (SERVICE
ORDER LINE - FIELD and SERVICE ORDER LINE - DEPOT) are defined to which the custom workflows are
associated.

This business case is designed to demonstrate later three levels of customizations, as first one is very simple.
Making Local Copy
Before start customizing, it is a good practice to make a local copy from the database. Even if an old local copy is
available on the hard drive, it is rather safe to make copy from the database. Otherwise, you may lose the latest
changes that might have been made by some other user.

To make a copy, run Workflow Builder and click on the folder button from the toolbar. Choose "Database" option
and enter user name, password and connection name to establish the database connection. After database is
connected, "Show Items Types" pops up. Choose all of the seeded OM item types by double clicking on them. Click
OK to load these item types in Workflow Builder's navigator tree.

Navigator Tree

Navigate to "Save as" from File menu, choose "File" option and specify the directory name on your local drive and
file name. Notice the change in the data store name. It changes from database schema name to the filename that was
specified to save.

To make changes, either continue the same session or close all data stores, exit from Workflow Builder, restart
another session and open it again from file data
store.

Defining Lookup Types

A lookup type is a list of values that can be
referenced by a function, or process as its possible
result type. These are analogous to the Quick
Codes in Oracle Applications. Examples: Shipping
Results, Service Results.

To define lookup type, click plus sign right next to

"OM Order Line", then right click on "Lookup

Lookup Type
types" and choose "New". Specify Internal Name, Display Name and Description. Internal Name and Display
Names must be unique within the Item type. Click OK to add the new lookup type.

Defining Lookup Codes

A lookup type has one or more values called
lookup codes associated with it. Example: Shipping
Result lookup type has Ship Confirm, Non
Shippable, Over Shipped Beyond Tolerance, and
Unreserve.

To add a new lookup code, right click on the

lookup type, and choose "New Lookup Code".
The "Lookup Type" field is filled and non-editable.
Specify Internal Name, Display Name and
Description. Internal Names and Display Names
must be unique within the lookup type. Click OK Lookup Code
to add new look up code definition.

Defining Function Activities

A function activity is piece of work, which represents a PL/SQL stored procedure that Workflow Engine executes
automatically. Examples: Create Supply - Line, Interface Shipments from Depot, Is Service Completed?

The functions can be classified into three types:

Oracle seeded functions, redefined functions and
custom functions with custom PL/SQL code. The
redefined functions are defined by reusing Oracle
standard workflow (seeded) function code, primarily
standard Workflow functions like BLOCK, WAIT,
etc. Examples: Interface Orders to Depot (Redef),
Interface Shipments from Depot (Redef)

To create a function, right click on Functions and

choose "New Function". Specify Internal Name,
Display Name and Description. Specify the name of
the function (PL/SQL stored procedure) you want
this activity to execute, which is either Oracle seeded
function names such as WF_STANDARD.BLOCK Function Activity
or custom coded procedures such as
OMWF_DEMO.IS_SERVICE_COMPLETED. If the activity is to return result to branch out the process, choose
appropriate lookup type in Result Type. Optionally change the icon to give better graphical representation of the
function. Oracle has many seeded icons. You can also add your own icons to the list.

Defining Messages
A message is the information that a notification activity sends to a user or role. The message may prompt for a
response or may simply provide information. Example: Overshipped Beyond Tolerance.

To create a message, right click on Messages and choose "New Message". Specify Internal Name, Display Name,
Description and Priority. Select the "Body" tab, specify the subject. Either type the body text or import an HTML
file. If you want the notification message to prompt the performer for a response value and you want Oracle
Workflow to interpret that response value as the result of the notification activity, select the Result tab page and
complete the information requested. Specify a display name, description and a lookup type.
 Message Message Body

The lookup type you select should be identical to the lookup type specified for the notification activity's result type.
Click OK to save message.

Defining Notification Activity

A notification is an activity that sends messages to
a user or role. Messages and Notifications are
defined in pairs. Example: Overship Beyond
Tolerance (Notification when a line is shipped
beyond its overshipment tolerance).

To create a notification, right click on Messages

and choose "New Notification". Specify Internal
Name, Display Name and Description. Optionally
change the icon. Indicate the result type (a
predefined Lookup Type) for this activity, which
must be same as that of associated message. You
can optionally specify a PL/SQL stored procedure
in the Function field. The procedure is known as a Notification Activity
post-notification function. Workflow Engine
executes this post-notification function in RESPOND, FORWARD, TRANSFER or TIMEOUT mode depending on
whether the recipient responds to, forwards, or transfers the notification or whether the notification times out.

Defining Processes
A process is a combination of several activities such
as functions, notifications and other processes
connected in a flow to accomplish a specific business
task. Examples: Line Ship - Line, Manual (Custom),
Line Flow - Generic, Line Flow - Depot Repair
(custom) and Ship - Line, Manual.

Process allows features like branching, looping,

timeouts, synchronization with other flows and many
other features. Our examples demonstrate branching
and looping features only. Refer to Oracle Workflow
User's guide for all of the features that are supported
and their descriptions.
Process Activity
Defining processes consists of two steps: defining process (properties) and defining flows (process diagram) with
activities and their relations.

To define processes, click plus sign right next to "OM Order Line", then right click on Processes and choose "New
Process". Specify Internal Name, Display Name and Description. Internal Name and Display Names should be
unique process names. Optionally change the icon. Choose Result Type from lookup codes list, if the process is
returning a result. For example, "Ship - Line, Manual (custom)" process returns "Ship Results". Check Runnable, if
this is a top-level process that could be a stand-alone workflow. Examples: Line Flow - Field Service. If unchecked,
this process can only be used as a sub-process and cannot be run directly by Workflow Engine. Example: Ship -
Line, Manual (custom) is a sub-process that is used only in Line Flow - Field Repair (custom) process.

Defining Process Flow

Next step is to define the process flow. Highlight the process and double click to open the process window. The
Process window in Oracle Workflow Builder graphically represents the activities (icons) and transitions (arrows) for
a particular process. Each activity is a node, a logical step that contributes toward the completion of a process.
Arrange your Navigator window on left side and Process window on right side as show in figure.

Nodes

Drag and drop the activities (functions, processes and notifications) from the navigator tree window into the Process
window. Edit the properties to specify information specific to this node by double-clicking the node. Indicate if the
node is start or end activity in the process. "Normal" is the default value. Each process must start with at least with
one start node and end with at least one end node. You can have multiple start and end activities. The number of end
nodes are determined by the number of results this process returns, which is equivalent the number of lookup codes
defined for the lookup type that is used as Result Type for this process. For end node, choose the "Result" from the
list.

Optionally, you can also specify timeout type and time, if applicable. Usually notifications are defined with
timeouts. Also, specify the "Performer" for notification activities. Performer is usually a User, or a Responsibility.
Click OK to save.

You can also use seeded workflow standard functions such as WAIT, NOOP, START, END and COMPARE
DATE, etc as nodes. For example, WAIT function is used in Ship - Line, Manual (custom) to pause the process for 6
hours, if the service is not completed. WAIT function's node attributes determine the wait time. To specify these
values tab to "Node Attributes". Choose the "Wait Mode" attribute and set its value to "Relative Time", and then
choose "Relative Time" attribute and enter "0.25" in the value. Similarly any function, including custom functions
can have attributes and its values assigned.
Transitions

To tell workflow how to move from one activity to the next, connect the nodes (activities) with lines called
Transitions. Transitions appear as arrows in your diagram and represent the completion of one activity and the
activation of another.

To draw lines between nodes, right click on the starting activity, hold down, move the cursor onto the next activity
and release it on the next activity in the flow. If you are drawing a line from an activity that returns a result, when
you release, a window pops up with choices. Choose one of the values or "Default". You must connect to the
destination nodes for all possible results of starting node. You may ignore some results by using "Default" path.
Workflow Engine chooses the Default path, if there is no path defined for the result returned by the node.
By right clicking the line, you will be able to change the result label, hide the label, delete the line, or straighten the
line.

Validating Definitions
Before saving the definitions in the database, you must check for any definition errors. Workflow Builder validates
the process definition to ensure that it conforms to specific process design rules.

To validate, choose "Verify" from File menu from the navigator window. A window pops with objects that are in
error. You can see detail errors by clicking plus sign. If the list too large you can copy it to a word document by
clicking "Copy" button and paste in the word document.

Upload Definitions to Database

You must save your definitions in the database, in order to test and use them. Choose "Save as" from File menu and
Choose database. Fill in the login information and click OK to save in the database. You can also save a definition
to the database to be effective at some future time by specifying value in "Effective". The default is system date.

Writing Custom Code

You can develop custom stored procedure code and crate stored procedures, for your custom functions, anytime
before testing or executing the flow. All of these stored procedures must follow Oracle standard Workflow API
format. The Workflow procedures must have five parameters: Item Type, Item Key, Activity Id, Function Mode,
and Result Out. These parameters are used by Workflow Engine to identify the stored procedure and execute it.

Item Type is the internal name of the item type. The internal name of "OM Order Lines" is OEOL. Item key is a
string that represents the primary key for the item type. Line Id is the item key for "OM Order Lines". Activity Id is
the ID number of this procedure in Workflow database definitions. You need not worry about this ID number while
writing the procedure, as Workflow Engine gets this ID of the activity from its predecessor activity. Function Mode
is execution mode of the activity such as "RUN', "CANCEL" and "ERROR".

Result Out represents the result that is returned by the stored procedure upon the completion. The valid values are
COMPLETE, WAITING, DEFERRED, NOTIFIED and ERROR followed by other information. For example, if the
function activity returns a result to branch out the process then you need to pass the result code (Internal Name of
the Lookup Code) followed by COMPLETE. These are separated by column (:). Refer to Oracle Workflow User's
Guide for exact syntax.

Order Management Setup

To use the Workflows in Order Management, you need to define order and line transactions types and assign
workflows to the transaction types.

First, define you line transaction types using "Transactions Types" window. Workflow is not assigned to line level
transaction types directly. Specify required Order Management information only. Examples: SERVICE ORDER
LINE - FIELD, SERVICE ORDER LINE - DEPOT.

Next, define header transaction type. In "Order Workflow" filed, choose "Order Flow - Generic" or any valid order
workflow. Specify a line transaction type in the "Default Order Line Type" and other required OM information.
Save the record.

Click "Assign Line Flows" button to associate the line transaction types and line workflows to an order transaction
type. Enter line transaction type in the "Line Type" filed. For example choose "SERVICE ORDER LINE - FIELD"
for "SERVICE ORDER" order transaction type. Optionally specify item type to restrict the flow to a specific user
item type. Enter a valid "OM Order Line" workflow in the "Process Name" field. For example, enter "Line Flow -
Field Service (custom) for "SERVICE ORDER LINE - FIELD" line type. Specify a start date. Save record. You can
also associate multiple line transaction types to an order transaction type. While entering the order line, you can
choose one of the valid line types in the line transaction type to choose appropriate workflow for that line. If it is not
specified, OM takes the default line transaction type from order transaction type definition.

Now we are ready to enter order and process the orders using the custom workflows.

Monitoring Workflow Status

You can view detailed workflow status information for an order line or order header by clicking the Tools menu and
selecting Workflow Status. A web browser window pops up and shows the status of each node that has been started
in the flow. It also lists the errors occurred, if any, during the order process at any node. You may analyze these
errors by clicking the associated links.

You can submit these error records for re-processing once the error associated is resolved. To resubmit, login as
SYSADMIN and choose System Administration responsibility. Navigate to "Worklist" (web browser). Web
Browser window opens and shows all of the order headers and lines that are in error, along with other workflow
errors and notifications. You can shortlist this by finding specific record. Select the rows by checking the "Select"
box and submit for re-processing. Optionally, you can reassign to other users or responsibilities.

Summary
This paper is an effort to put together the customization process very specific to Order Management workflows and
general techniques used in customizing them. It only explains the process and basic concepts of customization.
Many advanced Workflow topics are not covered such as synchronizing two levels of workflows using custom code,
etc.

The customization process includes: planning workflow, making local copy of the seeded workflows, defining the
various objects (attributes, lookup types, messages, notification and function, and processes), creating the process
diagram, and verifying and saving.

This paper also talks about classifying the level of customizations such as simple rearranging standard functions,
notifications and processes; including redefined functions out of seeded functions with more meaningful names
specific to the business in the workflows; using custom code as external triggers with the help of standard workflow
functions and using custom coded workflow functions. In Order Management major functionality is implemented as
external triggers. The best examples are “Booking” and “Pick Release”.

Best source of reference is seeded Oracle Order Management workflows. Refer to OM seeded workflows before
even planning to make the customization process easy.

Further Reference
1. Oracle Workflow User's Guide
2. Oracle Order Management User's Guide
3. Oracle System Administration User's Guide
4. Oracle Applications Object Library Technical Reference Guide.

Copyright © 2000 by Subhash V. V. Koppana