Oracle Workflow Details

Business processes today involve getting many types of information to multiple people according to rules that are constantly changing. Oracle Workflow lets you automate and continuously improve business processes, routing information of any type according to business rules you can easily change to people both inside and outside your enterprise.

Routing Information
Oracle Workflow lets you provide each person with all the information they need to take action. Oracle Workflow can route supporting information to each decision maker in a business process.

Defining and Modifying Business Rules
Oracle Workflow lets you define and continuously improve your business processes using a drag-and-drop process designer.
Unlike workflow systems that simply route documents from one user to another with some approval steps, Oracle Workflow lets you model sophisticated business processes. You can define processes that loop, branch into parallel flows and then rendezvous, decompose into subflows, and more. Because Oracle Workflow can decide which path to take based on the result of a stored procedure, you can use the full power of PL/SQL to express any business rule that affects a workflow process.

Delivering Electronic Notifications
Oracle Workflow extends the reach of business process automation throughout the enterprise and beyond to include any E-mail or Internet user. Oracle Workflow lets people receive notifications of items awaiting their attention via E-mail, and act based on their E-mail responses. You can even view your list of things to do, including necessary supporting information, and take action using a standard Web browser or an Oracle Applications Notification form.


Major Features and Definitions

Oracle Workflow Builder Oracle Workflow Builder lets you create, view, or modify a business process with simple drag and drop operations. Using the Workflow Builder, you can create and modify all workflow objects, including activities, item types, and messages. At any time you can add, remove, or change workflow activities, or set up new prerequisite relationships among activities. You can easily work with a summary-level model of your workflow, expanding activities within the workflow as needed to greater levels of detail. And, you can operate Oracle Workflow Builder from a desktop PC or from a disconnected laptop PC.

Workflow Engine The Workflow Engine embedded in the Oracle7 server monitors workflow states and coordinates the routing of activities for a process. Changes in workflow state, such as the completion of workflow activities, are signaled to the engine via a PL/SQL API. Based on flexibly-defined workflow rules, the engine determines which activities are eligible to run, and then runs them. The Workflow Engine supports sophisticated workflow rules, including looping, branching, parallel flows, and subflows.

Workflow Definitions Loader The Workflow Definitions Loader is a utility program that moves workflow definitions between database and corresponding flat file representations. You can use it to move workflow definitions from a development to a production database, or to apply upgrades to existing definitions. In addition to being a standalone server program, the Workflow Definitions Loader is also integrated into Oracle Workflow Builder, allowing you to open and save workflow definitions in both a database and file.

Complete Programmatic Extensibility Oracle Workflow lets you include your own PL/SQL procedures as activities in your workflows. Without modifying your application code, you can have your own program run whenever the Workflow Engine detects that your program's prerequisites are satisfied.

Electronic Notifications Oracle Workflow lets you include users in your workflows to handle activities that cannot be automated, such as approvals for requisitions or sales orders. Electronic notifications are routed to a role, which can be an individual user or a group of users. Any user associated with that role can act on the notification.
Each notification includes a message associated with it, which contains all the information a user needs to make a decision, as well as possible responses. Oracle Workflow interprets each response and moves on to the next workflow activity.

Personal Inbox Users who connect to Oracle Applications can see all the notifications awaiting their attention in a common Notification Viewer form, or Personal Inbox. Choosing a notification takes users to a Notification Details window that describes any actions they need to take. The Notification Details window can take users directly to an Oracle Applications form where they can perform the necessary action.

Electronic Mail Integration Electronic mail (E-mail) users can receive notifications of outstanding work items and can respond to those notifications using their E-mail application of choice. An E-mail notification can include an HTML attachment that provides another means of responding to the notification.

Internet-Enabled Workflow Any user with access to a standard Web browser can be included in a workflow. Web users can access a Notification Web page to see their outstanding work items, then navigate to additional pages to see more details or provide a response.

Monitoring and Administration Workflow administrators and users can view the progress of a work item in a workflow process by connecting to the Workflow Monitor using a standard Web browser that supports Java. The Workflow Monitor displays an annotated view of the process diagram for a particular instance of a workflow process, so that users can get a graphical depiction of their work item status. The Workflow Monitor also displays a separate status summary for the work item, the process, and each activity in the process.

Workflow Processes
Oracle Workflow manages business processes according to rules that you define. The rules, which we call a workflow process definition, include the activities that occur in the process and the relationship between those activities. An activity in a process definition can be an automated function defined by a PL/SQL stored procedure, a notification to a user or role that may optionally request a response, or a subflow that itself is made up of a more granular set of activities.
A workflow process is initiated when an application calls a set of Oracle Workflow Engine APIs. The Workflow Engine takes over by driving the relevant work item defined by the application, through a specific workflow process definition. According to the workflow process definition, the Workflow Engine performs automated steps and invokes appropriate agents when external processing is required.

Implementing Oracle Workflow

After you install Oracle Workflow, you implement it for your site by setting up the roles, icons, notification templates, background engines, and access levels appropriate for your enterprise.

Required Set Up Steps

Step 1: If you are using the standalone version of Oracle Workflow, you must map OracleWorkflow's directory service to the users and roles currently defined in your organization's directory repository by constructing views based on those database tables. The Notification System uses these views to send notifications to the performers specified in your activities. Your roles can be either individual users or a group of users. Oracle Workflow provides example directory services views that you can modify and reload.

Step 2: If you are using the standalone version of Oracle Workflow, you must create a view called WF_LANGUAGES that identifies the languages defined in your Oracle7 installation. Oracle Workflow uses this view to create in its translation tables, a row that maps to a row found in its non-translated base table for each installed language.

Step 3: If you are using the standalone version of Oracle Workflow, you must define an environment variable called WF_RESOURCES.

Step 4: After you install and configure Oracle WebServer, identify the Web Agent to be used by Oracle Workflow.

Step 5: Once you define your Oracle Workflow directory service, you need to identify the role that should have access to Oracle Workflow's administration features such as the Find Processes web page.

  Step 6: Configure Oracle WebServer to point to the Java code required to run the Workflow Monitor and optionally customize the company logo that appears in Oracle Workflow's web pages.

Step 7: If you are using the standalone version of Oracle Workflow, secure your Workflow database connection using Oracle WebServer security.

Step 8: Set up the Notification Mailer program so that users can receive notifications by E-mail if that is an option you are providing to your users.

Step 9: Set up background Workflow Engines to control the load and throughput of the primary Workflow Engine on your system. You can specify the cost threshold level of your primary and background engines to determine the activities an engine processes and the activities an engine defers.

Optional Set Up Steps

Step 10: You can modify the templates for your electronic mail notifications.

