Oracle Workflow Developer's Guide Release 2.6.4 Part Number B15853-01

Contents

Previous

Next

Demonstration Workflow Processes

Sample Workflow Processes

The following sample workflow processes are included with Oracle Workflow. Each of these processes illustrates the integration of different Oracle Workflow features. You can use these processes to verify your installation of Oracle Workflow.

• Requisition Process - illustrates results-based branching, parallel branching, subprocesses, timeouts, looping, and integration of PL/SQL documents in a notification. See: Requisition Process.

• Event System Demonstration Processes - illustrate sending and receiving business events between two systems and using external Java function activities. See: Event System Demonstration.

You can set up and initiate these sample processes if you are using the standalone version of Oracle Workflow. If you are using Oracle Workflow embedded in Oracle Applications, you should consider these processes mainly as examples for explanation purposes and not for demonstration use. The files necessary to set up and run these demonstrations are not provided with the version of Oracle Workflow embedded in Oracle Applications.

You can initiate these sample workflows from the Workflow Demonstrations home page or the Launch Processes Web page. You can access the Workflow Demonstrations home page using the URL:

<webagent>/wf_demo.home

Note: You can also access the Workflow Demonstrations Web page from the Oracle Workflow home page. See: Accessing the Oracle Workflow Home Page, Oracle Workflow Administrator's Guide.

The Workflow Demonstrations home page displays your notifications Worklist in the right-hand frame and in the left-hand frame lists links that let you initiate each of the sample workflows from a different Web page.

Related Topics

Testing Workflow Definitions

Displaying the Process Diagram of a Sample Workflow

Displaying the Process Diagram of a Sample Workflow

You can view the process diagram of a sample process in the Process window of Oracle Workflow Builder.

Sample Process Diagram

To Display a Sample Process in Oracle Workflow Builder

1. Choose Open from the File menu. Connect to your Oracle Workflow database and select the item type you want.

   Alternatively, you can connect to any of the sample workflow definition files, located in the ORACLE_HOME\wf\data\<language> directory on your PC.

2. Expand the data source, then the item type branch within that data source.

3. Expand the Processes branch and then double-click on a process activity to display the process diagram in a Process window.

Requisition Process

The Requisition process is an example of a workflow process that is initiated when you create a new requisition to purchase an item. The Requisition process is based on two tables that store approval hierarchy and spending authority information.

When you submit a requisition in this demonstration, the process sends a notification to the next manager in the approval hierarchy to approve the requisition. If the spending limit of the approving manager is less than the requisition amount, the process forwards the requisition to the next higher manager in the approval hierarchy until it finds a manager with the appropriate spending limit to approve the requisition. Each intermediate manager must approve the requisition to move it to the next higher manager. Once a manager with the appropriate spending limit approves the requisition, the process ends with a result of Approve.

The process can end with a result of rejected if:

• Any manager rejects the requisition.

• The requisition amount is greater than the highest spending limit.

• The requisition's requestor does not have a manager.

You can set up and initiate this example process if you are using the standalone version of Oracle Workflow. If you are using Oracle Workflow embedded in Oracle Applications, you should consider this process mainly as an example for explanation purposes and not for demonstration use. The files necessary to set up and run this demonstration are not provided with the version of Oracle Workflow embedded in Oracle Applications.

Attention: For detailed information about runnable workflow processes that are integrated with Oracle Applications, refer to the appropriate Oracle Applications user's guide or online documentation. See: Predefined Workflows Embedded in Oracle E-Business Suite.

Attention: Oracle Self-Service Web Applications provides a predefined Requisition Process that is different from the version of the example process documented here. The example process documented in this section is for demonstration purposes only and not for production use.

This sample workflow is based on the demonstration data model. The data model includes two tables with data: one table maintains an employee approval hierarchy and the other maintains the spending limit of each employee. These two tables make up the database application that we use to approve a requisition. In addition, the data model also includes a directory service that identifies the Oracle Workflow users and roles in this sample implementation.

There are two ways you can initiate the Requisition process based on a fictitious requisition: run a script or submit a requisition using a Web-based interface. Both methods require that you provide the name of the employee who prepared the requisition, the requisition amount, the requisition number, a requisition description, a requisition process owner and the name of the workflow process to initiate.

This section describes the Requisition process in detail to give you an understanding of what each activity in this workflow accomplishes.

Related Topics

Installing the Requisition Data Model

Initiating the Requisition Workflow

The Requisition Item Type

Summary of the Requisition Approval Process

Requisition Process Activities

Summary of the Notify Approver Subprocess

Notify Approver Subprocess Activities

Sample StartProcess Function

Example Function Activities

Example Notification Activity

Installing the Requisition Data Model

The Requisition data model is installed only with the standalone version of Oracle Workflow. The data model is automatically installed for you by the Workflow Configuration Assistant. The files used in the installation are copied to the ORACLE_HOME/wf/demo and ORACLE_HOME/wf/<language> directories in your Oracle Workflow server directory structure.

Attention: For the Requisition process demonstration to work properly, you should perform the steps required to set up Oracle Workflow after the installation. See: Overview of Setting Up, Oracle Workflow Administrator's Guide.

The installation does the following:

• Calls the script wfdemou.sql to create a database account for each of the users listed in the seed data table shown below. The script creates public grants and synonyms so that these accounts have full access to Oracle Workflow's Web-based user interface.

  Attention: For security reasons, the installation process automatically locks these user accounts after they are created. Before you can begin using the accounts, you must unlock them using a script called wfdemoul.sql. This script is located in the ORACLE_HOME/wf/demo directory. Connect to the SYSTEM database account using SQL*Plus and run the script using the following command:

  sqlplus SYSTEM/<SYSTEM pwd> @wfdemoul
  

  See your Oracle DBA if you need more information about the SYSTEM account and password.

• Calls a script called wfdemoc.sql to create two tables with seed data. These tables make up the demonstration database application that is workflow-enabled:

  • WF_REQDEMO_EMP_HIERARCHY - maintains the employee approval hierarchy. The approval chain consists of these employee user IDs listed in ascending order with the employee having the most authority listed last: BLEWIS, KWALKER, CDOUGLAS, and SPIERSON.

  • WF_REQDEMO_EMP_AUTHORITY - maintains the spending limit for each employee. The limit for each employee follows the employee's user ID: BLEWIS:500, KWALKER:1000, CDOUGLAS:2000, and SPIERSON:3000.

• The script wfdemoc.sql also inserts seed data into the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables. The following table shows the users and roles that are seeded by the script.

  Demonstration Users and Roles

  User	ADMIN Role	MANAGERS Role	WORKERS Role	OTHERS Role
  SYSADMIN	yes
  WFADMIN	yes
  BLEWIS			yes
  KWALKER			yes
  CDOUGLAS			yes	yes
  SPIERSON		yes		yes

  Attention: Each user has an e-mail address of 'WFINVALID' and each role has an e-mail address identical to its role name. You can change the users' and roles' e-mail addresses to other values by calling the Directory Service APIs SetAdHocUserAttr or SetAdHocRoleAttr. Alternatively, if you want e-mail notifications for all the users and roles to go to a single e-mail inbox, you can specify a test e-mail address in the Test Address configuration parameter when you configure a notification mailer. For more information, please refer to the Oracle Workflow Manager sections of the Oracle Applications Manager online help for Oracle Workflow embedded in Oracle Applications, or to the Oracle Workflow Manager sections of the Oracle Enterprise Manager online help for standalone Oracle Workflow.

  Attention: Also all users except BLEWIS have a Notification Preference of 'MAILHTML', which allows them, in addition to viewing notifications from the Notifications Web page, to get individual notifications via e-mail. BLEWIS has a Notification Preference of 'SUMMARY', which allows him, in addition to viewing notifications from the Notifications Web page, to receive a periodic e-mail summarizing all his currently open notifications. Note that a notification mailer must be set up to deliver e-mail notifications.

  Attention: Your Oracle Workflow directory service views must map to the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables to include the users and roles of the Requisition data model. See: Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.

• Calls the scripts wfdemos.sql and wfdemob.sql to create the PL/SQL spec and body for packages called WF_REQDEMO and WF_DEMO. These packages contain:

  • The PL/SQL stored procedures associated with the demonstration home page.

  • The PL/SQL stored procedures called by the function activities used in the Requisition Process workflow.

  • The PL/SQL procedure WF_REQDEMO.Create_Req called by the Oracle Workflow Web agent to generate the Web-based interface page for the Requisition process demonstration.

• Runs the Workflow Resource Generator to load messages from wfdemo.msg into the database. The messages are used by the Web-based interface page for the Requisition process demonstration.

• Loads the Requisition Process workflow definition from wfdemo.wft into the database. You can view this process in Oracle Workflow Builder.

Initiating the Requisition Workflow

You can use any of the following methods to initiate the Requisition workflow:

• Run the script wfrund.sql.

• Access the Requisition Demonstration Web page from the Workflow Demonstrations home page.

• Use the Launch Processes Web page. See: Testing Workflow Definitions.

You can also create your own custom end-user application interface to let users create requisitions that automatically initiate the Requisition process workflow. You must, however, customize the application interface such that when a user saves the requisition to the application database, the application calls a PL/SQL stored procedure similar to WF_REQDEMO.StartProcess that initiates the Requisition process. See: Sample StartProcess Function.

