In Oracle E-Business Suite, Oracle Order Management is closely integrated with Oracle Workflow. This relationship is a key factor in making Oracle Order Management more flexible and easier for customers to extend. Sometimes, however, extensions and customizations can result in imperfect workflow designs that lead to 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 Oracle Development. To avoid these problems, OM Workflow Validation helps Oracle Order Management customers evaluate and validate their proposed workflow extensions and customizations before they are moved into production.
Oracle Order Management validates assigned workflow processes in the Transaction Types window and with the Validate OM Workflow concurrent program. The Transaction Types window is the logical place to enforce workflow validation, because this is where top-level (“runnable”) workflow processes are assigned to transaction types. Here, validation is performed when:
The user enters a fulfillment flow different from the one saved in the database and attempts to save or navigate out of the current record
The user enters or changes the negotiation flow and navigates out of the field.
In the Line Workflow Assignments window, a row is entered or changed and the user tries to save or navigate out of the current record.
Validation in the Transaction Types window is implicit and cannot be avoided. It does not, however, check for all possible faults in workflow process design, but only those which would cause serious problems and which do not exact a high toll on performance in the window. In addition, due to the potential complexity of workflow process design, automated validation may not be conclusive in the case of some subtle potential error conditions, and therefore not warrant preventing the user from saving the workflow assignment. Because of these considerations, exhaustive workflow validation is only performed by the Validate OM Workflow concurrent program. The program can be launched by clicking on the Validate Workflow button in the Transaction Types window or by submitting it from the Run Requests window. The concurrent program is in the request group OM Concurrent Programs and takes an optional parameter Order Type.
Validation in the Transaction Types window
The following errors are captured in the Transaction Types window.
"Activity &ACTIVITY_LABEL in process &PROCESS_NAME has no OUTtransition."
This error means that in the workflow process assigned to the order or line type, an activity is missing the definition that determines where the flow goes after that activity is completed. For example, suppose that the fulfillment flow @demo_Order Flow – Generic is assigned to the order type Order Only2 as shown in the image above, and that the flow contains the subprocess Demo_Close – Order, which is defined as shown in the image below:
The actual error reported in the window would read: "Activity WAIT in process R_STANDARD_HEADER-8 (@demo_Order Flow – Generic) has no OUT transition."
The error message refers to a runnable workflow processes both by its internal name (R_STANDARD_HEADER-8), visible in Oracle Workflow Builder when View -> Developer Mode is turned on, and its display name (@demo_Order Flow – Generic). The latter is the same name displayed in the Transaction Types window. Activities within a workflow process are denoted by their internal names or by the labels (such as WAIT) used for unique identification within the parent process.
“Attributes of activity &ACTIVITY_LABEL in process &PROCESS_NAME are incorrectly defined.”
This error is raised for activities assigned the standard API Wf_standard.Waitforflow() for which either:
The activity attributes Continuation Activity or Continuation Flow are missing.
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.
This error is also raised for activities assigned the standard API Wf_standard.Continueflow() for which either:
The attributes Waiting Activity or Waiting Flow are missing,
The values of these attributes are incorrect.
"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 either Wf_standard.Continueflow() or 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 window, or vice versa.
"Process &PROCESS_NAME is missing activity &FULFILLMENT_ACTIVITY referenced in activity &FULFILL_LINE."
This error means that the activity referenced in the attribute Fulfillment Activity Name of the FULFILL_LINE (Fulfill) activity does not exist in the parent process &PROCESS_NAME.
"Process &PROCESS is incompatible with item type &ITEM_TYPE."
This error only applies to order line workflows. Some of the seeded line flows, such as Line Flow - ATO Item, Line Flow - ATO Model, and Line Flow - OTA Item, are only compatible with certain OM item types (ATO item, ATO model, education (OTA) item, and so on). The error is raised if the user attempts to assign such a workflow to any other OM item type, or to all OM item types.
"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 custom workflows with names similar to the seeded names of the specialized workflows mentioned there, which makes it likely that the custom workflows were derived from the seeded workflows, and therefore still incompatible with other OM item types. This message, however, is only a warning. The user can still save such an assignment after acknowledging the warning.
When the Validate OM Workflow concurrent program is submitted via the Validate Workflow button in the Transaction Types window, the request is submitted only for the transaction (order) type of the current record. Unsaved changes in the window must be saved before the concurrent request is submitted. The request ID is displayed after submission. The program 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.
The Validate OM Workflow concurrent program can also be submitted independently, like most other OM concurrent programs. If no value is given for the Order Type parameter, then all active order types are validated. If a specific Order Type parameter is specified, it is validated even if it is currently not active.
In addition to the errors already mentioned previously, the concurrent program reports the following conditions:
"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 (Defer Thread) activities that are 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 processes that are processing runtime workflows, which may appear never to complete.
"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, the Workflow Background process for deferred activities operates in a loop that removes activities from the deferred activity queue as long as there are any activities available. If a WAIT activity is defined in a loop within its parent process, and if there are only a few other activities in the loop with it, they may all complete very quickly, and the same WAIT activity will be again be added to the deferred activity queue. If the relative time (for the Wait Mode of Relative Time) of the activity is short enough, the time may expire before the 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 too many active workflow items in the same situation, an infinite loop may result, in which the concurrent program never completes.
"Please verify that activity &ACTIVITY1 precedes &ACTIVITY2 in process &PROCESS_NAME."
It is nearly impossible to programmatically establish with absolute certainty, in every conceivable workflow design, whether a particular activity comes before another one. Therefore, in some cases, the user is prompted to verify the order of activities.
"Process &PROCESS_NAME is missing activity &ACTIVITY_NAME."
This condition is checked for the OM Order Header activities BOOK_ORDER (Book) and CLOSE_HEADER (Close), and for the OM Order Line activities FULFILL_LINE (Fulfill) and CLOSE_LINE (Close). For most OM implementations, all of these are required.
"Please verify the value specified for attribute WAIT_ABSOLUTE_DATE in activity &ACTIVITY of process &PROCESS_NAME."
Use of the WAIT activity with Wait Mode of Absolute Date has a very limited application, and is often an error rather than a deliberate part of a workflow design. Therefore, this warning is displayed whenever such an activity is encountered.
To conclude: Because only a subset of workflow validations are enforced through the OM Transaction Types window and because workflow processes and definitions may be altered using Oracle Workflow Builder after they have already been assigned, it is strongly recommended that Oracle Order Management users do the following:
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 window.
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, because they are designed to prevent runtime data corruption errors that are difficult to detect and difficult to correct.