Step 11: You can include additional icons to your Oracle Workflow Icons subdirectory to customize the diagrammatic representation of your workflow processes. Use custom icons to provide meaningful symbols for each activity you define.

Other Workflow FeaturesBefore deploying Oracle Workflow and custom process definitions to other branches of your enterprise, you can protect your data from further modification by determining the level of access your users have to the data.

You can also use the Workflow Definitions Loader to load workflow process definitions from flat files to the database without using Oracle Workflow Builder.

[If you ever need to determine the version of the Oracle Workflow server you are running, you can connect to your Workflow server account using SQLPLUS and run a script called wfver.sql.]

Step 1: Setting Up an Oracle Workflow Directory Service

Oracle Workflow offers you flexibility in defining who your workflow users and roles are. You determine the directory repository you want Oracle Workflow to reference for users and roles information by creating three views based on the database tables that make up that repository. The views are: WF_USERS, WF_ROLES, and WF_USER_ROLES.

Oracle Workflow provides three local tables called WF_LOCAL_USERS, WF_LOCAL_ROLES, and WF_LOCAL_USER_ROLES which you can use to add information about users and roles not included in your existing directory repository.

[Note: Currently you must use SQL*PLUS or create your own custom application interface to enter data into these WF_LOCAL tables.]

WF_USERS The WF_USERS view should reference information about all the individuals in your organization who may receive workflow notifications. Create this view, making sure it contains the following columns:

Name--The internal name of the user as referenced by the Workflow Engine and Notification System. For example, an internal name for a user can be mbeech or 009, where 009 represents the user's employee ID.

The Name column must be sourced from a column that is less than 30 characters long and is all uppercase. If your source table does not have a column that meets these criteria, DO NOT use string functions to force these restrictions. Instead, define the Name column to be : so that Oracle Workflow can reference the original base table where users are stored and a unique user in that table. For example, "PER_PEOPLE:009" represents a user whose employee ID is 009 and is stored in the personnel table called PER_PEOPLE.

Display_Name--The display name of the user. An example of a display name can be 'Beech, Matthew'.

Description--An optional description of the user.

Notification_Preference--Indicate how this user prefers to receive notifications. A value of MAILTEXT or MAILHTML allows users to receive and respond to notifications by E-mail or by E-mail with HTML attachments, respectively. A value of QUERY allows users to query notifications from the Notifications Web page or Notification Viewer form. Finally, a value of SUMMARY allows users to get periodic E-mail summaries of their open notifications. However, to respond to the individual notifications, they have to query the notification from the Notification Web page or Notification Viewer form.

[A notification preference of MAILTEXT or MAILHTML also allows users to query their notifications from the Notifications Web page or Notification Viewer form.]

Language--The value of the Oracle7 NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of the user's notification session. Refer to your Oracle7 user's guide or installation manual for the list of supported language conventions.

Territory--The value of the Oracle7 NLS_TERRITORY initialization parameter that specifies the default territory-dependant date and numeric formatting used in the user's notification session. Refer to your Oracle7 user's guide or installation manual for the list of supported territory conventions.

Email_Address--A valid electronic mail address for this user or a mail distribution list defined by your electronic mail system.

Fax--A Fax number for the user.

Orig_System--A code that you assign to the directory repository that this view is based on. For example, if this view is based on the personnel data stored in a Human Resource Management System, Orig_System can be defined as PER.

Orig_System_ID--The primary key that identifies the user in this repository system. For example, Orig_System_ID can be defined as the value stored in a column called PERSON_ID in a Human Resources database table called PER_PEOPLE.

Status--The availability of the user to participate in a workflow process. The possible statuses are: active (ACTIVE), unavailable for an extended period (EXTLEAVE), permanently unavailable (INACTIVE), and temporarily unavailable (TMPLEAVE). These statuses are also stored in the lookup type called WFSTD_AVAILABILITY_STATUS.

WF_ROLES The WF_ROLES view should reference information about all the roles in your organization who may receive workflow notifications. Create this view, making sure it contains the following columns pertaining to the roles in your repository, similar to those described for WF_USERS:

It is required that you also define each user identified by WF_USERS as a role.

[Note: If a user is a member of a role and the user information is different from the role information, the role information will override the user information when the Notification System delivers a notification to the role. For example, suppose a user has a notification preference of 'SUMMARY', and the user is also a member of a multi-user role, whose notification preference is 'MAILHTML'. When a notification is assigned to the multi-user role, the user will receive a single notification message addressed to the role, as opposed to a summary message that includes that notification in it.]

*Name
*Display_Name
Description
*Notification_Preference
*Language
*Territory
*Email_Address
*Fax
Orig_System
Orig_System_ID

The Name column must be sourced from a column that is less than 30 characters long and is all uppercase. If your source table does not have a column that meets these criteria, DO NOT use string functions to force these restrictions. Instead, define the Name column to be : so that Oracle Workflow can reference the original base table where roles are stored and a unique role in that table. For example, "PER_POSITION:009" represents a position whose ID is 009 and is stored in the personnel table called PER_POSITION.

WF_USER_ROLES The WF_USER_ROLES view is an intersection of the users and roles in WF_USERS and WF_ROLES. Create this view, making sure it contains the following columns:

User_Name--The internal name of the user as listed in the view WF_USERS.
User_Orig_System--A code that you assign to the user directory repository as listed in the view WF_USERS.
User_Orig_System_ID--The primary key that identifies the user in the user directory repository as listed in the view WF_USERS.
Role_Name--The internal name of the role as listed in the view WF_ROLES.
Role_Orig_System--A code that you assign to the role directory repository as listed in the view WF_ROLES.
Role_Orig_System_ID--The primary key that identifies the role in the role directory repository as listed in the view WF_ROLES.

To take advantage of unique indexes when querying users, make sure you initially enter the usernames in your database in uppercase only. Forcing the usernames to uppercase in your view definition results in poor performance when accessing these views.
Warning: Avoid making a join to a view that contains a union as this results in poor database performance. Oracle7 is currently unable to preserve the indexes in that view when you make such a join. The workflow directory services views you create will most likely contain unions, therefore you should not join to them directly. If you need to retrieve data from any of the three directory services views, use the appropriate directory services API.

Overview of Notification Handling

Oracle Workflow sends a notification to a role when the Workflow Engine executes a notification activity in a workflow process. The notification activity may designate the role as being responsible for performing some human action or may simply relay process-related information to the role. To successfully deliver a notification to a role, the role must be defined in the Oracle Workflow directory service.
As a member of a role, you can view a notification using any one of four interfaces depending on your role's notification preference setting in the Oracle Workflow directory service. You can receive an E-mail for each individual notification, receive a single E-mail summarizing all your notifications, query the Workflow Notifications Web page or query the Workflow Notification Viewer form (for Oracle Applications users only) for your notifications.