To Run wfrund.sql

1. Enter the following command to run the script wfrund.sql in SQL*Plus:

   sqlplus <username>/<password>@<alias> @wfrund.sql
   <req_num> <req_desc> <req_amount> <requestor> <req_process_owner> <process_int_name> <item_type>
   

   Replace <username>/<password>@<alias> with the username, password, and alias for the database account where you installed the demonstration data model.

   Replace <req_num> with the requisition number that uniquely identifies the requisition.

   Note: The requisition number is used as the item key for the process, so it must contain only single-byte characters.

   Replace <req_desc> with an end-user defined description that uniquely identifies the requisition.

   Replace <req_amount> with the amount of the requisition, <requestor> with the name of the requisition requestor (who should be listed in the employee approval hierarchy), <req_process_owner> with the name of the requisition process owner (who should be listed in the employee approval hierarchy), <process_int_name> with the internal name of the process activity (in this case, REQUISITION_APPROVAL) and <item_type> with the internal name of the item type that the workflow process is associated with.

2. When this script completes, enter Commit at the SQL> prompt to save the transaction before quitting from SQL*Plus.

3. Based on the approval hierarchy, you can either log on as the requisition requestor or the requestor's manager to follow and respond to the series of notification messages that move the process to completion. See: Reviewing Notifications Via Electronic Mail, Oracle Workflow User's Guide and Viewing Notifications from a Web Browser, Oracle Workflow User's Guide.

   You can also access the Workflow Monitor to view the status of the workflow process. See: Using the Find Processes Web Page, Oracle Workflow Administrator's Guide.

To Use the Requisition Demonstration Web Page

1. Enter the following URL in a Web browser to access the Workflow Demonstration Web page, then click on the Requisition Approval link to display the Requisition Approval Web page:

   <webagent>/wf_demo.home
   

   <webagent> represents the base URL of the Web agent configured for Oracle Workflow in your Web server. See: Setting Global User Preferences, Oracle Workflow Administrator's Guide.

   Alternatively, you can enter the following URL to directly display the Requisition Approval Web page:

   <webagent>/wf_reqdemo.create_req
   

   Attention: These are both secured pages, so if you have not yet logged on as a valid workflow user in the current Web session, you will be prompted to do so before the page appears.

2. Enter a unique requisition number.

   Note: The requisition number is used as the item key for the process, so it must contain only single-byte characters.

3. Specify a unique requisition description of 80 characters or less.

4. Enter a requisition amount. The amount should be a number without formatting.

5. Use the poplist fields to specify a requisition requestor and process owner. The names on these poplists are limited to the names of the roles in the demonstration data model.

6. Following the requisition input fields is the Approval Hierarchy and Spending Authority table and a description of how the Requisition demonstration process works. The Approval Hierarchy and Spending Authority table summarizes the contents of the demonstration data model.

7. Choose Submit to initiate the Requisition process and to navigate to the Requisition Created confirmation page.

8. In addition to telling you what roles you should log in as to view the process' notifications, the confirmation page also contains a HTML link to the Workflow Monitor where you can choose View Diagram to display the process diagram for the requisition you submitted in ADMIN mode. See: Workflow Monitor, Oracle Workflow Administrator's Guide.

9. Select the Process Timeouts HTML link to have the background engine look for any timed out notifications and execute the next activity expected to run in the case of a time out.

   Two messages appear below this link informing you of when a timeout may occur in the process.

10. Select the Create Requisition HTML link if you wish to enter and submit another requisition in the Requisition Demonstration Web page.

The Requisition Item Type

The Requisition process is associated with an item type called Requisition. Currently there are two workflow processes associated with Requisition: Requisition Approval and Notify Approver.

If you examine the property page of Requisition, you see that it has a persistence type of Temporary and persistence number of days of 0. This means that the run time data associated with any work items for this item type are eligible for purging as soon as they complete. You also see that it calls a selector function named WF_REQDEMO.SELECTOR. This selector function is an example PL/SQL stored procedure that returns the name of the process to run when more than one process exists for a given item type. The selector function in this example returns REQUISITION_APPROVAL or 'Requisition Approval' as the process to run.

The Requisition item type also has several attributes associated with it. These attributes reference information in the demonstration application tables. The attributes are used and maintained by function activities as well as notification activities throughout the process. The following table lists the Requisition item type attributes.

Summary of the Requisition Approval Process

To view the properties of the Requisition Approval process, select the process in the navigator tree, then choose Properties from the Edit menu. The Requisition Approval process has a result type of Approval, indicating that when the process completes, it has a result of Approve or Reject (the lookup codes in the Approval lookup type associated with the Standard item type). This process activity is also runnable, indicating that it can be initiated as a top level process to run.

The Details property page of the process activity indicates that the Requisition process has an error process assigned to it that is initiated only when an error is encountered in the process. The error process is associated with an item type called WFERROR and is called DEFAULT_ERROR. For example, if you attempt to initiate the Requisition Approval process with a requisition that is created by someone who is not listed in the employee approval hierarchy, the Workflow Engine would raise an error when it tries to execute the Select Approver activity. This error would initiate WFERROR/DEFAULT_ERROR, which is the Default Error Process. See: Default Error Process.

When you display the Process window for the Requisition Approval process, you see that the process consists of 12 unique activities, several of which are reused to comprise the 15 activity nodes that appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Requisition Approval Process Diagram

The Requisition workflow begins when you run a script called wfrund.sql or submit a requisition using the Requisition Demonstration Web page. In both cases, you must provide a requisition requestor, requisition number, requisition amount, requisition description, and process owner. See: Initiating the Requisition Workflow.

The workflow begins at node 1 with the Start activity.

At node 2, the process attempts to select an approver for the requisition. If an approver cannot be found for the requisition, the requestor is notified and the process ends with the final process result of Reject. If an approver is found, then the requestor is notified of who that approver is and a function records in the application that the requisition is being forwarded to the approver. Both of these activities must complete before the approver is actually notified in node 8.

Node 8 is a subprocess that requests the approver to approve the requisition by a specified period of time and if the approver does not respond by that time, the subprocess performs a timeout activity to keep sending a reminder to the approver until the approver responds. If the approver rejects the requisition, the requisition gets updated as rejected in node 9, and the requestor is notified in node 10. The process ends at this point with a result of Reject.

If the approver approves the requisition, the process transitions to node 12 to verify that the requisition amount is within the approver's spending limit. If it is, the process approves the requisition in node 13, and notifies the requestor in node 14. The process ends in this case with a result of Approve.

Requisition Process Activities

Following is a description of each activity listed by the activity's display name. You can create all the components for an activity in the graphical Oracle Workflow Builder except for the PL/SQL stored procedures that the function activities call. Function activities can execute functions external to the database by integration with Oracle Advanced Queuing or execute PL/SQL stored procedures which you must create and store in the Oracle Database. All the function activities in the Requisition process execute PL/SQL stored procedures. The naming convention for the PL/SQL stored procedures used in the Requisition process is:

WF_REQDEMO.<PROCEDURE>

WF_REQDEMO is the name of the package that groups all the procedures used by the Requisition process. <PROCEDURE> represents the name of the procedure.

Several activities are described in greater depth to give you an idea of how they are constructed. See: Example Function Activities and Example Notification Activity.

Start (Node 1)

This is a Standard function activity that simply marks the start of the process.

Select Approver (Node 2)

This function activity determines who the next approver is for the requisition by checking the employee approval hierarchy table. This activity also saves the name of the previous approver or the name of the preparer if the requisition was never approved before. If an approver is found, this procedure returns a value of 'T', for True, otherwise it returns a value of 'F' for False.

Notify Requestor No Approver Available (Node 3)

This activity notifies the requisition preparer that no appropriate approver could be found for the requisition. The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, and who the last approver was, if there was any. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

This activity occurs in process node 3. If you display the property page of the node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Requestor Username.

Notify Requestor of Forward (Node 5)

This activity notifies the requisition preparer that the requisition was forwarded for approval. The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, name of the approver that the requisition is forwarded to, name of the previous approver, if any, and the most recent comments appended to the requisition. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

If you display the property page of this node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Requestor Username.

Record Requisition Forward (Node 6)

Currently this activity does nothing. It represents a point in the process where you can integrate a recording function. If you have a Purchasing/Requisition application into which you want to integrate this workflow, you can customize this activity to execute a PL/SQL stored procedure that updates your purchasing/requisition application table to indicate that the requisition is being forwarded to the next approver.

And (Node 7)

This Standard function activity merges two or more parallel branches in the flow only when the activities in all of those branches complete.

Notify Approver (Node 8)

This activity is a subprocess that notifies the approver that an action needs to be taken to either approve or reject the requisition. To view the subprocess, double-click on Notify Approver under the Processes branch in the navigator tree. The subprocess sends a notification to the approver and if the approver does not respond within a specified time, sends another reminder notification to the approver to take action. See: Summary of the Notify Approver Subprocess.

Reject Requisition (Node 9)

Currently this activity does nothing. It represents a point in the process where you can integrate a function. If you have a Purchasing/Requisition application into which you want to integrate this workflow, you can customize this activity to execute a PL/SQL stored procedure that updates your purchasing/requisition application table to indicate that the requisition is rejected.

