Oracle Order Management Workflow Validation

White Paper for End Users of Oracle Applications 11i

May 2005


Order Management Workflow Validation Page 1
Table of Contents
INTRODUCTION 2
OVERVIEW 3
VALIDATION IN THE TRANSACTION TYPES FORM 4
VALIDATION BY CONCURRENT PROGRAM 7
CONCLUSION 9

Order Management Workflow Validation Page 2
Introduction

In Oracle Applications 11i, Oracle Order Management is closely integrated with Oracle
Workflow. This relationship is a key factor in making OM more flexible and easier to
extend by its customers. Yet, the experience has been that extensions and customizations
sometimes lead to imperfect and faulty workflow designs that cause problems, errors, and
even data corruption which is not readily apparent and can only be corrected by data fix
scripts provided by Oracle Support or, even more often, Oracle Development. To help
OM customers evaluate and validate their proposed workflow extensions and
customizations before they are used in order processing, Development is introducing
functionality called OM Workflow Validation.


Order Management Workflow Validation Page 3
Overview

Order Management validates assigned workflow processes in two of its modules: the
Transaction Types form and the new concurrent program Validate OM Workflow.

The Transaction Types form is the logical place to enforce workflow validation,
because this is where top-level (runnable, in Oracle Workflow terminology) workflow
processes are assigned to transaction types, whether order or line types. Here, validation
fires:

1) When the operator enters a Fulfillment Flow different from the one saved in the
database and attempts to save or navigate out of the current record,
2) When the operator enters or changes the Navigation Flow and navigates out of the
field,
3) When, in the Line Workflow Assignments window of the form, a row is entered
or changed and the operator tries to save or navigate out of the current record.

Validation in the Transaction Types form is implicit and cannot be avoided. It does not,
however, check for all possible faults in workflow process design, but only those which
are serious enough and do not exact too high of a toll on performance in the form. In
addition, due to the potentially extreme complexity of workflow process design,
automated validation may not be conclusive in the case of some subtle potential error
conditions, and hence not warrant preventing the operator from saving the workflow
assignment. Because of these considerations, the complete workflow validation is only
done by the Validate OM Workflow concurrent program. The program can be started
either by clicking on the new Validate Workflow button in the Transaction Types form,
or by submitting it from the Order Managements Run Requests window. It is seeded in
the request group OM Concurrent Programs and takes an optional parameter Order Type.

Order Management Workflow Validation Page 4
Validation in the Transaction Types Form



The following errors are captured in the Transaction Types form:

1) "Activity &ACTIVITY_LABEL in process &PROCESS_NAME has no
OUT transition."

This means that an activity within the workflow process assigned to the order or line
type is missing the definition directing where the flow goes after that activity is
completed. Suppose that the fulfillment flow @demo_Order Flow Generic assigned
to order type Order Only2 as shown in the screen shot above contains a subprocess
Demo_Close Order defined as follows:


Order Management Workflow Validation Page 5


The actual error reported in the form would read: "Activity WAIT in process
R_STANDARD_HEADER-8 (@demo_Order Flow Generic) has no OUT
transition."

The error message refers to runnable workflow processes both by their internal name
(R_STANDARD_HEADER-8), visible in Oracle Workflow Builder when View ->
Developer Mode is turned on, and their display name (@demo_Order Flow
Generic). The latter is the same name displayed in the Transaction Types form.
Activities within a workflow process are denoted by their internal name or the label
(WAIT) used for unique identification within the parent process.

2) Attributes of activity &ACTIVITY_LABEL in process
&PROCESS_NAME are incorrectly defined.

This error will be raised for activities assigned the standard API
Wf_standard.Waitforflow() which either are (1) missing activity attributes
Continuation Activity or Continuation Flow, or (2) the Continuation Flow has the
value Detail in an OM Order Line (OEOL) workflow or the value Master in an OM
Order Header (OEOH) workflow. The same error will also be raised for activities
assigned the standard API Wf_standard.Continueflow() with missing attributes
Waiting Activity/ Waiting Flow, or with incorrect values for those attributes.


Order Management Workflow Validation Page 6
3) "Process &PROCESS1 is missing activity &ACTIVITY1, which is defined as
the waiting/continuation activity of activity &ACTIVITY2 in process
&PROCESS2."

This error also relates to activities assigned Wf_standard.Continueflow()/
Waitforflow() APIs. In this case, however, ACTIVITY1 is stated as the Continuation
Activity or Waiting Activity for ACTIVITY2 in PROCESS2, but is missing from
PROCESS1. PROCESS1 is an order header workflow, and PROCESS2 is an order
line workflow associated with PROCESS1 in the Transaction Types form, or vice
versa.

4) "Process &PROCESS_NAME is missing activity
&FULFILLMENT_ACTIVITY referenced in activity &FULFILL_LINE."

The activity referenced in the attribute Fulfillment Activity Name of the
FULFILL_LINE (Fulfill) activity does not exist in the parent process
&PROCESS_NAME.

5) "Process &PROCESS is incompatible with item type &ITEM_TYPE."