Each notification message can include context-sensitive information about the process and directions on how to respond to the notification, if a response is required. The message can also include pointers to Web URLs and references to Oracle Applications forms that allow the user to get additional information related to the notification.
As a notification recipient, there may be occasions when you will not be able to view or respond to your notifications in a timely manner. Rather than create a bottleneck in a workflow process, you can take advantage of the Automatic Notification Handler to define rules that direct Oracle Workflow to automatically handle the notifications for you.

Step 2: Creating the WF_LANGUAGES View

The field values in the property pages of Oracle Workflow Builder and the workflow notifications delivered to your users can be translated to the languages defined in your Oracle installation. However, in order for this to be possible, you must create a view called WF_LANGUAGES that identifies the languages defined in your Oracle installation. Oracle Workflow uses this view to create in its translatable tables, a row for each language that maps to a row found in its non-translated base table.
The WF_LANGUAGES view must include the following columns:
Code--The language code.
Display_Name--The display name of the language.
NLS_Language--The value of the Oracle NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of a session.
NLS_Territory--The value of the Oracle NLS_TERRITORY initialization parameter that specifies the default territory-dependant date and numeric formatting of a session.
NLS_Codeset--The code set for the language.
Installed_Flag--Flag to indicate if the language is installed and available for use.A sample WF_LANGUAGES view is included in the script of each of the predefined directory services that Oracle Workflow provides.

Step 3: Setting the WF_RESOURCES Environment Variable

If you are using the standalone version of Oracle Workflow, you must set an environment variable called WF_RESOURCES to point to the language-dependent Oracle Workflow resource file (wf.res). The resource file generally resides under the res subdirectory of your Oracle Workflow server directory structure.
You do not need to set this environment variable if you are using the version of Oracle Workflow embedded in Oracle Applications. For Oracle Applications, the path of the language-dependent Oracle Workflow resource file is $FND_TOP/$APPLRSC/wf.res.

Step 4: Identifying the Oracle Web Agent used by Oracle Workflow

Oracle WebServer must be installed before installing Oracle Workflow. Once you finish installing and configuring Oracle WebServer, you must identify the Oracle Web Agent that Oracle Workflow should use to access its Web components.

To Identify a Web Agent for Oracle Workflow

1. Edit the file wfcfg.msg as follows:

WFTKN WF_WEB_AGENT 0
Replace with the base URL of the Oracle Web Agent you defined for Oracle Workflow in Oracle WebServer. The base URL should look similar to this: http:///
represents the server and TCP/IP port number on which your Web Listener accepts requests and represents the application virtual path of your Oracle Workflow PL/SQL agent. Each PL/SQL agent you configure connects to a particular database schema. See your Oracle WebServer documentation for more information.

[Note: If you are using the version of Oracle Workflow embedded in Oracle Applications, the file wfcfg.msg is located in the resource/ subdirectory under $FND_TOP. If you are using the standalone version of Oracle Workflow, the file is located in the Oracle Workflow server res/ subdirectory.]

2. Run the Workflow Resource Generator to load the contents of wfcfg.msg into the table WF_RESOURCES.

To run the Workflow Resource Generator: For the standalone version of Oracle Workflow:
1. The Workflow Resource Generator program is located in the bin subdirectory of the Oracle Workflow directory structure.
2. Run the program from your operating system prompt as follows:
To generate a binary resource file from a source file (.msg), type: wfresgen [-v] -f
Replace with the full path and name of the resource file you want to generate, and with the full path and name of your source file. The optional -v flag causes the program to validate the source file against the binary resource file.
To upload seed data from a source file (.msg) to the database table WF_RESOURCES, type: wfresgen [-v] -d

Replace with the username, password and SQL*Net connect string or alias to your database and with the full path and name of the source file you want to upload. The optional -v flag causes the program to validate the source file against the database.

For Oracle Workflow embedded in Oracle Applications:
1. The Workflow Resource Generator program is registered as a concurrent program. You can run the Workflow Resource Generator concurrent program from the Submit Requests form or from the command line.
2. To run the concurrent program from the Submit Requests form, navigate to the Submit Requests form.
Note: Your system administrator needs to add this concurrent program to a request security group for the responsibility that you want to run this program from.

3. Submit the Workflow Resource Generator concurrent program as a request.

4. In the Parameters window, enter values for the following parameters:

Destination Type
Specify "Database", to upload seed data to the database table WF_RESOURCES from a source file (.msg), or "File", to generate a resource file from a source file.

Destination
If you specify "File" for Destination Type, then enter the full path and name of the resource file you wish to generate. If you specify "Database" for Destination Type, then the program automatically uses the current database account as its destination.
Source
Specify the full path and name of your source file.
5. Choose OK to close the Parameters window.
6. When you finish modifying the print and run options for this request, choose Submit to submit the request.
7. Rather than use the Submit Requests form, you can also run the Workflow Resource Generator concurrent program from the command line using one of two commands.

- To generate a resource file from a source file, type: WFRESGEN apps/pwd 0 Y FILE res_file source_file
- To upload seed data to the database table WF_RESOURCES from a source file, type: WFRESGEN apps/pwd 0 Y DATABASE source_file
Replace apps/pwd with the username and password to the APPS schema, replace res_file with the file specification of a resource file, and replace source_file with the file specification of a source file (.msg). A file specification is specified as:
@:[

/.../]file.ext

Step 5: Identifying the Oracle Workflow Administration Role

You can specify who has administrator privileges in Oracle Workflow by defining an Oracle Workflow administration role. Any user in the administration role can run the Oracle Workflow Find Processes web page, which provides full access to Oracle Workflow's administration features. In addition, any user in the administration role can view any other user's notifications.

To define the Oracle Workflow administration role
1. Edit the file wfcfg.msg as follows:

WFTKN WF_ADMIN_ROLE 0 Replace with the internal name of a role defined in the Oracle Workflow directory service. For example:

WFTKN WF_ADMIN_ROLE 0 SYSADMIN
Any user associated with this role will have full workflow administration privileges.

[Note: If you are using the version of Oracle Workflow embedded in Oracle Applications, the file wfcfg.msg is located in the resource/ subdirectory under $FND_TOP. If you are using the standalone version of Oracle Workflow, the file is located in the Oracle Workflow server res/ subdirectory.]

2. If you want all users and roles to have workflow administration privileges, such as in a development environment, replacewith an asterisk (*) as follows:

WFTKN WF_ADMIN_ROLE 0 *
3. Run the Workflow Resource Generator to load the contents of wfcfg.msg into the table WF_RESOURCES.

Step 6: Setting Up the Workflow Monitor and Oracle Workflow's Web Pages