Notify Requestor of Rejection (Node 10)

This activity notifies the requisition preparer that the requisition was rejected. The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, name of the manager that rejected the requisition, and comments from that manager. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Requestor Username.

Verify Authority (Node 12)

This function activity verifies whether the current approver has sufficient authority to approve the requisition. The procedure compares the requisition amount with the approver's approval limit amount and returns a value of 'Y' for Yes or 'N' for No. If your business rules are not sensitive to the amount that an approver can approve, then you can remove this activity to customize the process.

Approve Requisition (Node 13)

Currently this activity does nothing. It represents a point in the process where you can integrate a function. If you have a Purchasing/Requisition application into which you want to integrate this workflow, you can customize this activity to execute a PL/SQL stored procedure that updates your purchasing/requisition application table to indicate that the requisition is approved.

Notify Requestor of Approval (Node 14)

This activity notifies the requisition preparer that the requisition was approved. The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, approver name, and comments from the approver. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

If you display the property page of the activity node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Requestor Username.

End (Nodes 4, 11, and 15)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Requisition process activity has a result type of Approval, each End activity node must have a process result matching one of the lookup codes in the Approval lookup type.

Summary of the Notify Approver Subprocess

To view the properties of the Notify Approver subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Notify Approver subprocess has a result type of Approval, indicating that when the subprocess completes, it has a result of Approve or Reject (based on the lookup codes in the Approval lookup type). It is not runnable, indicating that it cannot be initiated as a top level process to run, but rather can only be run when called by another higher level process as a subprocess.

When you display the Process window for the Notify Approver subprocess, you see that the subprocess consists of 6 unique activities, several of which are reused to comprise the 9 activity nodes that appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Notify Approver Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the comments from the previous approver, if any, which are stored in the Note item attribute, are assigned to the Note for Reminder item attribute for use in the Reminder-Approval Needed notification. Then the Note item attribute is cleared, so that it can be used to store comments from the current approver.

At node 4, the process notifies the current approver to approve a requisition within a specified period of time. If the approver approves the requisition, the subprocess ends at node 7 and returns the result Approve to the top level Requisition process. Similarly, if the approver rejects the requisition, the subprocess ends at node 9 and returns the result Reject to the top level Requisition process.

If the approver does not respond by the due date, the subprocess takes the <Timeout> transition to node 5 to send a reminder to the approver to approve the requisition. Node 5 also has a timeout value assigned to it, and if the approver does not respond to the reminder by that time, the subprocess takes the next <Timeout> transition to loop back to node 5 to send another reminder to the approver. This loop continues until the approver approves or rejects the requisition, which would end the subprocess at node 7 or 9, respectively.

Notify Approver Subprocess Activities

Following is a description of each activity in the Notify Approver subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Assign (Node 2)

This is a Standard function activity that assigns a value to an item attribute. This Assign activity node assigns the value of the Note item attribute to the Note for Reminder item attribute.

Assign (Node 3)

This is a Standard function activity that assigns a value to an item attribute. This Assign activity node assigns a blank value to the Note item attribute to clear any previous value.

Notify Requisition Approval Required (Node 4)

This activity notifies the approver that the requisition needs to be approved or rejected. This activity must be completed within 5 minutes, otherwise it times out.

The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, previous approver name, and preparer name for the requisition when the notification is sent. The special WF_NOTIFICATION() message function is called to display these attributes in a message attribute table within the message, and also to include a notification history table in the message. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

The message includes a special RESULT attribute and a "Respond" attribute. The RESULT attribute has a display name of Action and prompts the approver to respond with a value of 'APPROVE' or 'REJECT' from the lookup type called Approval. The value that the approver selects becomes the result that determines which activity branch the Workflow Engine transitions to next.

The "Respond" attribute is called Note and this attribute prompts the approver for optional comments to include in the notification response.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Forward To Username.

Reminder-Approval Needed (Node 5)

This activity occurs only if the Notify Requisition Approval Required activity times out before being completed. This activity sends a reminder notice to the approver that the requisition needs to be approved or rejected.

The message includes 'Send' attributes that display the requisition number, requisition description, requisition amount, previous approver name, and preparer name for the requisition when the notification is sent. The special WF_NOTIFICATION() message function is called to include a notification history table in the message. The message also includes a 'Send' attribute for the from role that sent the notification, to be displayed in the notification header.

The message includes a special RESULT attribute and a "Respond" attribute. The RESULT attribute has a display name of Action and prompts the approver to respond with a value of 'APPROVE' or 'REJECT' from the lookup type called Approval. The value that the approver selects becomes the result that determines which activity branch the Workflow Engine transitions to next.

The "Respond" attribute is called Note and this attribute prompts the approver for optional comments to include in the notification response.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in an item type attribute named Forward To Username.

Or (Nodes 6 and 8)

This Standard function activity merges two or more parallel branches in a flow as soon as an activity in any one of those branches completes.

End (Nodes 7 and 9)

This function activity marks the end of the subprocess. Although the activity itself does not have a result type, each node of this activity in the subprocess must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Notify Approver process activity has a result type of Approval, each End activity node must have a process result matching one of the lookup codes in the Approval lookup type.

Sample StartProcess Function

Both wfrund.sql and the Requisition Demonstration Web page call a PL/SQL stored procedure named WF_REQDEMO.StartProcess to initiate the Requisition process.

To examine StartProcess in more detail, we divide the procedure into several sections and number each section with the notation (1) for easy referencing. The numbers themselves are not part of the procedure.

(1)  procedure StartProcess 
       (RequisitionNumber in varchar2,
        RequisitionDesc in varchar2,
        RequisitionAmount in number,
        RequestorUsername in varchar2,
        ProcessOwner in varchar2,
        Workflowprocess in varchar2 default null,
        item_type in varchar2 default null) is

(2)  ItemType varchar2(30) := nvl(item_type, 'WFDEMO');
     ItemKey varchar2(30) := RequisitionNumber;
     ItemUserKey varchar2(80) := RequisitionDesc;

(3)  begin
       wf_engine.CreateProcess (itemtype => ItemType,
         itemkey  => ItemKey,
         process  => WorkflowProcess );

(4)    wf_engine.SetItemUserKey (itemtype => itemtype,
         itemkey  => itemkey,
         userkey => ItemUserKey);

(5)    wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REQUISITION_NUMBER',
         avalue => RequisitionNumber);

(6)    wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REQUISITION_DESCRIPTION',
         avalue => ItemUserKey);

(7)    wf_engine.SetItemAttrNumber (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REQUISITION_AMOUNT',
         avalue => RequisitionAmount);

(8)    wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REQUESTOR_USERNAME',
         avalue => RequestorUsername);

(9)    wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'FORWARD_TO_USERNAME',
         avalue => RequestorUsername);

(10)   wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REQUISITION_PROCESS_OWNER',
         avalue => ProcessOwner);

(11)   wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'MONITOR_URL',
         avalue => wf_monitor.GetDiagramUrl
           (WF_CORE.Translate('WF_WEB_AGENT'),
             itemtype,itemkey,'NO'));

(12)   wf_engine.SetItemAttrText (itemtype => itemtype,
         itemkey  => itemkey,
         aname => 'REM_DOCUMENT',
         avalue => 'PLSQL:wf_reqdemo.reminder_req_document/'
           ||ItemType||':'||ItemKey);

(13)   wf_engine.SetItemOwner (itemtype => itemtype,
         itemkey  => itemkey,
         owner => ProcessOwner);

(14)   wf_engine.StartProcess (itemtype => itemtype,
         itemkey => itemkey );

(15)  exception
     when others then
       wf_core.context('WF_REQDEMO','StartProcess',
         RequisitionNumber,RequisitionAmount,
         RequestorUsername,ProcessOwner,Workflowprocess);
       raise;

(16)  end StartProcess;

(1) This section represents the specification of the procedure, which includes the list of parameters that must be passed to StartProcess. It uses the same parameter values that you pass to the wfrund.sql script or to the field values entered in the Requisition Demonstration Web page (WF_REQDEMO.Create_Req).

(2) The declarative part of the procedure body begins in this section. StartProcess consists of calls to various Workflow Engine PL/SQL APIs. See: Workflow Engine APIs, Oracle Workflow API Reference.

Since all of these APIs require an item type and item key input, we define ItemType and ItemKey as local arguments. The argument ItemType is defined as 'WFDEMO', which is the internal name for the Requisition item type. The argument ItemKey is the value of the RequisitionNumber parameter that is passed to the StartProcess procedure.

Note: The item key for a process instance can only contain single-byte characters. It cannot contain a multibyte value.

(3) The executable part of the procedure body begins here. This section calls the CreateProcess Workflow Engine API. This API creates a new runtime instance of the Requisition process, whose internal name is 'WFDEMO', and the new instance is identified by the item type and item key that are supplied. See: CreateProcess, Oracle Workflow API Reference.

Note: If you do not pass a value for <process_int_name> when initiating the demo, the selector function for the Requisition item type determines what process to run.

