This chapter covers the following topics:
This chapter provides guidelines to follow for extending the Oracle Order Management seeded workflow processes to meet your business needs. Oracle supports the extension of workflows. Extensions include using existing seeded subprocesses to build new workflow processes and modifying parameters of a subprocess without changing process logic (for example, changing the wait period of the Wait activity from month end to daily).
If the Oracle Order Management seeded workflows do not meet your business processing needs, you can create new flows by using any of the following methods:
Copy a seeded order or line flow, change its internal name, display name, and description in the Oracle Workflow Builder. Change the definition as desired. When you copy a flow, do not delete any of the seeded activities.
Use the seeded flows as examples to create new order or line flows using the seeded functional subprocesses and include your own custom activities in the Oracle Workflow Builder.
Warning: Oracle provides support only for its seeded activities, processes, and the type of extensions described in this manual. Oracle does not provide support for your custom activities and processes.
A customization changes the logic of the core application. Oracle does not support customizations to seeded workflows. Examples of customizations include:
Adding a new custom header activity that checks whether the order exceeds a certain currency amount, and performing special logic based on the amount.
Using a third party invoicing module instead of Oracle Accounts Receivable for invoice interface; this creates a new activity to populate the custom tables.
Changing the basic logic of a seeded subprocess, such as Book - Order, Manual. Adding or deleting activities from a seeded subprocess alters seeded data. However, you can copy and rename Book - Order, Manual and then insert a notification function activity.
Modifying drop-ship logic.
Modifying the integration of Oracle Order Management with another application such as Oracle Service.
Warning: Customization refers to the modification of the logic of a process or subprocess, and is not supported by Oracle.
The following exceptions are supported by Oracle:
You may change the item attribute OM WF Administrator to another responsibility (it defaults as SYSADMIN). The OM WF Administrator item attribute is available for both the seeded OM Order Header and OM Order Line item types.
You may tailor message bodies on seeded messages to meet your business needs.
Note: Any patch containing the workflow definition file will override the message. If this occurs, copy the main flow and the message, then use the message in your custom flow.
You can set the default error process of RETRY_ONLY on any new functions, processes or flows that you define.
Note: The RETRY_ONLY error process supports retrying only of the activity in an error state. RETRY_ONLY does not support aborting the flow or skipping the activity in an error state. Do not specify any other error process. Do not leave the error process field empty.
For more information about extending workflows or to learn how to create your own workflows, refer to the Oracle Workflow User's Guide.
When extending existing workflows to meet your business needs, always copy the seeded process and rename both the internal and display names before modifying the workflow. This process ensures that you do not modify seeded data. It also prevents patches containing the.wft files (which contain all the seeded flows and related information) from overriding your modifications.
Warning: If you modify any of Oracle's seeded workflow data, your changes are not supported. Any changes to the seeded workflow data are overwritten when a patch containing the .wft file is applied.
For example, you should not directly change the Book - Order, Manual subprocess by adding or deleting activities from it. Copy and rename what you want to change before making modifications. Do not modify predefined data; this includes all function activities, subprocesses, processes, and item attributes.
Always modify a copy of a subprocess instead of function activities. For example, use the seeded Book - Order, Manual subprocess rather than the seeded Book function activity. The subprocess is designed to handle exceptions, and it may perform other functions as well. For example, the Create Supply Order - Line, Manual subprocess not only creates supply, but also determines whether an item is sourced internally or externally.
Once you have modified an order or line flow, assign it to an order or line type. For more information about assigning workflows to transaction types, refer to Assigning Workflows to Transaction Types.
Oracle Order Management requires that some workflow events occur before others. This creates certain dependencies that should not be violated. For example, shipping is dependent on booking and therefore cannot occur after booking.
The following list describes dependencies in Oracle Order Management:
Order lines wait for booking before continuing their flow. Order lines should not invoice until after booking occurs.
Order level booking is required and should not be removed.
Lines should not interface to Oracle Invoicing until after shipping occurs (if a shipping activity exists in the process).
Close - Order and Close - Line are mandatory steps in header and line processes, respectively.
All order header processes are created as parent flows. Processes for lines on orders are created as child (detail) flows.
Wait for Flow and Continue Flow workflow utilities support the order (parent) - line (line or detail) coordination. The Book - Continue Line (Complete) function activity is part of the Book - Order, Manual subprocess. The Wait for Booking function activity is part of the Enter - Line subprocess. The line flow waits for the header level Book - Order, Manual subprocess to complete before the lines continue.
There are several ways to extend workflow processes without violating the Oracle Order Management dependencies. The following are several examples of extending workflow:
You can construct a flow using only seeded sub-processes from Order Management. If the necessary dependency requirements are met, this is considered extending, and is not a customization.
You can change the WAIT period of a seeded WAIT function activity. For instance, by default the Header Close Order sub-process will wait until the end of the month before closing the order. You could change it to wait for a different period of time.
You could add a standard WF notification to a flow. For example, you might want to send a simple FYI notification before invoicing a line, or send a Yes/No approval notification before invoicing.
You could add a Time Out transition such that if there is no response to a notification, the Line or Header might proceed after a defined period of time.
Note: Oracle Order Management supports only standard WF notifications: either an FYI notification or a notification requiring a response. Notifications that call stored PL/SQL procedures are not supported.
When extending workflow processes to meet your business needs, stay within the following guidelines:
All order header processes should include the Close - Order subprocess. All line level processes should include the Close - Line subprocess.
The order header process should contain either Book - Order, Manual or Book - Order, Deferred, and the line level process should include Enter - Line.
Do not design a line level process that conducts invoice interface before it shipping.
Include the functional subprocess that represents the business process you are needing. If a line must conduct invoice interface, select a subprocess which performs that particular function. For example, you must include the invoice interface supprocess instead of just including the invoicing activity.
Some workflow function activities must be configured. This is done by setting the function activity attributes. For example, with a notification activity you must set up a performer (recipient). If you use Utility - Set Notification Approver to enable you to send notification to the user/responsibility specified in the Notification Approver profile option, you must also specify the user/responsibility in the profile option.
Always specify OMERROR/R_ERROR_RETRY as the default error process for any workflow activity you define.
Note: It is recommended that you include the Fulfill activity before invoice interface. Please refer to the Fulfill activity for further details.
More Guidelines on Extending Workflow
If you are extending the seeded Order Management workflows to add workflow custom activites, please refer to the standards and procedures in the Oracle Workflow Developer's Guide. All PL/SQL stored procedures that are called by function or notification activities in an Oracle Workflow process should follow this standard API format so that the Workflow Engine can properly execute the activity.
The Workflow Engine traps errors produced by function activities by setting a savepoint before each function activity. If an activity produces an unhandled exception, the engine performs a rollback to the savepoint, and sets the activity to the ERROR status. For this reason, you should never commit within the PL/SQL procedure of a function activity. The Workflow Engine never issues a commit as it is the responsibility of the calling application to commit.
For environments such as database triggers or distributed transactions that do not allow savepoints, the Workflow Engine automatically traps "Savepoint not allowed" errors and defers the execution of the activity to the background engine.
If you must use a commit/rollback, please ensure that your extension is built as an autonomous transaction that insulates the main transaction by establishing the savepoint. Adding Commit/Rollback will interfere with the referential integrity of the application and will cause data corruption and exceptions that will stop the flow of an order or its line.
This section discusses possible extensions to the seeded Oracle Order Management workflows. The extensions listed do not violate Oracle Order Management dependencies, change core logic, or violate the rules for modifying a subprocess.
Note: Always remember to copy the seeded process or subprocess and rename both the internal and displays name before making any modifications.
Complete the following steps to modify the Close - Order subprocess to close orders more frequently than month-end.
Copy and rename the internal and displays names for the Close - Order subprocess.
Modify the Wait function activity in the copied and renamed Close - Order subprocess. If you want the orders to close twice a day, open the property sheet of the Wait activity, select the Node Attributes tab and set the Wait Mode to Relative Time, and set the Relative Time attribute to a value of .5.
Drag and drop this subprocess into your new header level process. Remember to modify the internal and display names of this new process.
Attach your new process to a Transaction Type.
You can extend processes and subprocesses by adding approvals. Refer to the Oracle Workflow User's Guide for more information about approvals.
One way to extend a workflow process using an approval is to add an approval to the header before booking. To create a process with this approval, complete the following steps:
Copy and rename the internal and displays names for the header level booking subprocess (Book - Order, Manual or Book - Order, Deferred).
Create the approval message and notification. For more information about creating messages and notifications, refer to the Oracle Workflow User's Guide.
Insert the approval notification function activity into the subprocess so that the approval occurs before booking.
Save your new subprocess and drag and drop it into a header level flow process (one that has been copied and renamed for your extensions).
Select the performer of the notification.
Set up a Transaction Type in Oracle Order Management that uses your new header process flow.
For more details on creating and extending workflows refer to the Oracle Workflow User's Guide.
Another way to extend a workflow process using an approval is to require approval for all standard line processes before a Ship activity can occur. To create a process with this approval, complete the following steps:
Copy and rename the internal and displays names for the line level subprocess (such as Line Flow - Generic).
Create the approval message and notification. For more information about creating messages and notifications, refer to the Oracle Workflow User's Guide.
Set the performer of the notification.
Insert the approval notification function activity into the subprocess so that the approval occurs before booking.
Assign your new line process to a Transaction Type in Oracle Order Management.
For more details on creating and extending workflows refer to the Oracle Workflow User's Guide.
Another extension available at the order header level is to create a process with deferred booking. To create a process with deferred booking, complete the following steps:
Copy and rename the internal and displays names for the order level process you want to extend (such as Order Flow - Generic).
Remove the Book - Order, Manual subprocess.
Insert the Book - Order, Deferred subprocess in place Book - Order, Manual.
Save your new process and assign it to a Transaction Type in Oracle Order Management.
The time-out transition option is another way to extend workflow to meet business requirements. In the case of quotes, for example, a yes/no approval function activity is inserted before Book - Order, Manual or Book - Order, Deferred. If approved the order continues to the booking subprocess. The order closes if either of the following conditions occur:
The approval is rejected.
There is no response within 30 days.
To set up such a process with a time-out transition, complete the following steps:
Copy and rename the internal and displays names for the line level subprocess (such as Line Flow - Generic).
Create an approval message and notification. For more information about creating messages and notifications, refer to the Oracle Workflow User's Guide.
On the Node tab of your notification define a time-out. If you use the Relative Time time-out of 30 days, orders processed using this Transaction Type close after 30 days if the notification is not approved.
Set the performer of the notification.
Insert the approval notification function activity into the subprocess so that the approval occurs before booking.
Assign your new line process to a Transaction Type in Oracle Order Management.