Like the previous one, this error is also only applicable to order line workflows. Some
of the seeded line flows, such as Line Flow - ATO Item, Line Flow - ATO Model,
Line Flow - OTA Item, etc., are only compatible with certain Order Management
item types (ATO item, ATO model, education (OTA) item, etc.). The error is raised if
the operator attempts to assign such a workflow to any other OM item type, or to all
OM item types.

6) "Process &PROCESS may be incompatible with item type &ITEM_TYPE.
Please make sure that is not the case before saving this assignment."

This is similar to the previous situation, but is reported for workflows with names
similar to the seeded names of the specialized workflows mentioned there, which
makes it likely that they were derived from them and therefore still incompatible with
other OM types. This message, however, is only a warning. The operator is still able
to save such an assignment after acknowledging it.


Order Management Workflow Validation Page 7
Validation by Concurrent Program

As mentioned earlier, the new concurrent program can be started by clicking on the
Validate Workflow button in the Transaction Types form, in which case it is submitted
only for the transaction (order) type of the current record. If there are unsaved changes in
the form at the time, the system will require them to be saved before submitting the
concurrent request. The request id is displayed after the submission. The job will perform
a complete validation of all OM Order Header (OEOH), OM Blanket Header (OEBH),
OM Negotiation Header (OENH) and OM Order Line (OEOL) processes associated with
the particular order type.

Of course, Validate OM Workflow can also be submitted independently, just like most
other OM concurrent programs. If no value is given for the parameter Order Type, then
all active order types are validated. If a specific Order Type parameter is stated, it is
validated even if it is currently not active.

In addition to the errors already mentioned in the previous paragraph, the concurrent
program also reports the following conditions:

1) "Activity &ACTIVITY in process &PROCESS defers workflow with zero
delay within a processing loop, which is not allowed."

This message is reported for standard WAIT (Wait) or Defer Thread (DEFER)
activities placed inside a loop in the workflow process definition. The Wait activity
has Wait Mode of Relative Time and Relative Time specified as zero (or null). Such a
definition may cause infinite loops in Workflow Background concurrent programs
processing runtime workflows and they may appear never to complete.

2) "Please verify that the value for attribute WAIT_RELATIVE_TIME of
activity &ACTIVITY in process &PROCESS is greater than the average
time it takes Workflow Background Process to complete."

Similar to the previous case, Workflow Background process for deferred activities
operates in a loop that dequeues activities from the deferred activity queue as long as
there are any available. If a WAIT activity is defined in a loop within its parent
process, and if there are only a few activities in the loop with it, they may all
complete very quickly, and the same WAIT activity will be enqueued again in the
deferred activity queue. If the Relative Time (for the Wait Mode of Relative Time) of
the activity is short enough, it is plausible that the time will have expired before that
very same Workflow Background process is done processing all other deferred
activities ahead in the queue. In that case, it will process the WAIT activity again. If
there are enough active workflow items in the same situation, it can lead to the
infinite loop and the concurrent program never completing, just like in the previous
scenario.


Order Management Workflow Validation Page 8
3) "Please verify that activity &ACTIVITY1 precedes &ACTIVITY2 in process
&PROCESS_NAME."

It is near impossible to programmatically establish with absolute certainty, in every
conceivable workflow design, if a particular activity comes before another one. The
users are therefore prompted to make sure of that in some cases.

4) "Process &PROCESS_NAME is missing activity &ACTIVITY_NAME."

This condition is checked for OM Order Header activities BOOK_ORDER (Book)
and CLOSE_HEADER (Close), and OM Order Line activities FULFILL_LINE
(Fulfill) and CLOSE_LINE (Close). For most OM implementations, all of these are
required.

5) "Please verify the value specified for attribute WAIT_ABSOLUTE_DATE in
activity &ACTIVITY of process &PROCESS_NAME."

Using the WAIT activity with Wait Mode of Absolute Date has a very limited usage,
and is most likely an error, rather than elaborate design. That is why this warning is
displayed whenever such an activity is encountered.

Order Management Workflow Validation Page 9
Conclusion

As mentioned above, only a subset of workflow validation is enforced while assigning
workflows to transaction types in OM Transaction Types form. Further, it is possible that
workflow processes and definitions can be altered using Oracle Workflow Builder after
they have already been assigned. Therefore, it is strongly recommended that Order
Management users do the following:

1) Run the Validate OM Workflow concurrent program using the Validate
Workflow button whenever adding or changing workflow assignments (whether
for fulfillment flows, negotiation flows or line flows) in the Transaction Types
form.

2) Schedule Validate OM Workflow to run periodically for all order types (no
parameters specified).

For both operations, check the output of the program carefully. Correct all reported errors
and heed all warnings. It is well worth it, because it may prevent many of the runtime
data corruption errors which may be hard to fix and even harder to detect on time.






Order Management Workflow Validation Page
10


Oracle Order Management Work Flow Validation
May 2005
Author: Srecko Bartl

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
Web: www.oracle.com

This document is provided for informational purposes only and the information herein is
subject to change without notice. Please report any errors herein to Oracle Corporation.
Oracle Corporation does not provide any warranties covering and specifically disclaims
any liability in connection with this document. Oracle is a registered trademark, and
oracle Order Management (are) a trademark(s) or registered trademark(s) of Oracle
corporation. All other names may be trademarks of their respective owners.
Copyright Oracle Corporation 2000
All Rights Reserved