(4) This section calls the SetItemUserKey Workflow Engine API to mark the new runtime instance of the Requisition process with an end-user key. The end-user key makes it easier for users to query and identify the process instance when it is displayed. See: SetItemUserKey, Oracle Workflow API Reference.

(5), (6), (7), (8), (9), (10), (11), and (12) These sections call either the SetItemAttributeText or SetItemAttributeNumber Workflow Engine APIs to set values for the item type attributes defined for this process. The attributes are REQUISITION_NUMBER, REQUISITION_DESCRIPTION, REQUISITION_AMOUNT, REQUESTOR_USERNAME, FORWARD_TO_USERNAME, REQUISITION_PROCESS_OWNER, MONITOR_URL, and REM_DOCUMENT. See: SetItemAttribute, Oracle Workflow API Reference.

(13) This section calls the SetItemOwner Workflow Engine API to mark the new runtime instance of the Requisition process with a process owner user name. Users can query for process instances by process owner. See: SetItemOwner, Oracle Workflow API Reference.

(14) This section calls WF_CORE.CONTEXT() if an exception occurs, to include context information in the error stack to help you locate the source of an error. See: CONTEXT, Oracle Workflow API Reference.

(15) This section calls the Oracle Workflow Engine StartProcess API to invoke the Requisition process for the item type and item key specified. See: StartProcess, Oracle Workflow API Reference.

(16) This section marks the end of the procedure.

Example Function Activities

In general, a function activity must have the following information specified in its Activity property page:

• Internal name for the activity.

• Display name for the activity.

• Result type for the activity, which can be none or the name of a predefined lookup type.

• Name of the PL/SQL stored procedure that the activity calls.

Also, the PL/SQL stored procedure that a function activity calls must comply with a specific API. See: Standard API for PL/SQL Procedures Called by Function Activities.

You can view the scripts that create the WF_REQDEMO stored procedure package used by the Requisition process in the ORACLE_HOME/wf/demo directory on your server.

Related Topics

Example: Select Approver

Example: Verify Authority

Example: Select Approver

The Select Approver function activity calls a PL/SQL stored procedure named WF_REQDEMO.SelectApprover that determines who the next approver is based on the employee approval hierarchy in the demonstration data model.

Result Type

This activity expects a response of 'T' if an approver is found or 'F' if an approver is not found. The possible responses are defined in a lookup type called Boolean, associated with the Standard item type.

PL/SQL Stored Procedure

The PL/SQL stored procedure that this function activity calls is described in detail below. Each section in the procedure is numbered with the notation (1) for easy referencing.

procedure SelectApprover 
  (itemtype in varchar2,
   itemkey in varchar2,
   actid in number,
   funcmode in varchar2,
   resultout out varchar2) is

(1)  l_forward_from_username varchar2(320);
     l_forward_to_username varchar2(320);

(2)  begin
     if (funcmode = 'RUN') then
       l_forward_to_username := wf_engine.GetItemAttrText (
         itemtype => itemtype,
         itemkey => itemkey,
         aname => 'FORWARD_TO_USERNAME');

(3)    if (l_forward_to_username is null) then
         l_forward_to_username := wf_engine.GetItemAttrText (
           itemtype => itemtype,
           itemkey => itemkey,
           aname => 'REQUESTOR_USERNAME');
       end if;

(4)    l_forward_from_username := l_forward_to_username;

(5)    wf_engine.SetItemAttrText (itemtype => itemtype;
         itemkey => itemkey,
         aname => 'FORWARD_FROM_USERNAME';
         avalue => l_forward_from_username);

(6)    l_forward_to_username := wf_reqdemo.GetManager( 
         l_forward_from_username);

(7)    wf_engine.SetItemAttrText (itemtype => itemtype;
         itemkey => itemkey,
         aname => 'FORWARD_TO_USERNAME';
         avalue => l_forward_to_username);

(8)    if (l_forward_to_username is null) then
         resultout :='COMPLETE:F';
       else
         resultout :='COMPLETE:T';
       end if;

(9)  end if;

(10) if (funcmode = 'CANCEL') then
       resultout :='COMPLETE';
       return;
     end if;

(11) if (funcmode = 'TIMEOUT') then
       resultout :='COMPLETE';
       return;
     end if;

(12) exception
       when others then
         wf_core.context('WF_REQDEMO','SelectorApprover',itemtype,
           itemkey,actid,funcmode);
         raise;

(13) end SelectApprover;

(1) The local arguments l_forward_from_username and l_forward_to_username are declared in this section.

(2) If the value of funcmode is RUN, then retrieve the name of the last person that this requisition was forwarded to for approval by assigning l_forward_to_username to the value of the FORWARD_TO_USERNAME item type attribute, determined by calling the Workflow Engine API GetItemAttrText. See: GetItemAttribute, Oracle Workflow API Reference.

(3) If the value of l_forward_to_username is null, then it means that the requisition has never been forwarded for approval. In this case, assign it the value of the REQUESTOR_USERNAME item type attribute, determined by calling the Workflow Engine API GetItemAttrText.

(4) Assign l_forward_from_username to the value of l_forward_to_username.

(5) This section assigns the value of l_forward_from_username to the FORWARD_FROM_USERNAME item type attribute by calling the Workflow Engine SetItemAttrText API.

(6) This section calls the function GetManager to return the manager of the previous approver stored in l_forward_from_username, from the WF_REQDEMO_EMP_HIERARCHY table and assigns that manager's name to l_forward_to_username.

(7) This section assigns the value of l_forward_to_username to the FORWARD_TO_USERNAME item type attribute by calling the Workflow Engine SetItemAttrText API.

(8) If l_forward_to_username is null, meaning there is no manager above the previous approver in the hierarchy, then assign resultout to be COMPLETE:F. Otherwise, assign resultout to be COMPLETE:T.

(9) This ends the check on funcmode =' RUN'.

(10) If the value of funcmode is CANCEL, then assign resultout to be COMPLETE.

(11) If the value of funcmode is TIMEOUT, then assign resultout to be COMPLETE.

(12) This section calls WF_CORE.CONTEXT if an exception occurs, to include context information in the error stack to help you locate the source of an error. See: CONTEXT, Oracle Workflow API Reference.

(13) This section marks the end of the procedure.

Example: Verify Authority

The Verify Authority function activity calls a PL/SQL stored procedure named WF_REQDEMO.VerifyAuthority to verify whether the requisition amount is within the approver's spending limit. This activity is also another example of an automated function activity that returns a result based on a business rule that you implement as a stored procedure.

Result Type

This activity expects a result of 'Yes' or 'No' when the procedure completes to indicate whether the approver has the authority to approve the requisition. These result values are defined in the lookup type called Yes/No, associated with the Standard item type.

PL/SQL Stored Procedure

The PL/SQL stored procedure that this function activity calls is described in detail below. Each section in the procedure is numbered with the notation (1) for easy referencing. We also use the convention 'l_' to identify local arguments used within the procedure.

procedure VerifyAuthority 
  (itemtype in varchar2,
   itemkey in varchar2,
   actid in number,
   funcmode in varchar2,
   resultout out varchar2) is

(1) l_forward_to_username varchar2(320);
     l_requisition_amount number;
     l_spending_limit number;

(2)  begin
     if (funcmode = 'RUN') then
       l_requisition_amount := wf_engine.GetItemAttrNumber (
         itemtype => itemtype,
         itemkey => itemkey,
         aname => 'REQUISITION_AMOUNT');

(3)    l_forward_to_username := wf_engine.GetItemAttrText (
         itemtype => itemtype,
         itemkey => itemkey,
         aname => 'FORWARD_TO_USERNAME');

(4)    if (wf_reqdemo.checkSpendingLimit(l_forward_to_username, 
             l_requisition_amount)) then
         resultout :='COMPLETE:Y';
       else
         resultout :='COMPLETE:N';
       end if;
     end if;

(5)  if (funcmode = 'CANCEL') then
       resultout :='COMPLETE:';
       return;
     end if;

(6)  if (funcmode = 'TIMEOUT') then
       resultout :='COMPLETE:';
       return;
     end if;

(7)  exception
       when others then
         wf_core.context('WF_REQDEMO', 'VerifyAuthority', 
           itemtype, itemkey, actid, funcmode);
         raise;

(8)  end VerifyAuthority;

(1) The local arguments l_forward_to_username, l_requisition_amount, and l_spending_limit are declared in this section.

(2) If the value of funcmode is equal to RUN, then assign l_requisition_amount to the value of the REQUISITION_AMOUNT item type attribute, determined by calling the Workflow Engine API GetItemAttrNumber. See: GetItemAttribute, Oracle Workflow API Reference.

(3) This section assigns l_forward_to_username to the value of the FORWARD_TO_USERNAME item type attribute, determined by calling the Workflow Engine API GetItemAttrText.

(4) This section calls the function CheckSpendingLimit for the current approver to determine whether the requisition amount is less than or equal to the approver's spending limit. If the requisition amount is less than or equal to the value in l_spending_limit, meaning the approver has authority to approve, then assign resultout to be COMPLETE:Y. Otherwise, assign resultout to be COMPLETE:N.

(5) If the value of funcmode is CANCEL, then assign resultout to be COMPLETE:.

(6) If the value of funcmode is TIMEOUT, then assign resultout to be COMPLETE:.