To use Oracle Workflow's web pages and the Workflow Monitor at your site, you must first install Oracle WebServer. Refer to your Oracle WebServer documentation for additional information.
Once Oracle WebServer is installed, you can customize the company logo that appears on Oracle Workflow's web pages. In addition, you must configure Oracle WebServer to point to the Java code required to run the Workflow Monitor.
Use a web browser that supports JavaScript to connect to the Notification Web page or a web browser that supports Java Development Kit (JDK), Version 1.1.4 and Abstract Windowing Toolkit (AWT) to connect to the Workflow Monitor.

To Set Up Oracle Workflow's Web Components: 
1. Copy or rename your company logo file (in .gif format) to WFLOGO.gif located in the appropriate directory.
For the standalone version of Oracle Workflow: //wf/java/oracle/wf/
//wf/java represents your .
For the Oracle Applications-embedded version of Oracle Workflow: /oracle/wf/
2. Connect to the Oracle WebServer home page. The URL to use is specific to your installation, but is typically a specific port on the server machine where you installed Oracle WebServer: http://:/
If you are using Oracle WebServer 2.x, complete Steps 3 through 8. If your are using Oracle WebServer 3.x, complete Steps 9through 15.
3. Choose WebServer Manager to go to the Oracle WebServer Administration page.
4. Choose Oracle Web Listener from the Oracle WebServer Administration page to go to the Oracle Web Listener Administration page. Enter the username and password for your Admin Server.
5. Scroll towards the bottom of the page to the Oracle Web Listeners list and locate the listener that you configured for the Oracle Workflow Server. Choose CONFIGURE for that Listener.
6. In the Oracle Web Listener Administration Server Advanced Configuration page, scroll to the Oracle Web Listener Configuration Parameters section and choose Directory Mappings to go to the Directory Mappings section.
7. Add the following entry in the Directory Mappings section to map the directory structure where java is located to a directory structure where the Java code exists: File-System Directory Flag Virtual Directory// NR /wfjava/
8. Choose Modify Listener.
9. Enter the username and password for your Oracle Web Application Server.
10. Choose Web Application Server Manager to go to the Administration home page.
11. Choose Oracle Web Listener from the Administration home page to go to the Oracle Web Listener Administration page.
12. Scroll towards the bottom of the page to the Oracle Web Listeners list and locate the listener that you configured for the Oracle Workflow Server. Choose CONFIGURE for that Listener.
13. In the Oracle Web Listener Advanced Configuration page, choose the Directory link from the list of links on the left hand frame to go to the Directory Mappings section.
14. Add the following entry in the Directory Mappings section to map the directory structure where java is located to a directory structure where the Java code exists:

File-System Directory-Flag - Virtual Directory

// NR /wfjava/
15. Choose Modify Listener.

Step 7: Secure the Workflow Database Connection Descriptor (DCD)

If you are not using Oracle Self-Service Web Applications with Oracle Workflow, then Oracle Workflow's web pages must rely on the user authentication feature of Oracle WebServer to provide security. To ensure that only authorized users can access workflow processes, the URLs that generate Oracle Workflow's web pages must be protected by the Oracle WebServer authentication feature. This feature requires users to enter a username and password before accessing theses pages by protecting the Oracle Workflow database connection descriptor (DCD). Follow the steps listed:
To protect the DCD in Oracle WebServer 2.x

or
To protect the DAD in Oracle WebServer 3.x

[Note: The database access descriptor (DAD) in Oracle WebServer 3.x is synonymous to the database connection descriptor (DCD) in Oracle WebServer 2.x.]

To protect the DCD in Oracle WebServer 2.x:
1. Connect to the Oracle WebServer Administration page.
2. Choose the Oracle Web Listener link.
3. Choose Configure for the appropriate listener.
4. Choose Security: Access Control and Encryption.
5. Enter usernames and passwords in either the Basic or Digest Authentication sections.
Basic authentication allows you to assign passwords to users, assign users to groups, and define sets of users and groups, called "realms." You can then assign the users, groups, and realms to specific files and directories, requiring requestors to provide a username and password to gain access. Basic authentication sends unencrypted passwords across the network, making this method subject to subversion. Basic authentication is not recommended when security is critical.
Digest authentication is the same as basic authentication except that it sends passwords encrypted across the network in the form of a cryptographic checksum, also called a "digest." You should use this scheme whenever authentication is required, although some older web browsers may not support it.
6. Assign your users to a group for the appropriate authentication method.
7. Assign the group to a realm for the appropriate authentication method.
8. Choose the Modify Listener button to save your changes.
9. Navigate back to the Listener Administration page.
10. Choose Web Request Broker and choose the Modify link.
11. Scroll to the Protecting Applications section.
12. Enter the following values in the fields: Virtual Path Scheme Realm
represents the virtual path of the PL/SQL agent's shared files, as defined in the Applications and Directories section of the Web Request Broker Administration page. Specify the scheme as either Basic or Digest. represents the realm name that you specified for your authentication scheme.
13. Choose Modify WRB Configuration to save your changes.
14. Restart the listener.
Note: You must set protection in the Web Request Broker section and not the Protection section of the Listener Administration page.

To protect the DAD in Oracle WebServer 3.x:
1. Connect to the Oracle Web Application Server Administration page.
2. Choose the Oracle Web Application Server link.
3. Choose the Authorization Server link.
4. Select either the Basic, Digest, or Database authentication scheme by choosing the appropriate link.
Basic authentication allows you to assign passwords to users, assign users to groups, and define sets of users and groups, called "realms." You can then assign the users, groups, and realms to specific files and directories, requiring requestors to provide a username and password to gain access. Basic authentication sends unencrypted passwords across the network, making this method subject to subversion. Basic authentication is not recommended when security is critical.
Digest authentication is the same as basic authentication except that it sends passwords encrypted across the network in the form of a cryptographic checksum, also called a "digest." You should use this scheme whenever authentication is required, although some older web browsers may not support it.
Database authentication allows you to authenticate the username and password pair against a database by using the username and password to logon to an Oracle RDBMS. The realm of database authentication consists of two parts: a Database Access Descriptor (DAD) and optionally a database role. The DAD identifies the database to check against. The username and password, if available in the DAD, is ignored. The database role allows that only a subset of database users (those who have the privilege to assume the role) be authenticated.
5. If you select either Basic or Digest authentication, enter usernames and passwords for your users, assign your users to a group, then assign the group to a realm for your authentication method.
If you select Database authentication, assign groups to a realm, then for each group, specify the DAD to check against, and optionally specify the roles to be authenticated.
6. Choose Modify to save your changes.
7. Navigate back to the Oracle Web Application Server Administration page.
8. Choose Cartridge Administration, then Cartridge Summary (Web Request Broker).
9. Choose the Protection link in the frame on the left side of the page to go to the Protecting Applications section.
10. Enter the following values in these fields to protect your realm: Virtual Path Scheme Realm
Basic_Oracle>
represents the virtual path of the PL/SQL cartridge's shared files, as defined in the Applications and Directories section of the Web Request Broker Administration page. Specify the scheme as either Basic, Digest, or Basic_Oracle (for the Database scheme). represents the realm name that you specified in Step 5.
11. Choose Modify WRB Configuration to save your changes.
12. Restart the listener.

