Oracle Workflow

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 LevelEvery 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.