(7) This section calls WF_CORE.CONTEXT if an exception occurs, to include context information in the error stack to help you locate the source of an error. See: CONTEXT, Oracle Workflow API Reference.

(8) This section marks the end of the procedure.

Example Notification Activity

The Requisition process contains several notification activities that send informative messages to users. The Notify Approver subprocess, however, also includes notification activities that request a response from a user.

A notification activity requires the following information be defined in its Activity property page:

• Internal name for the activity.

• Display name for the activity.

• Result type for the activity, which can be none or the name of a predefined lookup type.

• Name of a predefined message that the notification sends out.

Related Topics

Example: Notify Requisition Approval Required

Example: Notify Requisition Approval Required

The Notify Requisition Approval Required activity sends a message called Requisition Approval Required to an approving manager. The message requests that the manager approve or reject a requisition and provides details about the requisition within the body of the message.

Result Type

The manager's response determines the activity that the process transitions to next. The possible responses, 'APPROVE' or 'REJECT', are defined in a lookup type called Approval. These values are defined by the message's special Result attribute, whose display name is Action. These values are also the possible results of the notification activity, as defined by the Result Type field in the Activity property page.

Message

The content of the notification is defined in the message called Requisition Approval Required:

Requisition &REQUISITION_NUMBER, &REQUISITION_DESCRIPTION for 
&REQUISITION_AMOUNT requires approval

WF_NOTIFICATION(ATTRS,REQUISITION_NUMBER,REQUISITION_AMOUNT,
REQUISITION_DESCRIPTION,FORWARD_FROM_USERNAME,REQUESTOR_USERNAME)  

WF_NOTIFICATION(HISTORY)

Message attributes, preceded by an ampersand '&' in the subject line or body of the message, are token substituted with runtime values when the notification is sent. However, in order for token substitution to occur properly, all message attributes referenced in the subject line or body of the message must be defined with a source of 'Send'.

In this example, the message body consists of two calls to the special message function called WF_NOTIFICATION(). The first call displays the requisition number, requisition description, requisition amount, previous approver name, and preparer name for the requisition in a message attribute table within the message. The second call displays a notification history table in the message. Additionally, the message includes a special 'Send' attribute named #FROM_ROLE, for the from role that sent the notification, to be displayed in the notification header. See: #FROM_ROLE Attribute and WF_NOTIFICATION() Message Function.

This message also contains a special result message attribute called Action and a 'Respond' message attribute called Note.

The result message attribute is defined in the Result tab of the message's property page. The result attribute prompts the approver to respond with a value from a list of possible values provided by the lookup type specified. The response, in turn, becomes the result of the Notify Requisition Approval Required activity. In this case, the possible response values are 'APPROVE' or 'REJECT', as defined by the Approval lookup type. This result determines which activity the process transitions to next.

The 'Respond' message attribute Note is of type 'Text'. This attribute prompts the approver to enter optional comments when responding to the notification.

Note: To view the content of any message, double-click on the message in the navigator tree or select the message and choose Properties from the Edit menu.

Process Node Properties

If you display the properties of the Notify Requisition Approval Required activity node in the Notify Approver subprocess diagram you should see that this node is set to Normal because it is neither the start nor end activity in the process.

You should also see that the Performer is set to the Forward To Username item type attribute, indicating that the notification gets sent to the user whose name is stored in the item type attribute called 'Forward To Username'. The value of 'Forward To Username' is determined earlier in the Requisition process by the activity called Select Approver.

Event System Demonstration

The Event System Demonstration is an example of using events to transmit business documents between two systems. You initiate the demonstration process by entering a purchase order on one system. Oracle Workflow generates a purchase order XML document and sends this document to a second system. The second system processes the purchase order and sends back to the first system three XML documents representing a purchase order acknowledgement, an advanced shipment notice, and an invoice.

You can initiate this example process if you are using the standalone version of Oracle Workflow. If you are using Oracle Workflow embedded in Oracle Applications, you should consider this process mainly as an example for explanation purposes and not for demonstration use. The files necessary to set up and run this demonstration are not provided with the version of Oracle Workflow embedded in Oracle Applications.

Attention: For detailed information about runnable workflow processes that are integrated with Oracle Applications, refer to the appropriate Oracle Applications user's guide or online documentation. See: Predefined Workflows Embedded in Oracle E-Business Suite.

Before running the Event System Demonstration, you must set up a Buyer system and a Supplier system to use in the demonstration.

Note: You can either set up two separate systems, or you can use the same system as both the Buyer and the Supplier.

Then you can initiate an Event System Demonstration process on the Buyer system from the Workflow Demonstrations Web page. When you initiate the process, you must specify an order number, item number, item description, deliver date, total amount, and order requestor role for the purchase order.

Note: The order number is used in the item key for the process, so it must contain only single-byte characters.

When you submit the purchase order, the order information is inserted into a database table and a purchase order event is raised with the order number as the event key. Raising the purchase order event triggers two subscriptions to this event that have the source type Local. The first subscription adds a correlation ID to the event message. The correlation ID consists of the prefix PO followed by the event key (the order number).

Because the second subscription to this event requires the complete event data, the Event Manager runs the Generate function for the event to produce a valid purchase order XML document. The second subscription sends the event to the Buyer: Top Level PO process in the Event System Demonstration item type. The Workflow Engine creates a new instance of this process with the correlation ID as the item key.

During the purchase order processing in the Buyer: Top Level PO process, a standard external Java function activity retrieves the name of the order requestor from the purchase order XML document, so that the process can send notifications to the requestor. The purchase order event message is sent to the Supplier system, and then the process waits to receive responses from the supplier.

When the purchase order event arrives at the Supplier system, two subscriptions to this event with the source type External are triggered. The first subscription changes the correlation ID in the event message to consist of the prefix SO followed by the event key (the order number). The second subscription sends the event to the Supplier: Top Level Order process in the Event System Demonstration item type. The Workflow Engine creates a new instance of this process with the new correlation ID as the item key.

During the purchase order processing in the Supplier: Top Level Order process, standard external Java function activities retrieve the item number and item description from the purchase order XML document. The process sends event messages containing the following XML documents back to the Buyer system:

• purchase order acknowledgement

• advanced shipment notice

• invoice

On the Buyer system, these events trigger subscriptions with the source type External. For each event, there are two subscriptions: one that adds a correlation ID consisting of the prefix PO followed by the event key (the order number), and another that sends the event message to the Buyer: Top Level PO process, using the correlation ID to match the message with the running process to which it belongs. The process receives the event messages and notifies the order requestor when each one arrives. After all three response documents have been received, the process completes.

Related Topics

Installing the Event System Demonstration Data Model

Initiating the Event System Demonstration Workflow

The Event System Demonstration Item Type

Summary of the Buyer: Top Level PO Process

Buyer: Top Level PO Process Activities

Summary of the Buyer: Send PO to Supplier Subprocess

Buyer: Send PO to Supplier Subprocess Activities

Summary of the Buyer: Receive Supplier PO Acknowledgement Subprocess

Buyer: Receive Supplier PO Acknowledgement Subprocess Activities

Summary of the Buyer: Advanced Shipment Notice Subprocess

Buyer: Advanced Shipment Notice Subprocess Activities

Summary of the Buyer: Receive Supplier Invoicing Subprocess

Buyer: Receive Supplier Invoicing Subprocess Activities

Summary of the Supplier: Top Level Order Process

Supplier: Top Level Order Process Activities

Summary of the Supplier: Get Order Details Subprocess

Supplier: Get Order Details Subprocess Activities

Summary of the Supplier: Credit Check Subprocess

Supplier: Credit Check Subprocess Activities

Summary of the Supplier: Stock Check Subprocess

Supplier: Stock Check Subprocess Activities

Summary of the Supplier: Advanced Shipment Notice Subprocess

Supplier: Advanced Shipment Notice Subprocess Activities

Summary of the Supplier: Send Supplier Invoice Subprocess

Supplier: Send Supplier Invoice Subprocess Activities

B2B Purchase Order Event

B2B Purchase Order Acknowledgement Event

B2B Advanced Shipment Notice Event

B2B Invoice Event

Installing the Event System Demonstration Data Model

The Event System data model is installed only with the standalone version of Oracle Workflow. The data model is automatically installed for you by the Workflow Configuration Assistant. The files used in the installation are copied to the ORACLE_HOME/demo and ORACLE_HOME/demo/<language> directories of your Oracle Workflow server directory structure.

Attention: For the Event System Demonstration to work properly, you should perform the steps required to set up Oracle Workflow after the installation. See: Overview of Setting Up, Oracle Workflow Administrator's Guide.

The installation does the following:

• Calls a script called wfevdemc.sql to create two tables called WF_EVENTDEMO_ITEMS and WF_EVENTDEMO_PO. The table WF_EVENTDEMO_ITEMS contains the items that can be selected for the purchase order. The Event System Demonstration process updates the table WF_EVENTDEMO_PO with information from the purchase order.

• Calls the scripts wfevdems.sql and wfevdemb.sql to create the PL/SQL spec and body for a package called WF_EVENTDEMO. This package contains:

  • The PL/SQL stored procedures called by the function activities used in the Event System Demonstration workflow.

  • The PL/SQL procedures WF_EVENTDEMO.Create_Order and WF_EVENTDEMO.Track_Order called by the Oracle Workflow Web agent to generate the Web-based interface pages for the Event System Demonstration process demonstration.