Step 8: Implementing the Notification Mailer

The Notification Mailer is a program that performs E-mail send and response processing for the Oracle Workflow Notification System. It polls the database for messages that have to be sent, and performs the following action for each message:
Resolves the recipient role to a single E-mail address, which itself can be a mail list.
Switches its database session to the role's preferred language and territory as defined by the directory service.
Generates the message and any optional attachments using the appropriate message template.
Sends the message via UNIX Sendmail, Oracle Office/InterOffice, or any MAPI-compliant mail application on Windows 95 or Windows NT.The Notification Mailer also processes responses by interpreting the text of messages mailed to its response mail account and calling the appropriate notification response function to complete the notification.
Once you set up the Notification Mailer to run, it continually polls the database for messages to send and checks its response mail account for responses to process. You do not have to do anything else unless you have a need to shut it down and restart it again with different parameters.
Attention: The Notification Mailer will shut itself down if a database failure is encountered or if the PL/SQL package state for the session is invalid due to dropping or replacing of package definitions. If you are using the standalone version of Oracle Workflow, you can restart the Notification Mailer manually or run a shell script that restarts the Notification Mailer if it ever exits with a failure. If you are using the version of Oracle Workflow embedded in Oracle Applications, you can use the concurrent manager to restart the Notification Mailer program manually or schedule it to restart periodically.
You can install and set up the Notification Mailer to run against UNIX Sendmail, Oracle Office/InterOffice, or a MAPI-compliant mail application on Windows 95 or Windows NT. However, before doing so, you must set up a least one mail account for the Notification Mailer in one of these three mail applications. You must also define three folders or files in your mail account to use response processing.

To Run a Perpetual Shell Script for the Notification Mailer
1. If you are running the standalone version of Oracle Workflow, you need to set up a perpetual shell script that restarts the Notification Mailer if it shuts down due to failure. Oracle Workflow provides a sample shell script to restart the UNIX Sendmail or Oracle Office/InterOffice Notification Mailer. The script is called wfmail.csh and it is located in the Oracle Workflow bin subdirectory on your server.
Note: Use a similar technique to restart the Window NT Notification Mailer.
2. Enter the following command at your operating script prompt to run the shell script: wfmail.csh -f
Replace with the full path name of the configuration file that contains the parameters you want to run with the Notification Mailer. The shell script passes all command line arguments directly to the Notification Mailer executable.

Step 9: Setting Up Background Workflow Engines

When the Workflow Engine initiates and performs a process, it completes all necessary activities before continuing to the next eligible activity. In some cases, an activity can require a large amount of processing resource or time to complete. Oracle Workflow lets you manage the load on the Workflow Engine by setting up supplemental engines to run these costly activities as background tasks. In these cases, the costly activity is deferred by the Workflow Engine and run later by a background engine. The main Workflow Engine can then continue to the next available activity, which may occur on some other parallel branch of the process.
A background engine must also be set up to handle timed out notification activities. When the Workflow Engine comes across a notification activity that requires a response, it calls the Notification System to send the notification to the appropriate performer, then sets the notification activity to a status of 'NOTIFIED' until the performer completes the notification activity. Meanwhile, a background engine set up to handle timed out activities periodically checks for 'NOTIFIED' activities and whether these activities have time out values specified. If a 'NOTIFIED' activity does have a time out value, and the current date and time exceeds that time out value, the background engine marks that activity as timed out and calls the Workflow Engine. The Workflow Engine then resumes by trying to execute a transition activity.
You can define and start up as many background engines as you like to check for deferred and timed out activities. Background engines can be restricted to handle activities associated with specific item types, and within specific cost ranges. A background engine runs until it completes all eligible activities at the time it was initiated. Generally, you should set the background engine up to run periodically by either using a script to restart the background engine periodically (for the standalone version of Oracle Workflow), or scheduling the Background Process concurrent program to resubmit periodically (for the version of Oracle Workflow embedded in Oracle Applications).

Step 10: Modifying Your Message Templates

Use the System: Mailer item type in Oracle Workflow Builder to configure the templates that Oracle Workflow uses to send E-mail notifications. The System: Mailer item type has attributes that represent every part of the notification message. You can reorganize the layout of these attributes in each template to customize the E-mail messages sent by the Notification system. 
The messages of the System: Mailer item type are not true messages; rather they act as templates for any E-mail messages the Notification system sends. System: Mailer messages determine the basic format of an E-mail notification, including what header information to include, or whether and where to include details such as the message due date and priority.
Warning: Do not add new attributes or delete existing attributes from the messages templates in the System: Mailer item type.

Workflow Open Mail Message The Notification system uses the Workflow Open Mail message as a template for all E-mail notifications that require a response. The template includes generic instructions on how to respond to a notification. It also includes the following information about a message: message priority, date that a response is due, or if the notification is forwarded from another user, and any comments from the sender or forwarder of the message.
The Workflow Open Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
START_DATE -The date the message is sent.
TO -The role the notification is sent to; the performer.
SUBJECT -The subject line defined in the message.
BODY -The text of the body defined in the message.
COMMENT -Comments added by the sender or the forwarder.
PRIORITY -The priority of the notification message.
DUE_DATE -The date by which a response is required, specified in the notification activity.
NOTIFICATION -Required notification code used to identify the information in the notification.
RESPONSE -The user response section as defined by the Respond message attributes in the actual notification message definition.

You can customize the boilerplate text that appears in the body of the Workflow Open Mail template. The body of the Workflow Open Mail template contains the following default text, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent:
Oracle Workflow Notification

&COMMENT
-------------------------------------------
Response Instructions for &NOTIFICATION
To submit your response, reply to this message, including this note with your reply. The first lines of your reply must be your responses to the notification questions. Instructions below detail exactly what should be placed on each line of your reply.

&RESPONSE
-------------------------------------------
Notification Details:
&BODY
Due Date: &DUE_DATE

Workflow Open FYI Mail Message The Notification system uses the Workflow Open FYI Mail message as a template for all E-mail notifications that do not require a response. The template indicates that the notification is for your information (FYI) and does not require a response. In addition to the message, the template also includes any comments from the sender or forwarder of the message.
The Workflow Open FYI Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
START_DATE -The date the message is sent.
TO -The role the notification is sent to; the performer.
SUBJECT -The subject line defined in the message.
BODY -The text of the body defined in the message.
COMMENT -Comments added by the sender or the forwarder.
PRIORITY -The priority of the notification message.
DUE_DATE -The date by which a response is required, specified in the notification activity.
NOTIFICATION -Required notification code used to identify the information in the notification.

