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.
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
Oracle Apps Forms Personalization - (Demonstrated Example - (Shipping and Transaction Form) - Using Zooming, Global Variables, Local Variables, Passing Parameters Etc.,)