• Loads the Event System Demonstration workflow definition from wfevdeme.wft into the database. You can view this process in the Oracle Workflow Builder.

• The data model for the Event System Demonstration process also includes the same demonstration directory service that is used by the sample Requisition process. See: Installing the Requisition Data Model.

  Attention: For security reasons, the installation process automatically locks the database accounts for the users in the demonstration directory service after they are created. Before you can begin using the accounts, you must unlock them using a script called wfdemoul.sql. See: Installing the Requisition Data Model.

Initiating the Event System Demonstration Workflow

The Event System Demonstration requires two Workflow-enabled systems, a Buyer system and a Supplier system. You can either set up two separate systems, or you can use the same system as both the Buyer and the Supplier. Before you can run the Event System Demonstration, you must set up the system or systems that you want to use. See: To Set Up the Event System Demonstration Workflow.

After the systems are set up, you can initiate the Event System Demonstration workflow using the Events: Buyer Workbench demonstration Web page on the Buyer system. Then use the Events: Track Order demonstration Web page on the Supplier system to continue processing the Event System Demonstration workflow. See: To Initiate the Event System Demonstration Workflow from the Buyer Workbench and To Continue the Event System Demonstration Workflow on the Supplier System.

To Set Up the Event System Demonstration Workflow

1. If you are using two separate installations of Oracle Workflow, designate one of the installations as the Buyer system and the other as the Supplier system.

2. If you are using two separate installations of Oracle Workflow, sign the two systems up with each other to exchange event messages. See: Signing Up Systems.

3. If you are using two separate installations of Oracle Workflow, on the Buyer system, locate the predefined subscription to the demo.oracle.apps.wf.po.create event with the source type Local and the phase 2. Edit this subscription by selecting the standard WF_IN agent on the Supplier system as the To agent. See: To Define an Event Subscription.

4. If you are using two separate installations of Oracle Workflow, on the Supplier system, locate the predefined subscription to the demo.oracle.apps.wf.po.create event with the source type External and the phase 2. Edit this subscription by selecting the standard WF_IN agent on the Buyer system as the To agent. See: To Define an Event Subscription.

5. Ensure that the Java Function Activity Agent is running on your systems. See: Setting Up the Java Function Activity Agent, Oracle Workflow Administrator's Guide.

6. Optionally schedule a background engine to run every 10 to 30 seconds on your systems. See: Setting Up Background Engines, Oracle Workflow Administrator's Guide.

   You can also run the background engine manually during the demonstration by choosing the Process Order link on the Events: Track Order page.

To Initiate the Event System Demonstration Workflow from the Buyer Workbench

1. On the Buyer system, enter the following URL in a Web browser to access the Workflow Demonstration Web page:

   <webagent>/wf_demo.home
   

   <webagent> represents the base URL of the Web agent configured for Oracle Workflow in your Web server. See: Setting Global User Preferences, Oracle Workflow Administrator's Guide.

   Choose the Events: Buyer Workbench link to display the Buyer Workbench Web page.

   Alternatively, you can enter the following URL to directly display the Buyer Workbench Web page:

   <webagent>/wf_eventdemo.create_order
   

   Attention: These are both secured pages, so if you have not yet logged on as a valid workflow user in the current Web session, you will be prompted to do so before the page appears.

   Buyer Workbench Page

   

2. Enter a unique order number for the purchase order. The order number becomes the event key for the B2B Purchase Order event that is raised.

3. Select an item number.

4. Enter an item description of 40 characters or less.

5. Enter a deliver date in the format DD-MON-YYYY.

6. Enter the total amount for the purchase order. The amount should be a number without formatting.

7. Select a role name as the order requestor.

8. Choose the Submit button to submit the purchase order and display the Events: Track Order page. You can also choose the Cancel button to return to the Workflow Demonstrations page without submitting the purchase order.

9. Choose the Workflow Monitor link to view the progress of the Buyer: Top Level PO workflow process in the Workflow Monitor. See: Workflow Monitor, Oracle Workflow Administrator's Guide.

10. Choose the Process Order link to run the background engine and process the deferred activity so that the buyer workflow can continue processing the purchase order.

To Continue the Event System Demonstration Workflow on the Supplier System

1. On the Supplier system, enter the following URL in a Web browser to access the Workflow Demonstration Web page:

   <webagent>/wf_demo.home
   

   <webagent> represents the base URL of the Web agent configured for Oracle Workflow in your Web server. See: Setting Global User Preferences, Oracle Workflow Administrator's Guide.

   Choose the Events: Track Order link to display the Events: Track Order Web page.

   Alternatively, you can enter the following URL to directly display the Events: Track OrderWeb page:

   <webagent>/wf_eventdemo.track_order
   

   Attention: These are both secured pages, so if you have not yet logged on as a valid workflow user in the current Web session, you will be prompted to do so before the page appears.

   Events: Track Order Page

   

2. Select the order number for your purchase order and choose the Submit button.

3. Choose the Workflow Monitor link to view the progress of the Supplier: Top Level Order process in the Workflow Monitor. See: Workflow Monitor, Oracle Workflow Administrator's Guide.

4. Choose the Process Order link to run the background engine and continue processing the purchase order. Perform this step twice to process both deferred activities in the supplier workflow.

The Event System Demonstration Item Type

The Event System demonstration is associated with an item type called Event System Demonstration. Currently there are eleven workflow processes associated with Event System Demonstration:

• Buyer: Top Level PO

• Buyer: Send PO to Supplier

• Buyer: Receive Supplier PO Acknowledgement

• Buyer: Advanced Shipment Notice

• Buyer: Receive Supplier Invoicing

• Supplier: Top Level Order

• Supplier: Get Order Details

• Supplier: Credit Check

• Supplier: Stock Check

• Supplier: Advanced Shipment Notice

• Supplier: Send Supplier Invoice

To view the details of the Event System Demonstration item type in the Workflow Builder, choose Open from the File menu. Then connect to the database and select the Event System Demonstration item type, or connect to a file called wfevdeme.wft in the ORACLE_HOME\wf\Data\<language> subdirectory on your file system.

If you examine the property page of Event System Demonstration, you see that it has a persistence type of Temporary and persistence number of days of 0. This means that the runtime data associated with any work items for this item type are eligible for purging as soon as they complete.

The Event System Demonstration item type also has several attributes associated with it. These attributes reference information in the Workflow application tables. The attributes are used and maintained by function, notification, and event activities throughout the process. The following table lists the Event System Demonstration item type attributes.

Summary of the Buyer: Top Level PO Process

To view the properties of the Buyer: Top Level PO process, select the process in the navigator tree, then choose Properties from the Edit menu. This process activity is runnable, indicating that it can be initiated as a top level process to run.

When you display the Process window for the Buyer: Top Level PO process, you see that the process consists of nine unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Buyer: Top Level PO Process Diagram

The Buyer: Top Level PO workflow begins when you submit a purchase order from the Buyer Workbench demonstration page, raising the B2B Purchase Order event. Predefined subscriptions add a correlation ID consisting of the prefix PO followed by the event key (the order number), and send the event to the Buyer: Top Level PO process. See: To Initiate the Event System Demonstration Workflow from the Buyer Workbench.

The process begins at node 1 with the Buyer: Receive Create PO Event activity. The process finds a supplier for the purchase order and retrieves the agent details for the intended outbound and inbound agents to send the purchase order to the supplier.

Node 4 is a subprocess that retrieves the name of the order requestor from the purchase order event message, sends the purchase order to the supplier, and notifies the order requestor that the purchase order has been sent to the supplier.

Node 5 is a subprocess that waits to receive a purchase order acknowledgement event message from the supplier. If the acknowledgement is not received within a specified period of time, the subprocess performs a timeout activity to keep notifying the order requestor that the supplier has not responded until the acknowledgement is received. When the acknowledgement is received, the subprocess notifies the order requestor of the acknowledgement.

After the purchase order acknowledgement is received, the top level process waits to receive an advanced shipment notice and an invoice from the supplier. Node 6 is a subprocess that receives the advanced shipment notice and notifies the order requestor that the order has been shipped. Node 7 is a subprocess that receives the invoice and notifies the order requestor that the invoice has arrived. After both of these subprocesses complete, the process ends.

Buyer: Top Level PO Process Activities

Following is a description of each activity in the process, listed by the activity's display name.

Buyer: Receive Create PO Event (Node 1)

This event activity receives the B2B Purchase Order event message that is sent to the Buyer: Top Level PO process by the Event Manager to start a new item.

demo.oracle.wf.b2b.po.create

Find Supplier (Node 2)

Currently this activity does nothing. It represents a point in the process where you can integrate a function that locates a supplier for the purchase order, based on the item being ordered or other criteria.

Get Agent Details (Node 3)

This function activity retrieves the agent details from the subscription that sent the event message to the workflow process. The activity retrieves details for the outbound agent on the Buyer system that should send the message and the inbound agent on the Supplier system that should receive the message.

Buyer: Send PO to Supplier Process (Node 4)