You can customize the text that appears in the body of the Workflow Open Mail template. The body of the Workflow Open Mail template initially contains the following default text, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent:
Oracle Workflow Notification (FYI)
&COMMENT

-------------------------------------------
&BODY

Workflow Canceled Mail Message The Workflow Canceled Mail message informs the recipient that a previously sent notification is cancelled. It has the following message attributes, with values that are drawn from the message definition associated with the cancelled notification activity:
START_DATE -The date the original message was sent.
TO -The role the notification is sent to; the performer.
SUBJECT -The subject line of the original message.
BODY -The text of the original message.
COMMENT -Comments added by the sender or the forwarder.
PRIORITY -The priority of the notification message.
DUE_DATE -The date by which a response is required, specified in the notification activity.
NOTIFICATION -Required notification code used to identify the information in the notification.

The body of the Workflow Canceled Mail template initially contains the following customizable text:
You earlier received the notification shown below. That notification is now canceled, and no longer requires your response. You may simply delete it along with this message.
--------------------------------------------
&BODY

Workflow Invalid Mail Message The Workflow Invalid Mail message gets sent to a user when a user responds incorrectly to a notification. The message describes how to respond to the notification correctly. The message attributes are as follows:
START_DATE -The date the original message was sent.
TO -The role the notification is sent to; the performer.
SUBJECT -The subject line of the original message.
BODY -The text of the original message.
COMMENT -Comments added by the sender or the forwarder.
PRIORITY -The priority of the notification message.
DUE_DATE -The date by which a response is required, specified by the notification activity.
NOTIFICATION -Required notification code used to identify the information in the notification.
RESPONSE -The user response section as defined by the Respond message attributes in the original message definition.
MAIL_ERROR_MESSAGE -An error message that the mail program generates if an error occurs upon processing the response.
MAIL_ERROR_ STACK -An error stack of arguments that the mail program generates if an error occurs upon processing the response. You can provide this information to your support representative if the problem cannot be resolved with a corrected response.

The body of the Workflow Invalid Mail template initially contains the following customizable text:
Oracle Workflow Notification
&COMMENT
NOTE: Your previous response to this message was
invalid (see error message below). Please resubmit your
response.
Error Message: &MAIL_ERROR_MESSAGE
Error Stack: &MAIL_ERROR_STACK
--------------------------------------------------
Response Instructions for &NOTIFICATION
To submit your response, reply to this message, including this original with your reply. This note contains a special NID string that is required to process the response. The first lines of your reply must be your responses to the notification questions. You should enter one line for each response required by the notification, any additional lines will be ignored. You may leave a line blank to accept the default value for that specific response. You must supply a value or a blank line for each question asked. Instructions below detail exactly what should be placed on each line of your reply.
&RESPONSE
-------------------------------------------
Notification Details:
&BODY
Due Date: &DUE_DATE

Workflow Closed Mail Message The Workflow Closed Mail message informs the recipient that a previously sent notification is now closed. It has the following message attributes, with values that are drawn from the message definition associated with the closed notification activity:
START_DATE -The date the original message was sent.
TO -The role the notification is sent to; the performer.
SUBJECT -The subject line of the original message.
BODY -The text of the original message.
COMMENT -Comments added by the sender or the forwarder.
PRIORITY -The priority of the notification message.
DUE_DATE -The date by which a response is required, specified in the notification activity.
NOTIFICATION -Required notification code used to identify the information in the notification.

The body of the Workflow Closed Mail template initially contains the following customizable text:
You earlier received the notification shown below. That notification is now closed, and no longer requires your response. You may simply delete it along with this message.
--------------------------------------------
&BODY

Workflow Summary Mail Message The Notification system uses the Workflow Summary Mail message as a template to send a summary of workflow notifications to users and roles that have their notification preference set to 'SUMMARY' in the Oracle Workflow directory service. The Workflow Summary Mail message summarizes all currently open notifications for a given user/role. It has the following message attributes, with values that are drawn from the message definition associated with the open notification activity:
BODY -The subject line of the notification.
USER_NAME -The user/role the notification summary is sent to; the performer.
SYSDATE -The current date.

The body of the Workflow Summary Mail template initially contains the following customizable text:
NOTE: Please use a Web browser or Notification form to view notification details.
------------------------------------------------------
Summary of Notifications for '&USER_NAME'
&SUMMARY

Workflow Warning Mail Message The Notification system uses the Workflow Warning Mail message as a template to send a message to user if it receives unsolicited mail from that user. The Workflow Warning Mail message has the message attribute SYSDATE, which identifies the current date.
The body of the Workflow Warning Mail template initially contains the following customizable text, where the last portion of the text includes the mail originally received from the user:
Messages sent to this account are processed automatically by the Oracle Workflow Notification Mailer. The message you sent did not appear to be in response to a notification. If you are responding to a notification, please use the response template that was included with your notification. Take care to include the 'NID' line of the template in your reply. If you are not responding to a notification, please do not send mail to this account.
------------------------------------------------------------
From: &UFROM
Subject: &USUBJECT
&UBODY

Reviewing Notifications via Electronic Mail You can have your workflow notifications delivered to you as E-mail messages if your notification preference is set to 'MAILTEXT' or 'MAILHTML' in the Oracle Workflow directory service views. If your E-mail tool supports attachments, an E-mail notification may include an HTML attachment with the content and response fields of the notification formatted in a Web page. The user may respond either by replying to the E-mail as specified by the directions included in the E-mail, or by activating the HTML attachment and filling in the requested information in the resulting Web page.
You can receive E-mail notifications using any mail application that is MAPI-compliant running on Windows NT or that Oracle Office/InterOffice or UNIX Sendmail can provide a gateway to. The following example shows a notification received through Oracle Office.

The E-mail notification is based on a standard template defined in Oracle Workflow Builder. It describes the syntax the reply should follow, and lists the information needed to confirm the notification. The message also identifies any custom site information, specifies the due date of the message, and details any information necessary to process the response.

Step 11: Adding Custom Icons to Oracle WorkflowOracle Workflow

Builder looks for icons in the Icon subdirectory of the Oracle Workflow area on your PC. The Icon subdirectory is defined in the registry of Oracle Workflow Builder. The Oracle Workflow area is typically the WF20 subdirectory within your ORACLE_HOME for Windows 95 or NT directory structure.
Workflow provides a variety of icons that you can use with your activities and processes. You can add any icon files to this area as long as they are Windows icon files with the .ico suffix.
If you want the custom icons that you include in your Oracle Workflow Builder process definition to appear in the Workflow Monitor when you view the process, you must do the following:
Convert the custom icon files (.ico) to gif format (.gif).
Copy the .gif files to a directory where the Workflow Monitor can access them:
For the standalone version of Oracle Workflow -- //wf/java/oracle/wf/icons
For the Oracle Applications-embedded version of Oracle Workflow -- /oracle/wf/icons