This activity is a subprocess that retrieves the name of the order requestor from the purchase order event message, sends the purchase order to the supplier, and notifies the order requestor that the purchase order has been sent to the supplier. To view the subprocess, double-click on Buyer: Send PO to Supplier under the Processes branch in the navigator tree. See: Summary of the Buyer: Send to PO Subprocess.

Buyer: Receive Supplier PO Acknowledgement (Node 5)

This activity is a subprocess that waits to receive a purchase order acknowledgement event message from the supplier. If the acknowledgement is not received within a specified period of time, the subprocess performs a timeout activity to keep notifying the order requestor that the supplier has not responded until the acknowledgement is received. When the acknowledgement is received, the subprocess notifies the order requestor of the acknowledgement.

To view the subprocess, double-click on Buyer: Receive Supplier PO Acknowledgement under the Processes branch in the navigator tree. See: Summary of the Buyer: Receive Supplier PO Acknowledgement Subprocess.

Buyer: Advanced Shipment Notice Process (Node 6)

This activity is a subprocess that receives an advanced shipment notice from the supplier and notifies the order requestor that the order has been shipped. To view the subprocess, double-click on Buyer: Advanced Shipment Notice under the Processes branch in the navigator tree. See: Summary of the Buyer: Advanced Shipment Notice Subprocess.

Buyer: Receive Supplier Invoicing (Node 7)

This activity is a subprocess that receives an invoice from the supplier and notifies the order requestor that the invoice has arrived. To view the subprocess, double-click on Buyer: Receive Supplier Invoicing under the Processes branch in the navigator tree. See: Summary of the Buyer: Receive Supplier Invoicing Subprocess.

And (Node 8)

This Standard function activity merges two or more parallel branches in the flow only when the activities in all of those branches complete.

End (Node 9)

This Standard function activity marks the end of the process.

Summary of the Buyer: Send PO to Supplier Subprocess

To view the properties of the Buyer: Send PO to Supplier subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Buyer: Send PO to Supplier subprocess, you see that the subprocess consists of five unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Buyer: Send PO to Supplier Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process retrieves the name of the order requestor from the purchase order event message. Then the process sends the purchase order to the supplier and notifies the order requestor that the purchase order has been sent. The subprocess ends at this point.

Buyer: Send PO to Supplier Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

XML Get Tag Value (Node 2)

This Standard external Java function activity retrieves the value of a particular XML tag set in the event message. At this node, the process retrieves the name of the order requestor from the purchase order event message.

Buyer: Send PO to Supplier (Node 3)

This event activity sends the purchase order event message to the supplier, using the outbound agent on the Buyer system and the inbound agent on the Supplier system identified by the Get Agent Details activity in the Buyer: Top Level PO process.

PO Sent to Supplier (Node 4)

This activity notifies the order requestor that the purchase order has been sent to the supplier. The message includes a 'Send' attribute that displays the purchase order number when the notification is sent.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in the item type attribute named Order Requestor.

End (Node 5)

This Standard function activity marks the end of the process.

Summary of the Buyer: Receive Supplier PO Acknowledgement Subprocess

To view the properties of the Buyer: Receive Supplier PO Acknowledgement subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Buyer: Receive Supplier PO Acknowledgement subprocess, you see that the subprocess consists of five unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Buyer: Receive Supplier PO Acknowledgement Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process waits to receive a purchase order acknowledgement event message from the supplier. If the acknowledgement is not received within a specified period of time, the subprocess performs a timeout activity to keep notifying the order requestor that the supplier has not responded until the acknowledgement is received. When the acknowledgement is received, the subprocess notifies the order requestor of the acknowledgement. The subprocess ends at this point.

Buyer: Receive Supplier PO Acknowledgement Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Buyer: Receive PO Ack Event (Node 2)

This event activity waits to receive the B2B Purchase Order Acknowledgement event message from the supplier. The activity must be completed within one day; otherwise it times out.

demo.oracle.wf.b2b.po.ack

PO Not Acknowledged by Supplier (Node 3)

This activity occurs only if the Buyer: Receive PO Ack Event activity times out before being completed. This activity notifies the order requestor that the supplier has not yet acknowledged the purchase order. The message includes a 'Send' attribute that displays the purchase order number when the notification is sent.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in the item type attribute named Order Requestor.

PO Acknowledged by Supplier (Node 4)

This activity notifies the order requestor that the purchase order has been acknowledged by the supplier. The message includes a 'Send' attribute that displays the purchase order number when the notification is sent.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in the item type attribute named Order Requestor.

End (Node 5)

This Standard function activity marks the end of the process.

Summary of the Buyer: Advanced Shipment Notice Subprocess

To view the properties of the Buyer: Advanced Shipment Notice subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Buyer: Advanced Shipment Notice subprocess, you see that the subprocess consists of four unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Buyer: Advanced Shipment Notice Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process waits to receive an advanced shipment notice from the supplier. When the advanced shipment notice is received, the process notifies the order requestor that the order has been shipped. The subprocess ends at this point.

Buyer: Advanced Shipment Notice Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Buyer: Purchase Order ASN (Node 2)

This event activity waits to receive the B2B Advanced Shipment Notice event message from the supplier.

demo.oracle.wf.b2b.po.asn

Your Order has been Shipped (Node 3)

This activity notifies the order requestor that the purchase order advanced shipment notice has been received, indicating that the order has been shipped by the supplier. The message includes a 'Send' attribute that displays the purchase order number when the notification is sent.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in the item type attribute named Order Requestor.

End (Node 4)

This Standard function activity marks the end of the process.

Summary of the Buyer: Receive Supplier Invoicing Subprocess

To view the properties of the Buyer: Receive Supplier Invoicing subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Buyer: Receive Supplier Invoicing subprocess, you see that the subprocess consists of four unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Buyer: Receive Supplier Invoicing Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process waits to receive an invoice from the supplier. When the invoice is received, the process notifies the order requestor that the invoice has arrived. The subprocess ends at this point.

Buyer: Receive Supplier Invoicing Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Buyer: Receive Supplier Invoice (Node 2)

This event activity waits to receive the B2B Invoice event message from the supplier.

demo.oracle.wf.b2b.po.invoice

Invoice for Order Has Arrived (Node 3)

This activity notifies the order requestor that the invoice for the purchase order has been received from the supplier. The message includes a 'Send' attribute that displays the purchase order number when the notification is sent.

If you display the property page of this activity node, you see that the activity is assigned to a performer whose name is stored in the item type attribute named Order Requestor.

End (Node 4)

This Standard function activity marks the end of the process.

Summary of the Supplier: Top Level Order Process

To view the properties of the Supplier: Top Level Order process, select the process in the navigator tree, then choose Properties from the Edit menu. This process activity is runnable, indicating that it can be initiated as a top level process to run.

When you display the Process window for the Supplier: Top Level Order process, you see that the process consists of ten unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Top Level Order Process Diagram

The Supplier: Top Level Order workflow begins when the Supplier system receives the B2B Purchase Order event from the Buyer system. Predefined subscriptions change the correlation ID to consist of the prefix SO followed by the event key (the order number), and send the event to the Supplier: Top Level Order process.

The process begins by receiving a purchase order either at node 1 or at node 2, depending on the source of the purchase order.

Node 3 is a subprocess that retrieves the agent details for the intended outbound and inbound agents to send responses to the buyer, as well as retrieving the item number and item description.

Node 4 is a subprocess that performs a credit check if the total cost of the order is greater than 2000. Node 5 is a subprocess that performs a stock check to determine if the ordered item is in stock. When both the credit check and the stock check are complete, the process sends an acknowledgement of the purchase order to the buyer.

Node 8 is a subprocess that checks the shipping details for the order and then sends an advanced shipment notice to the buyer. Node 9 is a subprocess that creates an invoice and sends the invoice to the buyer. After sending the invoice, the process ends.

Supplier: Top Level Order Process Activities

Following is a description of each activity in the process, listed by the activity's display name.

Supplier: Receive External Order (Node 1)

This event activity receives the B2B Purchase Order event message that is sent to the Supplier: Top Level Order process by the Event Manager when the event is received from the buyer.

demo.oracle.wf.b2b.po.create

Supplier: Receive iStore Order (Node 2)

This event activity receives a purchase order event message that is sent when an order is placed through the supplier's iStore application. Currently this event is not defined. The activity represents a point in the process where you can integrate the reception of purchase orders from another source.

demo.oracle.wf.istore.po.create

Supplier: Get Order Details (Node 3)

This activity is a subprocess that retrieves the agent details for the intended outbound and inbound agents to send responses to the buyer, as well as retrieving the item number and item description of the ordered item.

To view the subprocess, double-click on Supplier: Get Order Details under the Processes branch in the navigator tree. See: Summary of the Supplier: Get Order Details Subprocess.

Supplier: Credit Check (Node 4)

This activity is a subprocess that performs a credit check if the total cost of the order is greater than $2000.

To view the subprocess, double-click on Supplier: Credit Check under the Processes branch in the navigator tree. See: Summary of the Supplier: Credit Check Subprocess.

Supplier: Stock Check (Node 5)

This activity is a subprocess that performs a stock check to determine if the ordered item is in stock.

To view the subprocess, double-click on Supplier: Stock Check under the Processes branch in the navigator tree. See: Summary of the Supplier: Stock Check Subprocess.

And (Node 6)

This Standard function activity merges two or more parallel branches in the flow only when the activities in all of those branches complete.

Supplier: Send Order Acknowledgement (Node 7)

This event activity sends the B2B Purchase Order Acknowledgement event message to the buyer, using the outbound agent on the Supplier system and the inbound agent on the Buyer system identified by the Get Agent Details activity in the Supplier: Get Order Details subprocess.

Supplier: Advanced Shipment Notice (Node 8)

This activity is a subprocess that checks the shipping details for the order and then sends an advanced shipment notice to the buyer.

To view the subprocess, double-click on Supplier: Advanced Shipment Notice under the Processes branch in the navigator tree. See: Summary of the Supplier: Advanced Shipment Notice Subprocess.

Supplier: Send Supplier Invoice (Node 9)

This activity is a subprocess that creates an invoice for the purchase order and sends the invoice to the buyer.

To view the subprocess, double-click on Supplier: Send Supplier Invoice under the Processes branch in the navigator tree. See: Summary of the Supplier: Send Supplier Invoice Subprocess.

End (Node 10)

This Standard function activity marks the end of the process.

Summary of the Supplier: Get Order Details Subprocess

To view the properties of the Supplier: Get Order Details subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Supplier: Get Order Details subprocess, you see that the subprocess consists of five unique activities, one of which is reused to make up the six activity nodes that appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Get Order Details Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process retrieves the agent details for the intended outbound and inbound agents to send responses to the buyer. Next, the process retrieves the item number and item description of the ordered item from the purchase order. When both the item number and item description have been retrieved, the subprocess ends.

Supplier: Get Order Details Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Get Agent Details (Node 2)

This function activity retrieves the agent details from the subscription that sent the event message to the workflow process. The activity retrieves details for the outbound agent on the Supplier system that should send the response messages and the inbound agent on the Buyer system that should receive the response messages.

XML Get Tag Value (Node 3)

This Standard external Java function activity retrieves the value of a particular XML tag set in the event message. At this node, the process retrieves the item number from the purchase order event message.

XML Get Tag Value (Node 4)

This Standard external Java function activity retrieves the value of a particular XML tag set in the event message. At this node, the process retrieves the item description from the purchase order event message.

And (Node 5)

This Standard function activity merges two or more parallel branches in the flow only when the activities in all of those branches complete.

End (Node 6)

This Standard function activity marks the end of the process.

Summary of the Supplier: Credit Check Subprocess

To view the properties of the Supplier: Credit Check subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Supplier: Credit Check subprocess, you see that the subprocess consists of four unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Credit Check Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process checks whether the total cost of the order is greater than 2000. If the total cost is equal to or less than 2000, the process ends at this point. If the total cost is greater than 2000, the process initiates a credit check on the buyer and then ends.

Supplier: Credit Check Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

XML Compare Tag Value (Number) (Node 2)

This Standard external Java function activity compares the value of a particular XML tag set in the event message with a test value. At this node, the process compares the total cost from the purchase order event message with the test value 2000.

Credit Check (Node 3)

This activity occurs only if the total cost of the purchase order is greater than 2000. This event activity raises a credit check event. Currently this event is not defined. The activity represents a point in the process where you can integrate a credit check.

End (Node 4)

This Standard function activity marks the end of the process.

Summary of the Supplier: Stock Check Subprocess

To view the properties of the Supplier: Stock Check subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Supplier: Stock Check subprocess, you see that the subprocess consists of three unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Stock Check Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process performs a stock check to determine if the ordered item is in stock. The subprocess ends at this point.

Supplier: Stock Check Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Stock Check (Node 2)

Currently, this activity does nothing. It represents a point in the process where you can integrate a function that performs a stock check.

End (Node 3)

This Standard function activity marks the end of the process.

Summary of the Supplier: Advanced Shipment Notice Subprocess

To view the properties of the Supplier: Advanced Shipment Notice subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Supplier: Advanced Shipment Notice subprocess, you see that the subprocess consists of four unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Advanced Shipment Notice Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process checks the shipping details for the purchase order. Then the process sends an advanced shipment notice to the buyer. The subprocess ends at this point.

Supplier: Advanced Shipment Notice Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Check Shipping Details (Node 2)

Currently, this activity does nothing. It represents a point in the process where you can integrate a function that checks the shipping details for the purchase order.

Supplier: Send ASN (Node 3)

This event activity sends the B2B Advanced Shipment Notice event message to the buyer, using the outbound agent on the Supplier system and the inbound agent on the Buyer system identified by the Get Agent Details activity in the Supplier: Get Order Details subprocess.

End (Node 4)

This Standard function activity marks the end of the process.

Summary of the Supplier: Send Supplier Invoice Subprocess

To view the properties of the Supplier: Send Supplier Invoice subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. This process activity is not runnable, indicating that it cannot be initiated as a top level process to run but must be called from a higher level process.

When you display the Process window for the Supplier: Send Supplier Invoice subprocess, you see that the subprocess consists of four unique activities. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Supplier: Send Supplier Invoice Process Diagram

The subprocess begins at node 1 with the Start activity. At node 2, the process creates an invoice for the items ordered in the purchase order. Then the process sends the invoice to the buyer. The subprocess ends at this point.

Supplier: Send Supplier Invoice Subprocess Activities

Following is a description of each activity in the subprocess, listed by the activity's display name.

Start (Node 1)

This Standard function activity marks the start of the process.

Create Invoice (Node 2)

Currently, this activity does nothing. It represents a point in the process where you can integrate a function that creates an invoice for the items ordered in the purchase order.

Supplier: Send Invoice (Node 3)

This event activity sends the B2B Invoice event message to the buyer, using the outbound agent on the Supplier system and the inbound agent on the Buyer system identified by the Get Agent Details activity in the Supplier: Get Order Details subprocess.

End (Node 4)

This Standard function activity marks the end of the process.

B2B Purchase Order Event

This event is raised on the Buyer system when you submit a purchase order from the Buyer Workbench demonstration page.

demo.oracle.wf.b2b.po.create

Oracle Workflow provides four default subscriptions to the B2B Purchase Order event. The first subscription adds a correlation ID to the event message when the B2B Purchase Order event is raised locally. The correlation ID consists of the prefix PO followed by the event key (the order number). This subscription is enabled by default. The following table lists the properties defined for this subscription.

The second subscription sends the event message to the Buyer: Top Level PO process in the Event System Demonstration item type when the B2B Purchase Order event is raised locally. This subscription is enabled by default. The following table lists the properties defined for this subscription.

The third subscription modifies the correlation ID in the event message when the B2B Purchase Order event is received from an external source. The correlation ID consists of the prefix SO followed by the event key (the order number). This subscription is enabled by default. The following table lists the properties defined for this subscription.

The fourth subscription sends the event message to the Supplier: Top Level Order process in the Event System Demonstration item type when the B2B Purchase Order event is received from an external source. This subscription is enabled by default. The following table lists the properties defined for this subscription.

B2B Purchase Order Acknowledgement Event

This event is sent from the Supplier system to the Buyer system as a purchase order acknowledgement after the B2B Purchase Order event is received and processed.

demo.oracle.wf.b2b.po.ack

Oracle Workflow provides two default subscriptions to the B2B Purchase Order Acknowledgement event. The first subscription adds a correlation ID to the event message when the B2B Purchase Order Acknowledgement event is received from an external source. The correlation ID consists of the prefix PO followed by the event key (the order number). This subscription is enabled by default. The following table lists the properties defined for this subscription.

The second subscription sends the event message to the Buyer: Top Level PO process in the Event System Demonstration item type when the B2B Purchase Order Acknowledgement event is received from an external source. The subscription is enabled by default. The following table lists the properties defined for this subscription.

B2B Advanced Shipment Notice Event

This event is sent from the Supplier system to the Buyer system as an advanced shipment notice after the B2B Purchase Order event is received and processed.

demo.oracle.wf.b2b.po.asn

Oracle Workflow provides two default subscriptions to the B2B Advanced Shipment Notice event. The first subscription adds a correlation ID to the event message when the B2B Advanced Shipment Notice event is received from an external source. The correlation ID consists of the prefix PO followed by the event key (the order number). This subscription is enabled by default. The following table lists the properties defined for this subscription.

The second subscription sends the event message to the Buyer: Top Level PO process in the Event System Demonstration item type when the B2B Advanced Shipment Notice event is received from an external source. The subscription is enabled by default. The following table lists the properties defined for this subscription.

B2B Invoice Event

This event is sent from the Supplier system to the Buyer system as an invoice after the B2B Purchase Order event is received and processed.

demo.oracle.wf.b2b.po.invoice

Oracle Workflow provides two default subscriptions to the B2B Invoice event. The first subscription adds a correlation ID to the event message when the B2B Invoice event is received from an external source. The correlation ID consists of the prefix PO followed by the event key (the order number). This subscription is enabled by default. The following table lists the properties defined for this subscription.

The second subscription sends the event message to the Buyer: Top Level PO process in the Event System Demonstration item type when the B2B Invoice event is received from an external source. The subscription is enabled by default. The following table lists the properties defined for this subscription.

Copyright © 2003, 2005, Oracle. All rights reserved.