Overview of Oracle Workflow Access Protection

Access protection is a feature that prevents workflow seed data created by a 'seed data provider' from being modified by a 'seed data consumer'. Here, a 'seed data provider' is any organization that creates 'seed data' for other organizations ('seed data consumers') to use in defining and customizing workflow process. In Oracle Workflow, seed data refers to either of the following:
-Workflow object definitions that can and should be customized to meet a certain consumer's needs.
-Workflow object definitions protected against customization because they represent standards that may also be upgraded in the future by the provider.

For example, the Oracle Workflow development team is a provider of seed data called the Standard item type. The Standard item type contains standard activities that can be dropped into any custom workflow process. The development team at your organization's headquarters may create a custom workflow process definition that references activities from the Standard item type. This makes the headquarters team a consumer of the Standard item type seed data.

Now suppose the headquarters team wants to deploy the custom workflow definition that it created to teams at other regional offices. The headquarters team, as seed data providers, may want to do the following:
Identify certain workflow objects in its custom workflow definition as corporate standards that the regional teams should adhere to and not modify.

Designate certain objects in its deployed process as customizable for the regional offices to alter to their offices' needs.The headquarters team can satisfy both requirement using the access protection feature in Oracle Workflow. Access protection lets seed data providers protect certain data as 'read-only', while allowing other data to be customized. Also during a seed data upgrade, access protection lets the seed data provider overwrite any existing protected seed data with new versions of that seed data, while preserving any customizations made to customizable seed data.

Oracle Workflow assigns a protection and customization level to every workflow object definition stored in the database and requires every user of Oracle Workflow to operate at a certain access level. The combination of protection, customization, and access levels make up the access protection feature and determines whether a user can modify a given workflow object. The level in all three cases, is a numeric value ranging from 0 to 1000 that indicates the relationship between different organizations as providers and consumers of seed data.

The following range of levels are presumed by Oracle Workflow:
0-9 : Oracle Workflow
10-19 : Oracle Application Object Library
20-99 : Oracle Applications development
100-999 : Customer organization. You can determine how you want this range to be interpreted. For example, 100 can represent headquarters, while 101 can represent a regional office, and so on.
1000 : Public

Access Level

Each user of Oracle Workflow operates the system at a certain access level according to the range of levels listed above. A "user of Oracle Workflow" in this case, represents someone who is operating Oracle Workflow Builder, or the Workflow Definitions Loader program, which loads workflow process definitions from a file into a database. As a seed data provider, you should always operate Oracle Workflow Builder at the same consistent access level because the level you work at affects the protection level of the seed data you create.

You can view your access level as follows:
In Oracle Workflow Builder, select About Workflow from the Help menu.
If you are going to run the Workflow Definitions Loader program, check the value for the environment variable WF_ACCESS_LEVEL on your workflow server.

[Note: The Workflow Definitions Loader program references the access level stored in the environment variable called WF_ACCESS_LEVEL, which you must define when you install Oracle Workflow on your server. If you do not define this environment variable, the Workflow Definitions Loader simply assumes a default access level of 100. ]
[Note: When you install the standalone version of Oracle Workflow on your server, you need to define this variable in an environment file. The default environment file is APPLSYS.env. If you do not define this environment variable, the Workflow Definitions Loader simply assumes a default access level of 100.]

Protection Level

Whenever you create a workflow object in Oracle Workflow Builder, you have the option of protecting the object at a certain level. An object's protection level controls whether other users can modify the object based on their access levels.
To change the protection level of an object, display the Access tab of the object's property page. The protection level that you set for an object is dependent on your current access level. You can control access to an object in one of four ways:
Allow access to everyone--By default, all users are allowed access to an object if both "Preserve Customizations' and 'Lock at this Access Level' are unchecked in the Access tab, that is the protection level is equal to 1000.
Limit access to users with access levels equal to your own or higher--If you check 'Preserve Customizations' in the Options region of the Access tab, you designate the object as being customizable by anyone with an access level equal to or higher than your current access level. You should only mark objects as customizable if you are sure that you will not be providing upgraded versions of this object in the future that would overwrite other user's customizations to it.
Limit access to users with access levels equal to your own or lower--If you check 'Lock at this Access Level', you protect the object and ensure that the object may only be modified by users with an access level equal to or lower than your current access level. Users operating at a higher access level will see a small lock on the workflow object's icon, indicating that the object can be used but not modified. Protect any objects that you want to define as standard components that will not change unless you provide a global upgrade. For this reason, it is important that you always operate at the same consistent access level.
Limit access to users with access levels equal to your own--If you check both 'Lock at this Level' and 'Preserve Customizations' you ensure that the object cannot be modified by anyone other than users operating at your current access level.

Preserve Customizations
Lock at this Access Level
Access Level applied to Object

Object may be updated by any access level.
X

Object may only be updated by users with access levels equal to or higher than your current access level.

X
Object may only be updated by users with access levels equal to or lower than your current access level.
X
X
Object cannot be updated by any access level except for your current access level.

Attention: If you have installed the beta version of Microsoft's Internet Explorer on your PC, which automatically installs an early version of a file called comctl32.dll, you may not see the lock icons appear on the locked objects in Oracle Workflow Builder. To correct this problem, install the production version of Microsoft's Internet Explorer to replace comctl32.dll with the latest copy.

The protection and access levels in Oracle Workflow are present to remind you that certain workflow objects should not be modified or should only be modified by someone accessing the tool at an authorized access level. It is not intended as a means of securing or source controlling your workflow objects.
Attention: Most workflow objects provided by Oracle Workflow have a protection level of 0, which means the objects can only be modified by the Oracle Workflow team, operating at an access level of 0. If you attempt to alter your access level to 0 and modify the data anyway, your customizations will not be supported, especially if Oracle Workflow provides an upgrade to the seed data that may overwrite the modifications you make to the originally protected data.

Customization Level Every workflow object, in addition to having a protection level, also records a customization level equal to your access level when you modify the object and save it to a database or file. For example, if a workflow object is customizable (protection level is 1000), and you customize it at an access level of 100, you now mark the object as having a customization level of 100. The customization level indicates that the object can only be further modified by someone operating at an access level equal to or higher than the customization level. So in this example, you can only customize the object further if your access level is 100 or higher. If you are operating at an access level lower than an object's customization level, you will see a small lock on that workflow object's icon, indicating that the object can be used but not modified

This ensures that a customizable object that has been customized never gets overwritten during a seed data upgrade because the upgrade always occurs with the Workflow Definitions Loader operating at an access level below the customized object's customization level.

Using the Workflow Definitions Loader

Rather than use the File Save or File Open menu options in Oracle Workflow Builder, you can also run a program called Workflow Definitions Loader to save or load process definitions from a database or flat file.

When you upgrade your database, use the Workflow Definitions Loader to preserve and back up your process definitions to a flat file. When the database upgrade is complete, use the Loader program again to upload the definitions back into your database. You can also use the Loader program to upgrade your database with a newer version of a process definition or to transfer process definitions to other databases.
The Workflow Definitions Loader program accepts several parameters that vary depending on the mode that you run the Loader program. Following is a summary of the Loader program's various modes and behavior.

Workflow Definitions Loader Behavior
Mode - Data Transfer - Data Protected at Access Level Less Than Loader Access Level -Customized Data
UPGRADE --------File to Database ----Preserved ----Preserved
UPLOAD ----------File to Database ----Preserved ----Overwritten
FORCE ------------File to Database ----Overwritten ----Overwritten
DOWNLOAD ------Database to File ----Not Applicable ----Not Applicable

Workflow Directory Services APIs

The following APIs can be called by an application program or a workflow function in the runtime phase to retrieve information about the users and roles in the Oracle Workflow directory services. These APIs are defined in a PL/SQL package called WF_DIRECTORY.
GetRoleUsers
GetUserRoles
GetRoleInfo
IsPerformer
CurrentUser
UserActive
GetUserName
GetRoleName

GetRoleUsers

Syntax:
procedure GetRoleUsers
(role in varchar2,
users out UserTable);

Description: Returns a table of users for a given role.
Arguments (input) role: A valid role name.

GetUserRoles

Syntax:
procedure GetUserRoles
(user in varchar2,
roles out RoleTable);

Description: Returns a table of roles that a given user is assigned to.

Arguments (input):user: A valid username.

GetRoleInfo

Syntax :
procedure GetRoleInfo
(Role in varchar2,
Display_Name out varchar2,
Email_Address out varchar2,
Notification_Preference out varchar2,
Language out varchar2,
Territory out varchar2);

Description : Returns the following information about a role:
--Display name
--Email address
--Notification Preference ('QUERY', 'MAILTEXT', 'MAILHTML', 'SUMMARY')
--Language
--Territory

Arguments (input) role: A valid role name.

IsPerformer

Syntax :
function IsPerformer
(user in varchar2,
role in varchar2);

Description : Returns true or false to identify whether a user is a performer of a role.
Arguments (input):

user: A valid username.
role: A valid role name.

CurrentUser

Syntax :
function CurrentUser
return varchar2;

Description : Returns the current Application Object Library username. This function is useful only for the version of Oracle Workflow embedded in Oracle Applications.

UserActive

Syntax :
function UserActive
(username in varchar2)
return boolean;

Description : Determines if a user is currently active and available to participate in a workflow. Returns TRUE if the user is active, otherwise it returns FALSE.

GetUserName

Syntax :
procedure GetUserName
(p_orig_system in varchar2,
p_orig_system_id in varchar2,
p_name out varchar2,
p_display_name out varchar2 );

Description : Returns a Workflow display name and username for a user given the system information from the original user and roles repository.

Arguments (input) :

p_orig_system: Code that identifies the original repository table.
p_orig_system_id : ID of a row in the original repository table.

GetRoleName

Syntax :
procedure GetRoleName
(p_orig_system in varchar2,
p_orig_system_id in varchar2,
p_name out varchar2,
p_display_name out varchar2 );

Description :Returns a Workflow display name and role name for a role given the system information from the original user and roles repository.

Arguments (input) :
p_orig_system: Code that identifies the original repository table.
p_orig_system_id : ID of a row in the original repository table.

Predefined Directory Services

Oracle Workflow provides scripts for you to implement any one of three directory service environments. If you are using the version of Oracle Workflow embedded in Oracle Applications you automatically:
Integrate your Oracle Workflow directory service with a unified Oracle Applications environment.If you are using the standalone version Oracle Workflow, you can choose to implement one of the following two directory services or create your own:
A directory services with native Oracle users.
A directory services with local workflow users.You can customize any of these directory services environments further by editing and rerunning their scripts against your Workflow Server.
Attention: If you create your own directory service or edit any of the predefined directory services listed above, you should run the script wfdirchk.sql to validate your directory service data model. The script is located on your server in the Oracle Workflow admin/sql subdirectory for the standalone version of Oracle Workflow, or in the sql subdirectory under $FND_TOP for the version of Oracle Workflow embedded in Oracle Applications.

Response Processing

You must create three folders or files in your response mail account before starting the Notification Mailer to process responses. The three folders or files serve to hold discarded, unprocessed, and processed messages.
The Notification Mailer does the following to check for response messages:
Logs into the response mail account.
Checks for messages. If a message exists, it reads the message, checking for the notification ID and node identifier.
If the message is not a notification, it moves it to the discard folder.
If the message is a notification for the current node, it moves the message to the unprocessed folder.
If the message is a notification, but for the wrong node, it does not move the message so that the Notification Mailer for the correct node can read it later.The Notification Mailer then opens the unprocessed folder to process each response. For each message, it:
Retrieves the notification ID.
Checks to see if the message bounced by referring to a specified tag file, if any. If the message bounced, it reroutes it or updates the notification's status and stops any further processing depending on the specifications of the tag file.
Checks the Oracle Workflow database for this notification.
If the notification does not exist, it moves it to the discard folder.
If the notification exists, but is closed or canceled, it moves it to the discard folder.
If the notification exists and is open, it verifies the response values with the definition of the message's response attributes in the database. If a response is invalid, it sends an Workflow Invalid Mail message to the recipient role. If the responses are valid, it calls a Respond function to complete the notification response and saves the change to the database.
Moves the message for the completed notification to the processed folder and closes the unprocessed folder.The Notification Mailer then truncates the discard and processed folders, if a '-' precedes the discard and process parameters specified in the configuration file, and logs out of the mail and database accounts.

Viewing Notifications from a Web Browser

You can use any Web browser that supports JavaScript and Frames to view and respond to your notifications.

To View Notifications from a Web Browser
To Reassign a Notification to Another User

Workflow Monitor

The Workflow Monitor is a tool that allows you to view and administer the status of a specific instance of a workflow process. You can use the point-and-click interface to display detailed status information about activities in the process as well as about the process as a whole. The Workflow Monitor can be run in 'USER' or 'ADMIN' mode, where 'ADMIN' mode provides additional details and functionality pertinent only to a workflow administrator.