Release 2.6.4
Part Number B15852-02
Contents
Previous
Next
| Oracle Workflow Administrator's Guide Release 2.6.4 Part Number B15852-02 | Contents | Previous | Next |
After you install Oracle Workflow, implement it for your site by setting up the preferences and components appropriate for your enterprise.
Related Topics
Oracle Workflow Hardware and Software Requirements
Overview of Required Setup Steps for the Standalone Version of Oracle Workflow
Overview of Required Setup Steps for the Version of Oracle Workflow Embedded in Oracle Applications
Identifying the Version of Your Oracle Workflow Server
Oracle Workflow Setup Checklist
The components of Oracle Workflow require the following hardware and software configurations. Some of the requirements are different for standalone Oracle Workflow and Oracle Workflow embedded in Oracle Applications. Check the installation documentation for your installation of Oracle Workflow to determine the exact requirements for your version.
Oracle Workflow Builder is installed using Oracle Universal Installer. The Oracle Workflow Builder installation includes the Oracle Net Services and Required Support Files which it requires. You should install Oracle Workflow Builder on an IBM, Compaq or 100% compatible personal computer with the following:
A Pentium processor or better
Clock speed of 66 Mhz or greater (90 Mhz or greater is recommended)
Network card
SVGA color monitor
Microsoft Windows 98, Windows 2000, Windows Server 2003, Windows XP, or Windows NT 4.0 or higher
At least 65 Mb of available disk space to install Oracle Workflow Builder, Oracle Net Services, and Required Support Files.
At least 32 Mb of memory, 64 Mb recommended
Note: Oracle Net Services require and only support the use of Microsoft's TCP/IP drivers.
The Oracle Workflow Server requires the following:
Oracle8i Database Release 3 (8.1.7) or higher, Oracle9i Database, or Oracle Database 10g, Enterprise or Standard Edition
Note: To determine which database versions are supported by your version of Oracle Workflow, please refer to the installation documentation for your installation.
At least 40 Mb of available disk space for Oracle Workflow Server once it is installed in your Oracle Home
At least 128 Mb of memory, 256 Mb recommended
Oracle Net Services, corresponding to the version of your Oracle Database
SQL*Plus, corresponding to the version of your Oracle Database
Note: While the version of Oracle Workflow offered to Oracle8i Database Standard Edition customers is exactly the same as the version offered to Oracle8i Database Enterprise Edition customers, it is important to note that Oracle Workflow leverages Oracle8i Database functionality. Consequently, using an Oracle8i Database Standard Edition database limits some of the features available for use by the Oracle Workflow Business Event System.
For example:
You cannot create any additional queues in Oracle8i Database Standard Edition beyond the default queues provided by Oracle Workflow. If you require additional queues, you should choose Oracle8i Database Enterprise Edition.
Oracle Advanced Queuing propagation in Oracle8i Database Standard Edition does not support propagating messages outside the local database. If you require messages to be propagated to other systems, you should choose Oracle8i Database Enterprise Edition.
In Oracle9i Database and higher, however, these restrictions no longer apply. Exactly the same functionality is available with Oracle Workflow in an Oracle9i Database and higher, Standard Edition, as in an Oracle9i Database and higher, Enterprise Edition.
To send and receive e-mail notifications, you must have an SMTP mail server set up for outbound messages and and an IMAP4 compliant mail server set up for inbound messages.
To send and respond to e-mail notifications with HTML attachments, your e-mail application should support HTML attachments and you should have a Web browser application that supports JavaScript and Frames to view the attachment.
The Oracle Workflow Web pages require Oracle HTTP Server and mod_plsql to be installed on a server machine. The Oracle HTTP Server and mod_plsql components are included with the Oracle Database in Oracle8i Database Release 3 (8.1.7) and higher, as well as with Oracle Application Server.
To view notifications you need a Web browser application that supports JavaScript and Frames. To view the Workflow Monitor you need a Web browser that supports Java Development Kit (JDK) Version 1.1.8 or higher and Abstract Windowing Toolkit (AWT), such as Netscape Communicator version 4.76 or a higher version of 4.7x, or Microsoft Internet Explorer version 5.0x or 5.5x.
To sign notification responses with certificate-based digital signatures in Oracle Applications, you must use a PC with Microsoft Windows 98, Windows 2000, Windows XP, or Windows NT 4.0 or higher. Additionally, you must access the notifications using Microsoft Internet Explorer version 5.0x, version 5.5x, or higher, or Netscape Communicator version 4.76 or a higher version of 4.7x.
To run external Java function activities in the standalone version of Oracle Workflow, you must have Java Development Kit (JDK) Version 1.4 installed.
To use the Workflow XML Loader in the standalone version of Oracle Workflow, you must have Java Development Kit (JDK) Version 1.4 installed. To use the Workflow XML Loader in the version of Oracle Workflow embedded in Oracle Applications, you must have Java Development Kit (JDK) Version 1.3 installed.
To extract the HTML help for the standalone version of Oracle Workflow, you need an unzip utility.
To implement Oracle Internet Directory integration, you must have Oracle Internet Directory installed. To implement single sign-on integration, you must install Oracle Workflow shipped with Oracle Application Server, you must implement Oracle Internet Directory integration, and you must have Oracle Application Server Single Sign-On installed and have mod_osso installed with Oracle HTTP Server.
Note: To implement single sign-on integration, you must use a version of the Oracle Database that is certified with your version of Oracle Application Server Single Sign-On.
Set up the default Oracle Workflow user preferences for your entire enterprise using the Global Preferences Web page. The Global Preferences Web page also lets you define your workflow administrator role and your Workflow Web agent. See: Setting Global User Preferences.
Ensure that a directory service is set up to provide information about the individuals and roles in your organization who may utilize Oracle Workflow functionality and receive workflow notifications. Oracle Workflow provides two predefined directory services from which you can choose. See: Setting Up an Oracle Workflow Directory Service.
Define an environment variable called WF_RESOURCES if your Workflow server is installed on a UNIX platform. See: Setting the WF_RESOURCES Environment Variable.
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. See: Setting Up Background Workflow Engines.
Set up the Business Event System to communicate business events between systems using event subscription processing and Workflow process event activities. See: Setting Up the Business Event System.
Set up the default Oracle Workflow user preferences for your entire enterprise using the Workflow Configuration page. The Workflow Configuration page also lets you define your workflow administrator role. See: Setting Global User Preferences.
Ensure that a directory service is set up to provide information about the individuals and roles in your organization who may utilize Oracle Workflow functionality and receive workflow notifications. In an Oracle Applications installation, directory service views for users and roles from the unified Oracle Applications environment are automatically implemented for you. See: Setting Up an Oracle Workflow Directory Service.
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. See: Setting Up Background Workflow Engines.
Set up the Business Event System to communicate business events between systems using event subscription processing and Workflow process event activities. See: Setting Up the Business Event System.
Attention: Although your Oracle Workflow installation automatically sets up the following for you, you may want to refer to their appropriate sections for additional background information:
You can partition the WF_ITEM_ACTIVITY_STATUSES, WF_ITEM_ACTIVITY_STATUSES_H, WF_ITEM_ATTRIBUTE_VALUES, and WF_ITEMS tables for performance gain. See: Partitioning Workflow Tables.
If you are using the standalone version of Oracle Workflow, you can synchronize the user information in your Workflow directory service with Oracle Internet Directory. Additionally, if you have installed Oracle Workflow shipped with Oracle Application Server, you can also use Oracle Internet Directory integration to implement single sign-on integration. See: Synchronizing Workflow Directory Services with Oracle Internet Directory.
Set up additional languages if you want to use Oracle Workflow in languages other than English. See: Setting Up Additional Languages.
Set up one or more notification mailers if you want to allow your users to receive notifications by e-mail. See: Implementing Notification Mailers.
You can modify the templates for your electronic mail notifications. See: Modifying Your Message Templates.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can give users access to the Advanced Worklist and Personal Worklist Web pages from any responsibility you choose. See: Adding Worklist Functions to User Responsibilities.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can use the WF: Notification Reassign Mode profile option to control which reassign modes are available to users from the Notification Details page. See: Setting the WF: Notification Reassign Mode Profile Option.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can control the item types for which users can define vacation rules, using the WF: Routing Rule Item Types lookup type and the WF: Vacation Rules - Allow All profile option. See: Setting Up Vacation Rule Options.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can set up users to enable electronic signatures in notification responses. See: Setting Up for Electronic Signatures.
Customize the company logo that appears in Oracle Workflow's Web pages. See: Customizing the Logo on Oracle Workflow's Web Pages.
You can include additional icons to your Oracle Workflow Icons subdirectory to customize the diagrammatic representation of your workflow processes. Use custom symbols for each activity you define. See: Adding Custom Icons to Oracle Workflow.
Set up the Java Function Activity Agent if you are using the standalone version of Oracle Workflow and you want to run external Java function activities. See: Setting Up the Java Function Activity Agent.
Before 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. See: Overview of Oracle Workflow Access Protection.
You can also use the Workflow Definitions Loader to load workflow process definitions from flat files to the database without using Oracle Workflow Builder. See: Using the Workflow Definitions Loader.
If you are using the Business Event System, you can use the Workflow XML Loader to load XML definitions for Business Event System objects between a database and a flat file. See: Using the Workflow XML Loader.
For details about configuring Oracle Workflow security, see: Oracle Workflow Security.
If you ever need to determine the version of the Oracle Workflow server you are running, you can connect to your Oracle Workflow database account using SQL*Plus and run a script called wfver.sql. See: wfver.sql.
In addition, all Oracle Workflow modules, such as the Workflow Definitions Loader, Oracle Workflow Builder, notification mailers, and the Workflow Monitor, automatically verify that the module is compatible with the version of the Oracle Workflow server that it is operating against. This version compatibility check helps to prevent problems such as running Oracle Workflow Builder 2.6.3 against an Oracle Workflow 2.0.3 database.
The following table lists Oracle Workflow setup steps. The table shows whether each step is required or optional and whether the step applies to the standalone or embedded version of Oracle Workflow or both. You need to perform optional steps only if you plan to use the related feature or complete certain business functions.
Note: For the latest documentation updates, product alerts, technical notes, and troubleshooting tips, please refer to the Oracle Workflow area on OracleMetaLink.
The following flowchart shows the Oracle Workflow setup steps in a graphical format, indicating which steps are required and which are optional.
Setup Flowchart
Partitioning addresses key issues in supporting very large tables and indexes by letting you decompose them into smaller and more manageable pieces called partitions. SQL queries and DML statements do not need to be modified in order to access partitioned tables. However, once partitions are defined, DDL statements can access and manipulate individual partitions rather than entire tables or indexes. In this way, partitioning can simplify the manageability of large database objects. Also, partitioning is entirely transparent to applications.
You can optionally run a script to partition certain Workflow tables that store runtime status data. For the version of Oracle Workflow embedded in Oracle Applications, the script is called wfupartb.sql; for the standalone version of Oracle Workflow, the script is called wfupart.sql. This step is highly recommended for performance gain.
The script partitions four Workflow tables and recreates the associated indexes. The following table shows the Workflow tables and indexes on which the script runs.
| Table | Indexes |
|---|---|
| WF_ITEM_ACTIVITY_STATUSES | WF_ITEM_ACTIVITY_STATUSES_PK, WF_ITEM_ACTIVITY_STATUSES_N1, and WF_ITEM_ACTIVITY_STATUSES_N2 |
| WF_ITEM_ACTIVITY_STATUSES_H | WF_ITEM_ACTIVITY_STATUSES_H_N1 and WF_ITEM_ACTIVITY_STATUSES_H_N2 |
| WF_ITEM_ATTRIBUTE_VALUES | WF_ITEM_ATTRIBUTE_VALUES_PK |
| WF_ITEMS | WF_ITEMS_PK, WF_ITEMS_N1, WF_ITEMS_N2, and WF_ITEMS_N3 |
Before running the partitioning script, you should back up these four tables so that you can restore them in case the script fails.
To run the script, you must have sufficient free space on the table and index tablespaces. During the creation of the partitioned tables, the script requires slightly more diskspace than the underlying tables, in the same tablespace where the underlying tables are located. Similarly, sufficient free space is required for the index tablespace.
Additionally, you should allow sufficient time for the script to run. The amount of time needed depends on the amount of data in the tables. When the tables already contain existing data, such as after an upgrade from a previous release, the script requires more time than it does when the tables are empty, such as after a fresh installation of Oracle Workflow. To minimize the time required, run the script as early as possible in your setup process.
Attention: If you are running the partitioning script through Oracle Net Services, then you must set the TWO_TASK variable before you begin.
For Oracle Workflow embedded in Oracle Applications, the wfupartb.sql script is located in the admin/sql subdirectory under $FND_TOP. Use the script as follows:
sqlplus <apps_user>/<apps_passwd> @wfupartb <fnd_user>
<fnd_passwd> <apps_user> <apps_passwd>
For example:
sqlplus apps/apps @wfupartb applsys apps apps apps
For standalone Oracle Workflow, the wfupart.sql script is located in the wf/admin/sql subdirectory in your Oracle Home. Use the script as follows:
sqlplus <wf_user>/<wf_passwd> @wfupart <wf_user> <wf_passwd>
For example:
sqlplus owf_mgr/owf_mgr @wfupart owf_mgr owf_mgr
If the partitioning script fails, you must perform any necessary cleanup manually. Since the script's operations are DDL operations running in nologging mode, rollback is not possible.
Related Topics
Users can control how they interact with Oracle Workflow by specifying user preferences. As a workflow administrator, you also have access to globally set default user preference values for the entire enterprise, using the Global Preferences page in standalone Oracle Workflow or the Workflow Configuration page in Oracle Applications. An individual user can override a default user preference at any time by modifying his or her preference setting, using the User Preferences Web page in standalone Oracle Workflow or the Preferences page in Oracle Applications.
See: Setting User Preferences, Oracle Workflow User's Guide and Set Preferences, Oracle Applications User's Guide.
To Set Global Preferences for Standalone Oracle Workflow
Use a Web browser to connect to the Oracle Workflow home page, and then choose the Global Preferences link:
<webagent>/wfa_html.home
Alternatively, you can connect directly to the Global Preferences Web page:
<webagent>/wf_pref.edit?edit_defaults=Y
<webagent> represents the base URL of the Web agent you configured for Oracle Workflow in your Web server.
Attention: These are secured pages, so if you have not yet logged on as a valid user in the current Web session, you will be prompted to do so before the page appears.
Note: You must have workflow administrator privileges to access the Global Preferences page. In standalone Oracle Workflow, workflow administrator privileges are initially assigned to all users by default. You can change that assignment in this page.
The Global Preferences Web page displays a summary of your current global preferences, except for the LDAP password which is not displayed for security reasons. Choose Update to modify these preferences.
In the Workflow Administrator field, use the list of values to select the role to which you want to assign workflow administrator privileges. Any user associated with this role can run the Oracle Workflow Find Processes Web page, which provides full access to the Workflow Monitor administration features. In addition, any user in the administration role can view any other user's notifications, launch test and demonstration processes, and access the Event Manager Web pages. See: Setting Up an Oracle Workflow Directory Service.
If you want all users and roles to have workflow administrator privileges, such as in a development environment, enter an asterisk (*) in the Workflow Administrator field.
Note: To find out which role currently has workflow administrator privileges, without accessing the Global Preferences page, you can use the following command:
select text
from wf_resources
where name = 'WF_ADMIN_ROLE';
After installing Oracle Workflow, you should change the Workflow Administrator preference from the default setting to the role that you want to have administrator privileges. For the standalone version of Oracle Workflow, the default setting after installation is an asterisk (*). You can log in as any user to access the Global Preferences page and specify the preferences you want.
In the Workflow Web Agent field, enter the base URL of the Oracle Web agent you defined for Oracle Workflow in Oracle HTTP Server.
Note: The list of values fields that are implemented in many of Oracle Workflow's Web pages will not function properly unless you specify the base URL of your Oracle Workflow Web agent in this field.
The base URL should look like this if you are using Oracle HTTP Server as your Web server:
http://<server.com:portID>/pls/<DAD_name>
<server.com:portID> represents the server and TCP/IP port number on which your Web listener accepts requests, and <DAD_name> represents the name of the Database Access Descriptor (DAD) configured for the Oracle Workflow database schema.
See your Oracle HTTP Server documentation for more information.
The Local System field displays the system name for the database where this installation of Oracle Workflow is located. Oracle Workflow automatically creates the system definition for this database in the Event Manager during installation. The Business Event System treats this system as the local system. See: Systems, Oracle Workflow Developer's Guide.
Note: The Local System setting is specific to this installation of Oracle Workflow and is not included when Business Event System data is replicated to other systems.
In the System Status field, use the list of values to select the Business Event System status that you want to assign to the local system.
Enabled - Subscriptions are executed on all events.
Local Only - Subscriptions are executed only on events raised on the local system.
External Only - Subscriptions are executed only on events received by inbound agents on the local system.
Disabled - No subscriptions are executed on any events.
Note: Oracle Workflow sets the system status to Enabled by default. After you finish setting up the Business Event System, you can change the setting to the status you want for event processing.
Note: The System Status setting is specific to this installation of Oracle Workflow and is not included when Business Event System data is replicated to other systems.
If you are implementing Oracle Internet Directory synchronization, specify the Lightweight Directory Access Protocol (LDAP) server information for the LDAP directory to which you want to connect.
LDAP Host - The host on which the LDAP directory resides.
LDAP Port - The port on the host.
If you are implementing Oracle Internet Directory synchronization, specify the LDAP user account used to connect to the LDAP server. This LDAP user account must have write privileges.
LDAP User Name - The LDAP user. This user name is required to bind to the LDAP directory. For example:
cn=orcladmin
Old LDAP Password - Enter your current LDAP password. Oracle Workflow validates this password before letting you change it.
New LDAP Password - Enter the new LDAP password you want to use. The password must be at least five characters long.
Repeat LDAP Password - Enter your new LDAP password again in this field to confirm it. You must enter exactly the same value that you entered in the New LDAP Password field.
Note: LDAP password values are masked as asterisks in the display and are stored in encrypted form.
If you are implementing Oracle Internet Directory synchronization, specify the directories for the change log and the user records.
LDAP Changelog Base Directory - The LDAP node under which change logs are located. For example:
cn=changelog
LDAP User Base Directory - The LDAP node under which user records can be found. For example:
cn=Base, cn=OracleSchemaVersion
In the Language and Territory fields, use the list of values to select the NLS_LANGUAGE and NLS_TERRITORY combination that defines the default language-dependent behavior and territory-dependent formatting of your users' notification sessions.
In the Date Format field, specify an Oracle Database-compliant date format that defines the default date format for the workflow database sessions of all users. An example of an Oracle Database-compliant date format is DD-Mon-RRRR. If you do not specify a date format, then the date format defaults to DD-MON-YYYY.
Note: Oracle Workflow may include a time element when relevant for certain displayed dates, even if you do not include a time format with your date format. If you specify a time format along with your date format, then in those situations when Oracle Workflow displays a time element, you will see two time elements following your date.
Leave the Document Home Node field blank. This functionality is reserved for future use.
In the 'Send me electronic mail notifications' field, use the list of values to select a notification preference:
HTML mail with attachments - Send notifications as HTML e-mail with attached links to the Notification Details page. Users must read their mail using an HTML e-mail viewer.
Plain text mail with HTML attachments - Send notifications as plain text e-mail but include the HTML-formatted version of the notifications and links to the Notification Details page as attachments.
Plain text mail - Send notifications as plain text e-mail.
Plain text summary mail - Send a summary of all notifications as plain text e-mail. Users must use the Worklist Web page to take action on individual notifications.
Do not send me mail - Do not send the notifications as e-mail. Users must view the notifications and take action from the Worklist Web page.
HTML mail - Send notifications as HTML e-mail only, without any standard attachments. If custom attachments have been defined for individual notifications in a process, however, those attachments will still be included. Users must read their mail using an HTML e-mail viewer.
Note: The "HTML summary mail" preference is not applicable for standalone Oracle Workflow. This notification preference is currently only available with Oracle Workflow embedded in Oracle Applications.
Choose OK once you are satisfied with your changes.
Note: These global language, territory, document home node, and notification preferences are saved to the Oracle Workflow Preferences table for a special user name called -WF_DEFAULT-. The workflow administrator role, workflow Web agent, local system, and LDAP information is saved to the Workflow Resources table.
Attention: The Language, Territory, and Notification preference settings in the Global Preferences and User Preferences Web pages are valid only if your directory service views map the Language, Territory, and Notification_Preference columns to the Oracle Workflow preferences table. If you map to some other preference source or set a hard-coded value to these columns, any changes you make to the preferences via the preferences Web pages are ignored. See: Setting Up an Oracle Workflow Directory Service.
To Set Global Preferences for Oracle Workflow Embedded in Oracle Applications
Use a Web browser to navigate to the Workflow Configuration page, using a responsibility and navigation path specified by your system administrator. See: Oracle Workflow Administrator Navigation Paths.
Note: You must have workflow administrator privileges to set global workflow preferences in the Workflow Configuration page. If you do not have administrator privileges, you can view global workflow preferences, but you cannot modify them. In Oracle Applications, workflow administrator privileges are initially assigned to the SYSADMIN user by default. You can change that assignment in this page.
In the Workflow System Administrator field, select the role to which you want to assign workflow administrator privileges. Any user associated with this role can set global workflow preferences in this page, view workflows owned by any user and perform administrative operations in the Status Monitor, run test workflows in the Developer Studio, and maintain Business Event System objects and raise test events in the Event Manager. See: Setting Up an Oracle Workflow Directory Service.
If you want all users and roles to have workflow administrator privileges, such as in a development environment, enter an asterisk (*) in the Workflow System Administrator field.
Note: To find out which role currently has workflow administrator privileges, without accessing the Workflow Configuration page, you can use the following command:
select text
from wf_resources
where name = 'WF_ADMIN_ROLE';
After installing Oracle Workflow, you should change the Workflow Administrator preference from the default setting to the role that you want to have administrator privileges. For the version of Oracle Workflow embedded in Oracle Applications, the default setting after installation is SYSADMIN. You must log in as the SYSADMIN user to access the Workflow Configuration page and specify the preferences you want.
Note: The SYSADMIN role is different than the role associated with the System Administrator responsibility in Oracle Applications. If you want to assign workflow administrator privileges to this or any other Oracle Applications responsibility, you must set the Workflow System Administrator preference to the internal name of the workflow role associated with that responsibility.
You can query the WF_ROLES view to find the role name for a responsibility. For example, to find the role names for various administrator responsibilities in Oracle Applications, use the following command:
select name, display_name
from wf_roles
where display_name like '%Admin%';
If you set the Workflow System Administrator preference to the role name of a responsibility, then any Oracle Applications user with that responsibility will have workflow administrator privileges.
If you are integrating with Oracle Internet Directory, specify the Lightweight Directory Access Protocol (LDAP) server information for the LDAP directory to which you will connect. If you already configured these parameters while installing Oracle Application Server with Oracle E-Business Suite, Oracle Workflow displays those values here. For more information, see: Installing Oracle Application Server 10g with Oracle E-Business Suite Release 11i (OracleMetaLink note 233436.1) and Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On (OracleMetaLink note 261914.1).
Host - The host on which the LDAP directory resides.
Port - The port on the host.
Username - The LDAP user account used to connect to the LDAP server. This user name must have write privileges and is required to bind to the LDAP directory. For example:
cn=orcladmin
Old Password - Enter your current LDAP password. Oracle Workflow validates this password before letting you change it.
New Password - Enter the new LDAP password you want to use. The password must be at least five characters long.
Repeat Password - Enter your new LDAP password again in this field to confirm it. You must enter exactly the same value that you entered in the New LDAP Password field.
Note: LDAP password values are masked as asterisks in the display and are stored in encrypted form.
Change Log Base Directory - The LDAP node under which change logs are located. For example:
cn=changelog
User Base Directory - The LDAP node under which user records can be found. For example:
cn=Users,dc=oracle,dc=com
Specify details about the local system that identifies this installation of Oracle Workflow in the Business Event System. See: Systems, Oracle Workflow Developer's Guide.
System Name - The system name for the database where this installation of Oracle Workflow is located. Oracle Workflow automatically creates the system definition for this database in the Event Manager during installation.
Status - Select the execution status for the local system.
Enabled - Subscriptions are executed on all events. Oracle Workflow sets the system status to Enabled by default.
Local Only - Subscriptions are executed only on events raised on the local system.
External Only - Subscriptions are executed only on events received by inbound agents on the local system.
Disabled - No subscriptions are executed on any events.
Note: The local system settings are specific to this installation of Oracle Workflow and are not included when Business Event System data is replicated to other systems.
Specify default workflow preferences for your users.
Notification Style - Specify whether Oracle Workflow should send e-mail notifications to users, and if so, in what format. A user can override this default setting by specifying a different notification style in his or her individual Oracle E-Business Suite preferences.
HTML mail with attachments - Send notifications as HTML-formatted e-mail with attached links to the Notification Details page. Users must read their e-mail using an HTML e-mail client.
Plain text mail with HTML attachments - Send notifications as plain text e-mail but include the HTML-formatted version of the notifications and links to the Notification Details page as attachments.
Plain text mail - Send notifications as plain text e-mail.
Plain text summary mail - Send a summary of all notifications as plain text e-mail. Users must use the Worklist Web pages to view and take action on individual notifications.
Do not send me mail - Do not send the notifications as e-mail. Users must use the Worklist Web pages to view and take action on their notifications.
HTML mail - Send notifications as HTML-formatted e-mail only, without any standard attachments. If custom attachments have been defined for individual notifications in a process, however, those attachments will still be included. Users must read their e-mail using an HTML e-mail client.
HTML summary mail - Send a summary of all notifications as HTML-formatted e-mail, with a link to the Worklist page as well as links to each notification in the Notification Details page. Users must use the Worklist Web pages to view and take action on individual notifications.
Note: To send e-mail notifications, you must configure and run a notification mailer. Additionally, users who are to receive e-mail notifications must have an e-mail address defined. You can run a diagnostic test through Oracle Diagnostics to check that all users with a notification preference to receive e-mail have an e-mail address defined. See: Implementing Notification Mailers, Setting Up an Oracle Workflow Directory Service, and Oracle Workflow Diagnostic Tests.
Users can always access their notifications through the Worklist Web pages, even if their notification preference also includes e-mail notifications.
Browser Signing DLL Location - The location of the Capicom.dll file that is used for Web page operations with encryption in the Microsoft Internet Explorer browser. This preference is required only if you plan to use certificate-based digital signatures to confirm notification responses, and your users access Oracle Applications with Microsoft Internet Explorer.
By default, this preference is set to a URL at which the Capicom.dll file can be downloaded from Microsoft's Web site. In most cases, you do not need to change this setting. However, you can update this preference if the location of the Capicom.dll file changes, or if you choose to store a copy of the file on your local network and point to that location instead.
For more information about setting up for certificate-based signatures, see: Loading Certificates for Digital Signatures.
Review details about the JInitiator plugin in your Oracle Applications installation. Oracle Workflow uses JInitiator to launch Oracle Applications forms linked to notifications.
Class ID - The class identifier for this version of JInitiator.
Download Location - The location where the JInitiator executable is staged for download to users' client machines.
Version - The JInitiator version number.
For more information, refer to OracleMetaLink note 162488.1, "Complete Guide to JInitiator for Oracle's E-Business Suite: 11.5.x (11i)."
Note: The global notification and DLL location preferences are saved to the Oracle Workflow preferences table for a special user name called -WF_DEFAULT-. The workflow administrator role, LDAP, local system, and JInitiator information is saved to the Oracle Workflow resources table.
Oracle Workflow requires a directory service to provide information about the individuals and roles in your organization who may utilize Oracle Workflow functionality and receive workflow notifications. Oracle Workflow references this user and role information through the following views.
WF_USERS - Individual users.
WF_ROLES - Roles, which can have one or more users as members.
WF_USER_ROLES - Associations of users with the roles of which they are members.
Note: A role can contain only individual users as its members. It cannot contain another role. However, in Oracle Applications only, roles can be related to each other in a hierarchy so that users assigned to one role automatically inherit membership in its superior roles as well.
WF_USER_ROLE_ASSIGNMENTS_V - Assignments of users to roles, both direct and inherited through role hierarchy relationships. This view is used only in Oracle Applications.
See: Workflow Directory Service Views.
Oracle Workflow provides predefined directory services for you that are implemented by default during installation.
If you are using the standalone version of Oracle Workflow, you can choose one of two predefined directory services.
During installation, you can choose to integrate with Oracle Internet Directory as your directory repository. In this case, directory service views that support Oracle Internet Directory integration are automatically implemented for you. See: Integrating an Oracle Workflow Directory Service with Oracle Internet Directory and Synchronizing Workflow Directory Services with Oracle Internet Directory.
If you do not choose to integrate with Oracle Internet Directory, directory service views that use Oracle Database users and roles as your directory repository are automatically implemented for you by default. You should modify the default views to add e-mail addresses for these users if you want them to be able to receive e-mail notifications. You should also grant the wf_plsql_ui database role to your database users so that they can access the Oracle Workflow Web pages. See: Integrating an Oracle Workflow Directory Service with Oracle Database Users.
If you are using the version of Oracle Workflow embedded in Oracle Applications, directory service views for users and roles from the unified Oracle Applications environment are automatically implemented for you. See: Setting Up a Directory Service for Oracle Workflow Embedded in Oracle Applications.
You can also create your own directory service by defining custom views with the required columns. However, note that only the predefined directory services provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
Oracle Workflow provides local directory repository tables called WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES. These tables should always be included in any implementation of the WF_USERS, WF_ROLES, and WF_USER_ROLES views.
WF_LOCAL_ROLES stores role information, including a user flag to mark those roles that also represent individual users. This table contains columns similar to those required in the WF_USERS and WF_ROLES views.
WF_LOCAL_USER_ROLES stores information about the associations of users with roles. This table contains columns similar to those required in the WF_USER_ROLES view.
Oracle Workflow also provides tables to support extended directory service features.
WF_LOCAL_ROLES_TL stores translated display name and description values for multiple language support (MLS) in the WF_USERS and WF_ROLES views.
WF_ROLE_HIERARCHIES stores information about the hierarchical relationships between roles in Oracle Applications.
WF_USER_ROLE_ASSIGNMENTS stores information about the direct and inherited assignments of users to roles in Oracle Applications.
For the standalone version of Oracle Workflow, if you are integrating with Oracle Internet Directory, the Workflow local tables store user information that is retrieved from and synchronized with Oracle Internet Directory, as well as Workflow role information that is entered and stored locally. If you are integrating with Oracle Database users or a custom directory service repository, you can use these tables to store ad hoc users and roles not included in your existing tables. You can create such ad hoc users and roles in the Workflow local tables by calling the appropriate Workflow directory service PL/SQL APIs.
Note: If you implement Oracle Internet Directory integration, you must not create ad hoc users in the Workflow local tables, because you risk discrepancies in your user information and unpredictable results if you use any tool other than Oracle Internet Directory to maintain users after integrating with Oracle Internet Directory. You can still use ad hoc roles, however, since Workflow roles are not maintained through Oracle Internet Directory. See: Synchronizing Workflow Directory Services with Oracle Internet Directory.
For Oracle Workflow embedded in Oracle Applications, the Workflow local tables now store denormalized user and role information originating from various other Oracle Applications modules, so that the directory service views can access this information with good performance. You can also use these tables to store ad hoc users and roles by calling the appropriate Workflow directory service PL/SQL APIs.
In both standalone Oracle Workflow and Oracle Applications, you should periodically purge ad hoc users and roles from the Workflow local tables after they have expired in order to improve performance. See: Directory, Oracle Workflow API Reference.
See: Workflow Directory Service APIs, Oracle Workflow API Reference, Ad Hoc Users and Roles, Oracle Workflow Developer's Guide, and Oracle Workflow Security.
Setting Up a Directory Service for Standalone Oracle Workflow
If you are using the standalone version of Oracle Workflow, you can choose to implement either one of the two predefined directory services. Oracle Workflow provides scripts that you can run to implement these directory service environments, creating view definitions for the WF_USERS, WF_ROLES, and WF_USER_ROLES views. See: Workflow Directory Service Views.
You can integrate your Workflow directory service with Oracle Internet Directory as your directory repository. See: Integrating Oracle Workflow Directory Services with Oracle Internet Directory and Synchronizing Workflow Directory Services with Oracle Internet Directory.
You can also implement a directory service that is integrated with Oracle Database users. See: Integrating Oracle Workflow Directory Services with Oracle Database Users.
Note: Additionally, you can create your own directory service by defining custom views based on the database tables that make up your directory repository, provided that you define the required columns and also map to the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables for users and roles that are not stored in your repository. If you choose to do so, you can either create new view definitions, or you can edit and run a copy of one of the provided scripts. However, note that only the predefined directory service views provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
Integrating an Oracle Workflow Directory Service with Oracle Internet Directory
If you are using the standalone version of Oracle Workflow, you can integrate your Workflow directory service with Oracle Internet Directory as your directory repository. In this case, Oracle Workflow provides a directory service implementation that maps the directory service views only to the Workflow local tables, because only the users in the WF_LOCAL_ROLES table with their user flag set to Y will be synchronized with Oracle Internet Directory. (Only users are maintained through Oracle Internet Directory, not Workflow roles.) After implementing Oracle Internet Directory integration, you maintain your user information only through Oracle Internet Directory. See: Synchronizing Workflow Directory Services with Oracle Internet Directory.
You can also use this directory service implementation if your users and roles are not stored in any existing directory repository, and you want to enter all your user and role information directly in the Workflow local tables. In this case the WF_LOCAL_ROLES, WF_LOCAL_ROLES_TL, and WF_LOCAL_USER_ROLES tables become your primary directory repository tables.
Oracle Workflow provides a script named wfdircsv.sql which you can run to set up the views mapped only to the Workflow local tables. The wfdircsv.sql script is located in the ORACLE_HOME/wf/sql directory on your server. This script creates three views, WF_USERS, WF_ROLES, and WF_USER_ROLES. See: Workflow Directory Service Views.
The originating system in the WF_USERS view is called WF_LOCAL_USERS, and the originating system ID is 0.
The WF_ROLES view includes all users and roles defined in WF_LOCAL_ROLES, regardless of the user flag. The originating system is WF_LOCAL_ROLES and the originating system ID is 0.
The WF_USER_ROLES view consists of the names and originating system information of both users and roles in WF_USERS and WF_ROLES, associating users with the roles of which they are members.
Note: If you do not want to implement Oracle Internet Directory integration, but you choose to define custom views, you can use the wfdircsv.sql script to begin your custom definitions by creating a copy of this script and editing it to incorporate your own directory repository tables in addition to the Workflow local tables. However, note that only the predefined directory service views provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
If you implement Oracle Internet Directory integration, you must not customize the view definitions to incorporate any tables other than the Workflow local tables, because only the users in the WF_LOCAL_ROLES table with their user flag set to Y will be synchronized with Oracle Internet Directory.
Integrating an Oracle Workflow Directory Service with Oracle Database Users
If you are using the standalone version of Oracle Workflow, you can map your directory service to the native users and roles in the Oracle Database. In this case you base your views on the tables DBA_USERS, DBA_ROLES, and WF_LOCAL_ROLES.
Oracle Workflow provides a script named wfdirouv.sql which you can use to set up the views. The wfdirouv.sql script is located in the ORACLE_HOME/wf/sql directory. This script is automatically run by the Oracle Workflow Configuration Assistant when you install the standalone version of Oracle Workflow. The script creates the three directory service views, WF_USERS, WF_ROLES, and WF_USER_ROLES. See: Workflow Directory Service Views.
The WF_USERS view creates a workflow user for each DBA user and any users stored in WF_LOCAL_ROLES. For each DBA user, the originating system is called ORACLE, and the originating system ID is the USERNAME column in DBA_USERS. The default notification preference for each DBA user is MAILHTML.
The WF_ROLES view includes all users in the WF_USERS view, all roles defined in the WF_LOCAL_ROLES table, and all roles in DBA_ROLES, where role_name begins with WF. For each DBA role, the originating system is ORACLE and the originating system ID is the ROLE column in DBA_ROLES. The default notification preference for each DBA role is MAILHTML.
The WF_USER_ROLES view consists of the names and originating system information of both users and roles in WF_USERS and WF_ROLES, associating users with the roles of which they are members.
The wfdirouv.sql script sets each native Oracle user's e-mail address to the user's respective username. If you want users to be able to receive e-mail notifications, as a minimal setup step, you should edit the wfdirouv.sql script to either link your native Oracle users to an existing mail directory store through the WF_ROLES view definition, or, if the usernames and e-mail account names match, then simply add the domain for your organization, such as '@oracle.com', to the usernames in the WF_USERS view definition. Typically, the columns that you change are EMAIL_ADDRESS in WF_USERS and EMAIL_ADDRESS in WF_ROLES.
Additionally, you should grant each database user who is a Workflow user the wf_plsql_ui database role. This role provides users the privileges to access the Oracle Workflow Web pages. Use the GRANT SQL statement to grant the role to users. For example:
grant wf_plsql_ui to username;
See: GRANT, Oracle Database SQL Reference.
Setting Up a Directory Service for Oracle Workflow Embedded in Oracle Applications
In Oracle Applications, Oracle Workflow uses a directory service model in which denormalized information is maintained in the Workflow local tables for performance gain. The Workflow local tables store user and role information originating from various other Oracle Applications modules, as well as ad hoc users and roles, so that the WF_USERS, WF_ROLES, WF_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS_V views can access this information with good performance. You should maintain synchronization between the user and role information stored in application tables by the source modules and the information stored in the Workflow local tables.
Directory Service Views for Oracle Applications
The predefined WF_USERS, WF_ROLES, WF_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS_V directory service views for Oracle Workflow embedded in Oracle Applications are now based solely on the Workflow local tables where the denormalized information is stored. These view definitions are automatically created for you during installation. See: Workflow Directory Service Views.
WF_USERS is based on WF_LOCAL_ROLES where the user flag is set to Y and on WF_LOCAL_ROLES_TL.
WF_ROLES is based on WF_LOCAL_ROLES and on WF_LOCAL_ROLES_TL.
WF_USER_ROLES is based on WF_LOCAL_USER_ROLES.
WF_USER_ROLE_ASSIGNMENTS_V is based on WF_USER_ROLE_ASSIGNMENTS.
Note: You can customize your directory service by creating your own custom view definitions, provided that you define the required columns and map to the Workflow local tables. However, note that only the predefined directory service views provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
In Oracle Applications, the only roles in WF_LOCAL_ROLES that are marked as individual users with the user flag set to Y are roles that represent Oracle Applications users, originating from the FND_USER table, roles that represent Oracle Trading Community Architecture (TCA) person parties, roles that represent TCA contacts (relationship parties), or roles that represent ad hoc users. Records originating from other application tables are treated solely as roles, with the user flag set to N. The WF_LOCAL_USER_ROLES table is used to associate Oracle Applications users, TCA person parties, and TCA contacts with roles defined by other applications.
Note: An Oracle Applications user may be associated with an Oracle Human Resources person. In this case, some person information is combined into the user's record in WF_LOCAL_ROLES. In such a combined record, the originating system is changed from FND_USR to PER, and the display name is taken from Oracle Human Resources, while the internal name is the Oracle Applications user name from FND_USER, and the user flag is still set to Y.
Each Oracle Human Resources person is also represented in WF_LOCAL_ROLES as a role with the originating system PER_ROLE and the user flag set to N. This record remains unaffected whether the person is linked to an Oracle Applications user or not.
The following table summarizes the different ways in which Oracle Applications users and Oracle Human Resources people are stored in WF_LOCAL_ROLES.
| Type of Role | Orig_System | User_Flag |
|---|---|---|
| Oracle Applications user, not linked to an Oracle Human Resources person | FND_USR | Y |
| Oracle Applications user linked to an Oracle Human Resources person | PER | Y |
| Oracle Human Resources person | PER_ROLE | N |
To link an Oracle Applications user to an Oracle Human Resources person, navigate to the Users window in Oracle Applications and select the appropriate person name in the Person field for that user. See: Users Window, Oracle Applications System Administrator's Guide.
You should only link an Oracle Human Resources person to one Oracle Applications user. If a person is linked to more than one user, notifications for that person may become inaccessible, and workflow processes may be halted while waiting for those notifications to be completed. Additionally, assigning a person to multiple users may cause errors in other Oracle Applications modules as well. For this reason, you must not link an Oracle Human Resources person to more than one Oracle Applications user.
The WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables are partitioned by the originating system within Oracle Applications that was the source of the denormalized information. This partitioning provides faster data access and also allows each originating system to be synchronized with the Workflow local tables individually. Each table also includes a separate partition that contains ad hoc users and roles as well as data from any system that does not have its own partition.
The partition information for each originating system is stored in the WF_DIRECTORY_PARTITIONS table. There are partitions for the following systems:
WF_LOCAL_ROLES - Ad hoc users and roles, as well as data from any originating system that does not have its own partition
FND_USR - FND users, which may or may not be linked to Oracle Human Resources people
FND_RESP - FND responsibilities
PER_ROLE - HR people
POS - HR positions
AMV_APPR - MarketView approvals
AMV_CHN - MarketView channels
ENG_LIST - Engineering approval list
HZ_GROUP - TCA groups
HZ_PARTY - TCA person parties and contacts
GBX - Federal HR group boxes
HTB_SEC - This partition does not participate in bulk synchronization.
PQH_ROLES - Position Control roles
UMX - User Management roles. This partition does not participate in bulk synchronization.
Note: Normally each partition contains only records that originate from the corresponding system. However, the FND_USR partition can contain both roles with an originating system value of FND_USR, which are unlinked Oracle Applications users, and roles with an originating system value of PER, which are Oracle Applications users that are linked to Oracle Human Resources people.
See: Ad Hoc Users and Roles, Oracle Workflow Developer's Guide.
You can run a diagnostic test through Oracle Diagnostics to check that there are no duplicate roles in the WF_LOCAL_ROLES table. See: Oracle Workflow Diagnostic Tests.
Synchronizing Workflow User and Role Information
For each Oracle Applications module that is a source of Oracle Workflow user and role information, the information stored in the source application tables must be synchronized with the denormalized information in the Workflow local tables. The Workflow local synchronization APIs are used to perform this synchronization.
Incremental Synchronization
Oracle Workflow automatically performs an initial synchronization of the user and role information in all the related originating systems during installation. Subsequently, you must continue synchronizing the user and role information from the source modules with the Workflow local tables. For each Oracle Applications module that stores user and role information in its application tables, a patch will be made available to automatically synchronize that information with the information in the Workflow local tables on an incremental basis, using the Workflow local synchronization APIs. For details on the patches that are currently available, please refer to OracleMetaLink note 171703.1, Implementing Oracle Workflow Directory Service Synchronization.
Bulk Synchronization
Until these incremental synchronization patches are released, you can run a concurrent program named Synchronize WF LOCAL Tables to perform synchronization in bulk, periodically refreshing the information in the Workflow local tables for the affected modules. This concurrent program is provided as an interim method to synchronize the Workflow local tables with the user and role information stored in the product application tables until each affected product performs the synchronization automatically.
Oracle Workflow provides a request set named Synchronize Workflow LOCAL Tables that contains ten instances of the Synchronize WF Local Tables program, one for each originating system. You can use this request set to submit requests for all the originating systems at once. Note that because this program is incompatible with itself, each request is defined as a separate stage and the stages will run sequentially. By default, this request set is scheduled to run once a day to provide a minimal level of synchronization. You can modify the schedule for the request set to perform synchronization more frequently.
You only need to run the bulk synchronization program for products for which you do not have an incremental synchronization patch installed. After applying the patch for a product, you no longer need to run the program for originating systems owned by that product.
After applying the patch for a product, remove the program instance for each of that product's originating systems from the Synchronize Workflow LOCAL Tables request set. See: Defining Request Sets, Oracle Applications System Administrator's Guide.
Also, do not submit any further single requests for the Synchronize WF LOCAL Tables program for that product's originating systems.
Note: You can still use the bulk synchronization program to synchronize the product's data for troubleshooting and diagnostic purposes, if necessary.
Note: Products that use role hierarchies do not participate in bulk synchronization. These products must perform incremental synchronization.
To submit the Synchronize Workflow LOCAL Tables request set
Navigate to the Submit Requests form in Oracle Applications (System Administrator: Requests > Run). See: Running Reports and Programs, Oracle Applications User's Guide.
Choose to run a request set and select Synchronize Workflow LOCAL Tables as the request set to run.
Enter the values you want for the following parameters.
Parallel Processes - Enter the number of parallel processes to run. The default value for this parameter is 1. However, if your hardware resources allow, you can optionally set this parameter to a higher value in order to parallelize the queries during execution of the program.
Logging - Select the logging mode you want. This mode determines whether redo log data is generated for database operations performed by the bulk synchronization process. The default value for this parameter is LOGGING, which generates redo log data normally. You can optionally set the logging mode to NOLOGGING to suppress redo log data, obtaining a performance gain. Without this redo log data, no media recovery is possible for the Workflow directory tables and indexes, requiring that you re-run the bulk synchronization process in the event of a media recovery scenario. One additional scenario that would require the process to be re-run is when you open a standby database, whose maintenance also depends on redo log data.
Select the print and run options you want to define the schedule for this request set, and choose Submit to submit the requests.
To submit a single request for the Synchronize WF LOCAL Tables concurrent program
Navigate to the Submit Requests form in Oracle Applications (System Administrator: Requests > Run). See: Running Reports and Programs, Oracle Applications User's Guide.
Choose to run a single request and select the Synchronize WF LOCAL Tables concurrent program as the request to run.
In the Parameters window, enter the values you want for the following parameters:
Orig System - Select the name of the originating system whose user and role information you want to synchronize with the WF_LOCAL tables. These system names are stored in the FND_WF_ORIG_SYSTEMS lookup type. You can select the following systems:
AMV_APPR - MarketView Approvals
AMV_CHN - MarketView Channels
ENG_LIST - Engineering Approval List
FND_RESP - FND Responsibilities
FND_USR - FND Users
GBX - Federal HR Group Boxes
HZ_GROUP - TCA Groups
HZ_PARTY - TCA Parties
PER_ROLE - HR People
POS - HR Positions
PQH_ROLES - Position Control Roles
Parallel Processes - Enter the number of parallel processes to run. The default value for this parameter is 1. However, if your hardware resources allow, you can optionally set this parameter to a higher value in order to parallelize the queries during execution of the program.
Logging - Select the logging mode you want. This mode determines whether redo log data is generated for database operations performed by the bulk synchronization process. The default value for this parameter is LOGGING, which generates redo log data normally. You can optionally set the logging mode to NOLOGGING to suppress redo log data, obtaining a performance gain. Without this redo log data, no media recovery is possible for the Workflow directory tables and indexes, requiring that you re-run the bulk synchronization process in the event of a media recovery scenario. One additional scenario that would require the process to be re-run is when you open a standby database, whose maintenance also depends on redo log data.
Select the print and run options you want to define the schedule for this request, and choose Submit to submit the request. You can submit multiple requests for this program to perform synchronization for different originating systems at different frequencies. However, note that because this program is incompatible with itself, only one request for the program can run at a time.
Note: Additionally, you must not run bulk synchronization using APIs or scripts from SQL*Plus while you are running the Synchronize WF LOCAL Tables concurrent program or the Synchronize Workflow LOCAL Tables request set, as the two processes will interfere with each other.
How Bulk Synchronization Is Performed
The bulk synchronization program retrieves user and role information from an originating system through views that present the information that was formerly included in the previous implementation of the Workflow directory service views. Each originating system provides two new views, one that contains the same columns as WF_ROLES and one that contains the same columns as WF_USER_ROLES.
Note: Originating systems that use role hierarchies do not participate in bulk synchronization. These originating systems must perform incremental synchronization.
For backward compatibility, the originating systems' synchronization views must present exactly the same user and role information that was included for that system in the previous implementation of the Workflow directory service views. The information must be presented in the format required by Oracle Workflow, with no duplicates. For example, the internal name for a user or role must be sourced from a column that is no longer than 320 characters. It is recommended that internal names be all uppercase. If the source table in the originating system does not have a column that meets these criteria, the internal name should be defined to be <orig_system>:<orig_system_id> instead, so that Oracle Workflow can reference the original base table where users or roles are stored and a unique user or role in that table.
Note: If internal names in all uppercase are used, the names should be initially entered in the database in all uppercase. Forcing the names to uppercase in the view definition results in poor performance when accessing these views.
Note: You can customize these originating system synchronization view definitions to specify the data you want to include in bulk synchronization, provided that your customized views meet the requirements listed above. However, note that the originating systems that have implemented incremental synchronization will also be propagating user and role information to the Workflow local tables automatically, so the synchronization views used for bulk synchronization are not the only source of data for Oracle Workflow. Also note that only the predefined synchronization views provided by Oracle Applications are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
When you run the bulk synchronization program for a particular originating system, the program extracts the role and user/role association information from that system's synchronization views and loads the information into staging tables. The program then performs a partition exchange between the staging tables and the WF_LOCAL_ROLES, WF_LOCAL_ROLES_TL, WF_LOCAL_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS tables to update the partitions for that system in the Workflow local tables. Finally, the staging tables are truncated.
Note: The bulk synchronization program does not store or modify any information in the WF_LOCAL_ROLES partitions within the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables that contain ad hoc users and roles.
Role Hierarchies
In Oracle Applications, roles can be related to each other in a hierarchy so that users assigned to one role automatically inherit membership in its superior roles as well. Role hierarchies enable role-based access control in Oracle Applications.
For example, a company could define a role hierarchy with three roles: sales manager, sales representative, and employee. A user with the sales manager role automatically inherits the sales representative role, and a user with the sales representative role automatically inherits the employee role. If user A is assigned directly to the sales representative role, then user A will also have an inherited assignment to the employee role. If user B is assigned directly to the sales manager role, user B will also have inherited assignments to both the sales representative role and the employee role.
Oracle Workflow stores hierarchical relationships between roles in the WF_ROLE_HIERARCHIES table. Oracle Workflow also stores denormalized information about direct and inherited assignments of users to roles in the WF_USER_ROLE_ASSIGNMENTS table for performance gain. If a user is associated with a certain role through more than one direct or inherited assignment, the WF_USER_ROLE_ASSIGNMENTS table tracks which assignments are currently valid and expires the user/role association only when all assignments have ended.
Note: Originating systems that use role hierarchies do not participate in bulk synchronization. These originating systems must perform incremental synchronization.
Workflow Directory Service Views
Oracle Workflow relies on views named WF_USERS, WF_ROLES, WF_USER_ROLES, and, in Oracle Applications only, WF_USER_ROLE_ASSIGNMENTS_V, to reference user and role information. Other views provide further access to Workflow directory service data, including WF_ALL_ROLES_VL, WF_ALL_USER_ROLES, and, in Oracle Applications only, WF_ALL_USER_ROLE_ASSIGNMENTS.
If you are using the standalone version of Oracle Workflow, you can choose to implement definitions for these views from one of two predefined directory services provided by Oracle Workflow, which let you either integrate with Oracle Internet Directory as your directory repository or use Oracle Database users and roles for your directory service. If you are using the version of Oracle Workflow embedded in Oracle Applications, directory service views for the unified Oracle Applications environment are automatically defined for you during installation.
Note: An expiration date can be assigned to each role in WF_LOCAL_ROLES, each user/role association in WF_LOCAL_USER_ROLES, and each user/role assignment in WF_ROLE_HIERARCHIES. After that date, an expired role is no longer included in the predefined WF_USERS and WF_ROLES view, an expired user/role association is no longer included in the predefined WF_USER_ROLES view, and an expired user/role assignment is no longer included in the WF_USER_ROLE_ASSIGNMENTS_V view.
However, note that although the expired rows no longer appear in these views, they still exist in the Workflow local tables. You should periodically purge expired ad hoc users and roles using the WF_PURGE.Directory() API in order to improve performance. See: Directory, Oracle Workflow API Reference.
You can also create your own directory service by defining custom views with the required columns. However, note that only the predefined directory services provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.
If you create your own custom view definitions:
Each individual user identified by WF_USERS must also appear in the WF_ROLES view as a role.
You should set the user flag in the underlying tables to Y for all the roles that also represent individual users, and set the user flag to N for all other roles.
You should include the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables in the view definitions. You can optionally also include the WF_LOCAL_ROLES_TL table for multiple language support.
You should avoid selecting from DUAL to incorporate additional users and roles into the directory service views as this allows you to violate the unique constraint on certain columns of the views and reduces performance with unnecessary joins between the 'select from DUAL' statements.
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.
You should run the script wfdirchk.sql to validate your directory service data model. This script is located on your server in the ORACLE_HOME/wf/admin/sql directory for the standalone version of Oracle Workflow or in the $FND_TOP/sql directory for the version of Oracle Workflow embedded in Oracle Applications. See: Wfdirchk.sql.
Note: Avoid making a join to a view that contains a union, as this results in poor database performance. The Oracle Database is unable to preserve the indexes in that view when you make such a join. The workflow directory service 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. See: Workflow Directory Service APIs, Oracle Workflow API Reference.
WF_USERS
The WF_USERS view references information about the individuals in your organization who may utilize Oracle Workflow functionality or receive workflow notifications.
Note: In WF_LOCAL_ROLES, a role that is an individual user has the user flag set to Y.
Note: For Oracle Applications, this view now includes only Oracle Applications users originating from the FND_USER table, TCA person parties, TCA contacts, and ad hoc users, although an Oracle Applications user record may also include information from Oracle Human Resources if the user is linked to an Oracle Human Resources person.
The WF_USERS view must contain the following required 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.
Attention: If you define custom views, the Name column must be sourced from a column that is no longer than 320 characters, and it is recommended that the internal name be 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 <orig_system>:<orig_system_id> 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 could represent a user whose employee ID is 009 and whose record is stored in a 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 - The method by which this user prefers to receive notifications. A value of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH allows users to receive and respond to notifications by plain text e-mail, HTML-formatted e-mail with attachments, HTML-formatted e-mail without attachments, or by plain text e-mail with HTML attachments, respectively. A value of QUERY allows users to query notifications from the Worklist Web page. Finally, a value of SUMMARY or, for Oracle Applications only, SUMHTML, allows users to receive periodic e-mail summaries of their open notifications. However, to respond to the individual notifications, they must view the notification in the Worklist Web pages. See: Overview of Notification Handling, Oracle Workflow User's Guide and Notification Preferences.
Note: A notification preference of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH also allows users to view their notifications in the Worklist Web pages.
Note: In Oracle Applications, if no notification preference is provided by the originating system, the notification preference is set to MAILHTML by default.
Note: If you define custom views, you can map the Notification_Preference column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default notification preference for all users in your enterprise using the Global Preferences page in standalone Oracle Workflow or the Workflow Configuration page in Oracle Applications, and let individual users override that default value by changing their notification preference in the User Preferences page in standalone Oracle Workflow or the Preferences page in Oracle Applications. See: Setting Global User Preferences, Setting User Preferences, Oracle Workflow User's Guide, and get_pref, Oracle Workflow Developer's Guide.
NVL(wf_pref.get_pref(USR.USER_NAME,'MAILTYPE'), 'MAILHTML')
Language - The value of the database NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of the user's notification session. The Language column is required and cannot be left null. Refer to your Oracle Database user's guide or installation manual for the list of supported language conventions.
Note: In Oracle Applications, for roles that are Oracle Applications users marked with an originating system of FND_USR or PER, Oracle Workflow uses the GetRoleInfo() procedure to find the language for a user, rather than querying this column in the directory service views. GetRoleInfo() by default retrieves the language value from the ICX: Language profile option for that Oracle Applications user.
However, if the WF_PREFERENCE resource token is defined and set to FND, then the GetRoleInfo() procedure obtains the language value from the Oracle Workflow preferences table instead.
The WF_PREFERENCE resource token is not used in the standalone version of Oracle Workflow.
Note: If you define custom views, and, if you are using Oracle Applications, the WF_PREFERENCE resource token is set to FND, then you can map the Language column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default language for all users in your enterprise and let individual users override that default value by changing their language preference. See: Setting Global User Preferences, Setting User Preferences, Oracle Workflow User's Guide, and get_pref, Oracle Workflow Developer's Guide.
NVL(wf_pref.get_pref(USR.USER_NAME,'LANGUAGE'), <default_language>)
Attention: Make sure that the e-mail templates used by notification mailers to send notifications have been translated by Oracle to the language you wish to set. The standard e-mail templates are delivered in a file called wfmail.wft under the subdirectory $ORACLE_HOME/wf/res/<lang> for the standalone version of Oracle Workflow or $FND_TOP/import/<lang> for the version of Oracle Workflow embedded in Oracle Applications. You can check the appropriate language subdirectory to verify if the templates have been translated to the language you wish to set. See: Modifying Your Message Templates.
Territory - The value of the database NLS_TERRITORY initialization parameter that specifies the default territory-dependent formatting used in the user's notification session. The Territory column is required and cannot be left null. Refer to your Oracle Database user's guide or installation manual for the list of supported territory conventions.
Note: In Oracle Applications, for roles that are Oracle Applications users marked with an originating system of FND_USR or PER, Oracle Workflow uses the GetRoleInfo() procedure to find the territory for a user, rather than querying this column in the directory service views. GetRoleInfo() by default retrieves the territory value from the ICX: Territory profile option for that Oracle Applications user.
However, if the WF_PREFERENCE resource token is defined and set to FND, then the GetRoleInfo() procedure obtains the territory value from the Oracle Workflow preferences table instead.
The WF_PREFERENCE resource token is not used in the standalone version of Oracle Workflow.
Note: If you define custom views, and, if you are using Oracle Applications, the WF_PREFERENCE resource token is set to FND, then you can map the Territory column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default territory for all users in your enterprise and let individual users override that default value by changing their territory preference. See: Setting Global User Preferences, Setting User Preferences, Oracle Workflow User's Guide, and get_pref, Oracle Workflow Developer's Guide.
NVL(wf_pref.get_pref(USR.USER_NAME,'TERRITORY'), <default_territory>)
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 originating system, which is the directory repository that this view is ultimately 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.
Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user. For example, a supplier could be marked as the parent of a supplier site.
Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.
Note: If no parent information is provided, the Parent_Orig_System and Parent_Orig_System_ID default to the user's own Orig_System and Orig_System_ID, respectively.
Start_Date - The date at which the user becomes valid in the directory service.
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.
Expiration_Date - The date at which the user is no longer valid in the directory service. After this date, the user will no longer appear in the seeded WF_USERS view.
Owner_Tag - A code to identify the program or application that owns the information for this user.
WF_ROLES
The WF_ROLES view references information about all the roles in your organization who may utilize Oracle Workflow functionality or receive workflow notifications. This view must contain the following required columns pertaining to the roles in your repository. Those columns that are preceded by an asterisk (*) are similar to the corresponding columns described for the WF_USERS view.
Attention: Each user identified by WF_USERS must also appear in the WF_ROLES view as a role. This is a requirement for Oracle Workflow.
Note: If a user is a member of a role and the user information such as language and notification preference is different from the role information, the Expand Roles option for a notification addressed to the role determines whether the user information or the role information takes precedence. If the Expand Roles option is not checked and the Notification System delivers the notification to the role, the role information will override the user information. If Expand Roles is checked, however, then each user in the role will receive a separate copy of the notification, and the user information will override the role information.
If a user has a notification preference of SUMMARY or SUMHTML, and the user is also a member of a multi-user role with a different notification preference such as MAILHTML, the Notification System will use the Expand Roles setting to determine whether to deliver the notification according to the role or user notification preference. However, even if Expand Roles is not checked and the notification preference of the role takes precedence, the notification will still appear in the user's summary message because the notification is part of the user's worklist.
Name - The internal name of the role as referenced by the Workflow Engine and Notification System.
Attention: If you define custom views, the Name column must be sourced from a column that is no longer than 320 characters, and it is recommended that the internal name be 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 <orig_system>:<orig_system_id> 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" could represent a position whose ID is 009 and whose record is stored in the personnel table called PER_POSITION.
*Display_Name
*Description
*Notification_Preference
*Language
*Territory
Email_Address - If the e-mail address is null for a given role, notification mailers send an individual e-mail to each user within the role.
*Fax
*Orig_System
*Orig_System_ID
*Parent_Orig_System
*Parent_Orig_System_ID
*Start_Date
*Status
Expiration_Date - The date at which the role is no longer valid in the directory service. After this date, the role will no longer appear in the seeded WF_ROLES view.
*Owner_Tag
WF_USER_ROLES
The WF_USER_ROLES view is an intersection of the users and roles in WF_USERS and WF_ROLES, showing which users are members of which roles.
Note: A role can contain only individual users as its members. It cannot contain another role. However, in Oracle Applications roles can be related to each other in a hierarchy so that users assigned to one role automatically inherit membership in its superior roles as well.
The WF_USER_ROLES view must contain the following required columns:
User_Name - The internal name of the user as listed in the view WF_USERS.
Role_Name - The internal name of the role as listed in the view WF_ROLES.
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_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.
Start_Date - The date at which the association of this user with this role becomes valid in the directory service.
Expiration_Date - The date at which the association of this user with this role is no longer valid in the directory service. After this date, the user and role association will no longer appear in the seeded WF_USER_ROLES view.
Assignment_Type - A code indicating how the user was assigned to membership in this role. This column is used only in Oracle Applications.
D - The user was directly assigned to this role.
I - The user inherited this role through membership in another role.
B - The user has both direct and inherited assignments to this role.
Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user/role association.
Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.
WF_USER_ROLE_ASSIGNMENTS_V
The WF_USER_ROLE_ASSIGNMENTS_V view is an intersection of the users and roles in WF_USERS and WF_ROLES, that tracks how assignments of users to roles are made directly or inherited through role hierarchy relationships. The view shows only currently active assignments. This view is used only in Oracle Applications.
The WF_USER_ROLE_ASSIGNMENTS_V view contains the following columns:
User_Name - The internal name of the user as listed in the view WF_USERS.
Role_Name - The internal name of the role as listed in the view WF_ROLES.
Assigning_Role - The role from which the user is inheriting assignment to this role.
Start_Date - The date at which the assignment of this user to this role becomes valid in the directory service.
End_Date - The date at which the assignment of this user to this role is no longer valid in the directory service.
Assignment_Type - The way in which the user was assigned to membership in this role, either DIRECT or INHERITED.
WF_ALL_ROLES_VL
The WF_ALL_ROLES_VL view contains role information similar to the WF_ROLES view. However, WF_ALL_ROLES_VL includes all roles, whether not yet valid, currently valid, or expired.
The WF_ALL_ROLES_VL view contains the following columns:
Name - The internal name of the role.
Display_Name - The display name of the role.
Description - An optional description of the role.
Notification_Preference - The method by which this role prefers to receive notifications.
Language - The value of the database NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of the role's notification session.
Territory - The value of the database NLS_TERRITORY initialization parameter that specifies the default territory-dependent formatting used in the role's notification session.
Email_Address - A valid electronic mail address for this role.
Fax - A fax number for the role.
Orig_System - A code that you assign to originating system on which this view is ultimately based.
Orig_System_ID - The primary key that identifies the role in the originating system.
Start_Date - The date at which the role becomes valid in the directory service.
Status - The availability of the role 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.
Expiration_Date - The date at which the role is no longer valid in the directory service.
Owner_Tag - A code to identify the program or application that owns the information for this role.
Created_By - Standard Who column.
Creation_Date - Standard Who column.
Last_Updated_By - Standard Who column.
Last_Update_Date - Standard Who column.
Last_Update_Login - Standard Who column.
WF_ALL_USER_ROLES
The WF_ALL_USER_ROLES view contains user/role association information similar to the WF_USER_ROLES view. However, WF_ALL_USER_ROLES includes all user/role associations, whether not yet valid, currently valid, or expired.
The WF_ALL_USER_ROLES view contains the following columns:
User_Name - The internal name of the user.
Role_Name - The internal name of the role .
User_Orig_System - A code that you assign to the user directory repository.
User_Orig_System_ID - The primary key that identifies the user in the user originating system.
Role_Orig_System - A code that you assign to the role directory repository.
Role_Orig_System_ID - The primary key that identifies the role in the role originating system.
Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user/role association.
Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.
Assignment_Type - A code indicating how the user was assigned to membership in this role. This column is used only in Oracle Applications.
D - The user was directly assigned to this role.
I - The user inherited this role through membership in another role.
B - The user has both direct and inherited assignments to this role.
Start_Date - The date at which the association of this user with this role becomes valid in the directory service.
Expiration_Date - The date at which the association of this user with this role is no longer valid in the directory service.
Owner_Tag - A code to identify the program or application that owns the information for the association of this user with this role.
Created_By - Standard Who column.
Creation_Date - Standard Who column.
Last_Updated_By - Standard Who column.
Last_Update_Date - Standard Who column.
Last_Update_Login - Standard Who column.
WF_ALL_USER_ROLE_ASSIGNMENTS
The WF_ALL_USER_ROLE_ASSIGNMENTS view contains information about how assignments of users to roles are made directly or inherited through role hierarchy relationships, similar to the WF_USER_ROLE_ASSIGNMENTS_V view. However, WF_ALL_USER_ROLE_ASSIGNMENTS includes all user/role assignments, whether not yet valid, currently valid, or expired. This view is used only in Oracle Applications.
The WF_ALL_USER_ROLE_ASSIGNMENTS view contains the following columns:
User_Name - The internal name of the user.
Role_Name - The internal name of the role .
Assigning_Role - The role from which the user is inheriting assignment to this role.
Start_Date - The date at which the assignment of this user to this role becomes valid in the directory service.
End_Date - The date at which the assignment of this user to this role is no longer valid in the directory service.
Assignment_Type - The way in which the user was assigned to membership in this role, either DIRECT or INHERITED.
Created_By - Standard Who column.
Creation_Date - Standard Who column.
Last_Updated_By - Standard Who column.
Last_Update_Date - Standard Who column.
Last_Update_Login - Standard Who column.
If you are using the standalone version of Oracle Workflow, you can synchronize the user information in your Workflow directory service with Oracle Internet Directory using Lightweight Directory Access Protocol (LDAP). This integration is recommended because it enables you to manage and publish user information in a central location which various systems can reference.
Synchronization with Oracle Internet Directory enables Oracle Workflow to do the following:
Assign ownership of work items and send notifications to users defined in Oracle Internet Directory.
Synchronize with other external user directories that are synchronized with Oracle Internet Directory.
Participate in single sign-on through LDAP external authentication with Oracle Application Server Single Sign-On Server, if you have installed Oracle Application Server. With single sign-on, a user who is logged into any participating Oracle Application Server component is automatically authenticated when accessing any other participating component and does not need to log in again.
Attention: To implement single sign-on integration, you must install Oracle Workflow shipped with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.
For more information about leveraging the Oracle Identity Management infrastructure, see: Oracle Workflow Security.
Oracle Internet Directory
Oracle Internet Directory is a general purpose directory service that enables fast retrieval and centralized management of information about dispersed users and network resources. It combines Lightweight Directory Access Protocol (LDAP) Version 3 with the high performance, scalability, robustness, and availability of the Oracle Database.
LDAP is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to communicate. LDAP was conceived as an internet-ready, lightweight implementation of the International Standardization Organization (ISO) X.500 standard for directory services. It requires a minimal amount of networking software on the client side, which makes it particularly attractive for internet-based, thin client applications.
The advantages of Oracle Internet Directory include:
Scalability - Oracle Internet Directory exploits the strengths of the Oracle Database, enabling support for terabytes of directory information. In addition, such technologies as multithreaded LDAP servers and database connection pooling allow it to support thousands of concurrent clients with subsecond search response times.
Oracle Internet Directory also provides data management tools, such as Oracle Directory Manager and a variety of command-line tools, for manipulating large volumes of LDAP data.
High availability - Oracle Internet Directory is designed to meet the needs of a variety of important applications. For example, it supports full, multimaster replication between directory servers: If one server in a replication community becomes unavailable, then a user can access the data from another server. Information about changes made to directory data on a server is stored in special tables on the Oracle Database. These are replicated throughout the directory environment by Oracle Replication, a robust replication mechanism.
Oracle Internet Directory also takes advantage of all the availability features of the Oracle Database. Because directory information is stored securely in the Oracle Database, it is protected by the backup capabilities of the database. Additionally, the Oracle Database, running with large datastores and heavy loads, can recover from system failures quickly.
Security - Oracle Internet Directory offers comprehensive and flexible access control. An administrator can grant or restrict access to a specific directory object or to an entire directory subtree. Moreover, Oracle Internet Directory implements three levels of user authentication: anonymous, password-based, and certificate-based using Secure Socket Layer (SSL) Version 3 for authenticated access and data privacy.
Synchronization with other directories - Oracle Internet Directory includes the Oracle Directory Integration platform that enables you to synchronize with other enterprise repositories, including third-party LDAP directories.
Oracle Application Server Single Sign-On uses Oracle Internet Directory to store user entries. It maps users for any partner application to user entries in Oracle Internet Directory entries, and authenticates them by using LDAP mechanisms.
See: Oracle Internet Directory Administrator's Guide.
Oracle Application Server Single Sign-On
Oracle Application Server Single Sign-On is a component of Oracle Application Server that provides a framework for secure single sign-on, allowing users to log in to multiple Web-based applications by entering a user name and password only once.
Attention: To implement single sign-on integration for Oracle Workflow, you must install Oracle Workflow shipped with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.
Oracle Application Server Single Sign-On provides the following benefits:
Ease of administration and reduced administrative costs, because user names and passwords can be stored and maintained outside of any particular application and shared across the enterprise
Convenient login experience, because users do not need to maintain a separate username and password for each application they access
Increased security, because when the password is only required once, users are less likely to use simple, easy-to-remember passwords or write them down
The core of the Oracle Application Server Single Sign-On technology is the Login Server. The Login Server authenticates users and passes their identities to the partner applications that are integrated with it.
Partner applications support a single sign-on mechanism that enables them to accept a user's username and password as validated by the Login Server. A partner application delegates its authentication to the Login Server. If a partner application is registered with the Login Server, users can log into it using the single sign-on mechanism.
With mod_osso, an Oracle module that enables single sign-on, Oracle HTTP Server becomes a partner application of the Login Server. Oracle Workflow uses Oracle HTTP Server as its Web server. If you implement Oracle Internet Directory/Single Sign-On integration, Oracle Workflow participates in single sign-on by using mod_osso to authenticate access to its secured Web pages.
When a user first tries to access a secured Workflow Web page, the Workflow security package WFA_SEC checks the CGI environment variable REMOTE_USER for user information. If the user is not already logged in to Oracle Workflow or another Oracle Application Server Single Sign-On participating application, the user will be prompted to log in before the page appears.
Note: The WFA_SEC package is loaded as a post-install configuration step if you choose to implement Oracle Internet Directory/Single Sign-On integration. For more information, see your installation documentation.
To set the variable REMOTE_USER, Oracle HTTP Server internally calls to mod_osso. Acting as an Oracle Application Server Single Sign-On partner application, mod_osso transparently redirects the user to the Login Server to obtain authentication credentials, if no application cookie is present.
The Login Server performs the following steps:
Prompts the user for the user name and password, if no login cookie is present.
Authenticates the user by means of the user name and password, using external repository authentication that relies on an LDAP-compliant directory, specifically Oracle Internet Directory. The Login Server binds to Oracle Internet Directory and then looks up the user credentials stored in the directory.
Stores an encrypted login cookie on the authenticated client.
Transparently redirects the user to the partner application, mod_osso, by using a URL with an encrypted parameter containing the user's identity.
Oracle HTTP Server with mod_osso then performs the following steps:
Decrypts the parameter.
Identifies the user.
Establishes its own session management (for example, determining what, if any, access privileges to grant to the user).
Sets a partner application cookie so that subsequent user access does not require a redirect to the Login Server.
Presents the requested application page to the user.
If, during the same session, the user again seeks access to the same or to a different partner application, the Login Server does not prompt the user for a username and password. Instead, the Login Server obtains the information from the login cookie that is already on the client browser. The login cookie provides the Login Server with the user's identity and indicates that authentication has already been performed. If there is no login cookie, the Login Server presents the user with a login page.
To guard against eavesdropping, the Login Server can send the login cookie to the client browser over an encrypted SSL channel.
The login cookie expires with the session, either at the end of a time interval specified by the administrator, or when the user exits the browser. The login cookie is never written to disk.
Note: To log out of a partner application and log in as another user, the user must also log out of the Login Server session. Otherwise, the authentication request returns the partner application to the logged in state of the previous user.
See: Oracle Application Server Single Sign-On Administrator's Guide and Oracle Identity Management Application Developer's Guide.
Oracle Internet Directory Synchronization
Oracle Workflow provides APIs to synchronize the user information in your Workflow directory service with Oracle Internet Directory. These APIs are defined in a PL/SQL package called WF_LDAP. See: Workflow LDAP APIs, Oracle Workflow API Reference.
Note: Oracle Internet Directory integration includes only individual users, not user groups. Workflow roles are not maintained through Oracle Internet Directory.
To Synchronize Workflow Directory Services with Oracle Internet Directory
During installation, use the Workflow Configuration Assistant to choose to integrate with Oracle Internet Directory. You enter LDAP preferences in the Workflow Configuration Assistant, which are then stored as global workflow preferences. After installation, you can use the Global Preferences page to verify that the following preferences are set to the appropriate information for your Oracle Internet Directory installation, and optionally modify these settings. See: Setting Global User Preferences.
LDAP Host
LDAP Port
LDAP User Name
LDAP Password
LDAP Changelog Base Directory
LDAP User Base Directory
Note: If you choose to integrate with Oracle Internet Directory during installation, Workflow directory service views that support this integration are automatically implemented for you. See: Integrating Oracle Workflow Directory Services with Oracle Internet Directory.
Ensure that the PL/SQL package named DBMS_LDAP is loaded in your database. This package contains the functions and procedures which can be used to access data from LDAP servers and is required for LDAP synchronization.
For standalone Oracle Workflow, if you choose to integrate with Oracle Internet Directory by entering LDAP preferences in the Workflow Configuration Assistant, this package should be loaded as a pre-installation step. For more information, see the installation documentation for the software with which you installed Oracle Workflow.
For single sign-on integration, ensure that the Database Access Descriptor for Oracle Workflow is protected in the mod_osso configuration file. For standalone Oracle Workflow with Oracle Application Server, if you choose to integrate with Oracle Internet Directory by entering LDAP preferences in the Workflow Configuration Assistant, mod_osso configuration is automatically performed for you during installation. For more information, see the installation documentation for the software with which you installed Oracle Workflow.
Attention: To implement single sign-on integration, you must install Oracle Workflow shipped with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.
If you choose to integrate with Oracle Internet Directory by entering LDAP preferences in the Workflow Configuration Assistant, the Workflow Configuration Assistant performs an initial synchronization for you by running the WF_LDAP.Synch_all( ) API. This function retrieves all the existing user information from Oracle Internet Directory, based on the LDAP directory information specified in the global workflow preferences, and raises the oracle.apps.global.user.change event. Predefined subscriptions to this event create new users in the WF_LOCAL_ROLES table if necessary and load the user information into the WF_LOCAL_ROLES table.
Because WF_LDAP.Synch_all( ) retrieves information for all users stored in Oracle Internet Directory, this function should be used only once during setup. If necessary, however, you can also run WF_LDAP.Synch_all( ) as required for recovery or cleanup.
Subsequently, you must maintain the synchronization between your Workflow directory service and Oracle Internet Directory by retrieving and loading only changed Oracle Internet Directory user information. It is recommended that you update the user information every ten minutes.
You can use either WF_LDAP.Synch_changes( ) or WF_LDAP.Schedule_changes( ) to retrieve changed user information from Oracle Internet Directory. WF_LDAP.Synch_changes( ) identifies LDAP user changes in Oracle Internet Directory, including creation, modification, and deletion, by querying the LDAP change log records. The function connects to Oracle Internet Directory based on the LDAP directory information specified in the global workflow preferences. If there is a change, the function retrieves the user information from Oracle Internet Directory and raises the oracle.apps.global.user.change event. Predefined subscriptions to this event create new users in the WF_LOCAL_ROLES table if necessary and load the user information into the table. You can use WF_LDAP.Synch_changes( ) to perform a single update.
To continue updating user information periodically, use WF_LDAP.Schedule_changes( ). This procedure submits a database job using the DBMS_JOB utility to run WF_LDAP.Synch_changes( ) repeatedly at an interval that you specify. The default interval, which is also the recommended frequency to check for updates, is ten minutes.
You can create a script to run WF_LDAP.Schedule_changes( ). For example, to run the API at an interval of ten minutes, create a SQL file with the following commands:
declare
begin
wf_ldap.schedule_changes(0,0,10);
end;
/
Then run SQL*Plus and load your new script to the database.
Note: You must terminate the running of any WF_LDAP APIs before changing your LDAP setup, such as by migrating to a different LDAP server.
Attention: If you implement Oracle Internet Directory integration, you must maintain your users only through Oracle Internet Directory. You must not create ad hoc users in the WF_LOCAL_ROLES table, because you risk discrepancies in your user information and unpredictable results if you use any tool other than Oracle Internet Directory to maintain users after integrating with Oracle Internet Directory. Consequently, if you implement Oracle Internet Directory integration, you must not use the CreateAdHocUser( ), SetAdHocUserStatus( ), SetAdHocUserExpiration( ), or SetAdHocUserAttr( ) APIs in the WF_DIRECTORY package.
You can still use ad hoc roles, however, since Workflow roles are not maintained through Oracle Internet Directory.
See: Setting Global User Preferences, Workflow LDAP APIs, Oracle Workflow API Reference, User Entry Has Changed Event, Oracle Workflow Developer's Guide, Managing Job Queues, Oracle Administrator's Guide, and Workflow Directory Service APIs, Oracle Workflow API Reference.
The Oracle Workflow Web pages, your workflow definitions, and workflow notifications can be translated to the languages defined in your Oracle installation. Some of the steps for setting up other languages in addition to English differ for the standalone and embedded versions of Oracle Workflow.
Note: You can only display languages that require a multibyte character set if your database uses a character set that supports these languages, such as UTF8. For more information, see: Choosing a Character Set, Oracle Database Globalization Support Guide.
WF_LANGUAGES View
To support additional languages, Oracle Workflow uses a view called WF_LANGUAGES that identifies the languages defined in your Oracle installation. This view is automatically created during installation for both the standalone and the embedded versions of Oracle Workflow. Oracle Workflow uses the WF_LANGUAGES view to create, in its translatable tables, a row for each language that maps to a row found in the corresponding non-translated base table.
The WF_LANGUAGES view includes 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 character set for the language.
Installed_Flag - Flag to indicate if the language is installed and available for use.
See: Oracle Database Globalization Support Guide.
To Display Oracle Workflow Web Pages in Other Languages
For Oracle Workflow embedded in Oracle Applications, you select and install additional languages as part of the Oracle Applications installation. Users can set their language preference to an installed language through the Personal Homepage in order to view Oracle Applications screens in that language. See: Selecting NLS Settings, Installing Oracle Applications and Set Preferences, Oracle Applications User's Guide.
For the standalone version of Oracle Workflow, the server installation and upgrade are available only in English. To support access to Oracle Workflow Web pages in another language, you must load that language after the installation using the Oracle Workflow Configuration Assistant. See the installation documentation for your release and platform.
The Oracle Workflow Configuration Assistant performs the following tasks to set up a language:
Runs the script wfnlena.sql to enable the language. See: wfnlena.sql.
Runs the script WFNLADD.sql to create rows for the enabled language in each workflow object translation table. See: WFNLADD.sql.
Loads translated resource files for the user interface using the Workflow Resource Generator, translated versions of the standard and demonstration workflow definitions using the Workflow Definitions Loader, and translated Business Event System object definitions using the Workflow XML Loader.
If you have multiple languages loaded for Oracle Workflow, as a workflow administrator, you can specify the default language that your users' Web sessions display by setting the Language preference in the Global Preferences page. Individual users can override the default language by setting the Language preference in the User Preferences page. See: Setting Global User Preferences and Setting User Preferences, Oracle Workflow User's Guide.
Note: To display Oracle Workflow Web pages properly, the character sets on the database tier and middle tier must match. The NLS_LANG value specified in the Database Access Descriptor (DAD) for Oracle Workflow in Oracle HTTP Server should be set to the database character set, using the following format:
.CHARSET
Note that it is important to include the period (.) before the character set name in the NLS_LANG value. For more information, see the installation documentation for your release and platform.
To Create and View Workflow Definitions in Other Languages using Oracle Workflow Builder
Set the NLS_LANG environment variable for the new language, territory, and encoded character set that you want to use for the workflow definition. For example, for Windows NT, run the regedit32 command and locate the NLS_LANG setting under the HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE hierarchy. Double click on NLS_LANG. Then set the variable to the new value and save your work. Specify the value for NLS_LANG in the following format:
LANGUAGE_TERRITORY.CHARSET
For more information about setting NLS_LANG, see: Globalization Support, Oracle Database Installation Guide.
Start Oracle Workflow Builder. Create a translated version of your workflow definition and save it as a flat file (.wft), or open and view a workflow definition that is already translated.
Note: Although you can enter and view property values for your workflow definitions in other languages, the Oracle Workflow Builder user interface is still displayed in English.
To Load Workflow Definitions in Other Languages to a Database
Ensure that the WF_LANGUAGES view has been created in your workflow server. This view is automatically created during installation.
Ensure that the language you want is set up in the database.
For Oracle Workflow embedded in Oracle Applications, you select and install additional languages as part of the Oracle Applications installation. See: Selecting NLS Settings, Installing Oracle Applications.
For standalone Oracle Workflow, the server installation automatically adds all available languages to your workflow database. See the installation documentation for your release and platform.
For standalone Oracle Workflow, the server installation and upgrade are available only in English. To support access to workflow definitions in another language, you must load that language after the installation using the Oracle Workflow Configuration Assistant. See the installation documentation for your release and platform.
Load the translated workflow definition to your workflow database using either the Workflow Definitions Loader or the Workflow Builder.
Before running the Workflow Definitions Loader program, you must set the NLS_LANG environment variable to the appropriate territory and character set for the workflow definition you want to load. The character set must match the character set encoding used to create the workflow definition file, which is determined by the NLS_LANG value that was set on the client PC before the .wft file was created in the Workflow Builder. For example, if the .wft file was created in the Japanese native character set encoding JA16SJIS, then you must specify JA16SJIS in the character set portion of NLS_LANG before loading the file, and you cannot specify a different character set such as UTF8.
To set NLS_LANG before running the Workflow Definitions Loader, use the following format:
_TERRITORY.CHARSET
Note that it is important to include the underscore (_) before the territory name and the period (.) between the territory name and the character set name in the NLS_LANG value. For example, if the .wft file was created in the Japanese native character set encoding JA16SJIS, set NLS_LANG to the following value:
_JAPAN.JA16SJIS.
You do not need to include the language in this NLS_LANG value because the Workflow Definitions Loader uses the language specified within the .wft file to determine the language to load. See: Using the Workflow Definitions Loader.
Note: If you create all your translated workflow definition files in Unicode encoding, you can simply set NLS_LANG to .UTF8 before loading these files. In this case you will not need to reset NLS_LANG for translated files in different languages, because the .UTF8 character set applies to all the files in Unicode encoding.
Before using the Workflow Builder to save a translated workflow definition to the database, you must set the NLS_LANG environment variable to the appropriate language, territory, and character set. If you are saving several workflow definitions in different languages, you must reset NLS_LANG for each language. See: Opening and Saving Item Types, Oracle Workflow Developer's Guide.
Note: The translated versions of Oracle Workflow's standard and demonstration workflow definitions are provided in native character set encoding, not in UTF8.
To Send E-mail Notifications in Other Languages
Determine whether Oracle has translated the e-mail notification templates to the language you wish to set by checking for the file containing the templates in the appropriate language subdirectory, ORACLE_HOME/wf/res/<lang> for the standalone version of Oracle Workflow or $FND_TOP/import/<lang> for the version of Oracle Workflow embedded in Oracle Applications. The standard templates are delivered in a file called wfmail.wft. See: Modifying Your Message Templates.
If the e-mail templates are available for the desired language, Oracle Workflow uses the language preference for the notification recipient to determine the language for an e-mail notification.
Oracle Applications users can set their language preference in the Preferences page. This preference is also stored in the ICX: Language profile option. See: Set Preferences, Oracle Applications User's Guide.
Note: In Oracle Applications, users can select a session-level language in the login window, which overrides their user-level language preference for that session. However, Oracle Workflow still uses the user-level language preference to determine the language in which e-mail notifications are sent.
For standalone Oracle Workflow, as the workflow administrator, you can specify the default language setting in the Global Preferences page. Individual users can override the default language setting by specifying their own preferred language in the User Preferences page. See: Setting Global User Preferences and Setting User Preferences, Oracle Workflow User's Guide.
If you are using the standalone version of Oracle Workflow and your Workflow server is installed on a UNIX platform, you must set an environment variable called WF_RESOURCES to point to the language-dependent Oracle Workflow resource file (wf<language>.res). The resource file generally resides in the ORACLE_HOME/wf/res directory.
Attention: Do not enclose environment variable values in double quotes (" ") as this is not supported.
You do not need to set this environment variable if your Workflow server is installed on the Windows platform. The Workflow server installation on Windows automatically sets a WF_RESOURCES environment variable that identifies the path of the wf<language>.res file.
You also 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<language>.res.
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 workflow process can also include a Wait activity, which defers the continuation of a process until a later time. This type of deferred activity is also completed by a background engine.
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, and 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 <Timeout> transition activity.
Additionally, a background engine must be set up to handle stuck processes. A process is identified as stuck when it has a status of ACTIVE, but cannot progress any further. For example, a process could become stuck in the following situations:
A thread within a process leads to an activity that is not defined as an End activity but has no other activity modeled after it, and no other activity is active.
A process with only one thread loops back, but the pivot activity of the loop has the On Revisit property set to Ignore.
An activity returns a result for which no eligible transition exists. For instance, if the function for a function activity returns an unexpected result value, and no default transition is modeled after that activity, the process cannot continue.
The background engine sets the status of a stuck process to ERROR:#STUCK and executes the error process defined for it.
The following table lists the standard queues used in background engine processing.
| Queue Table | Queue Name | Payload Type | Retention Time | Description |
|---|---|---|---|---|
| WF_DEFERRED_QUEUE_M | WF_DEFERRED_QUEUE_M | SYSTEM. WF_PAYLOAD_T | 0 days | Standard background deferred queue |
| WF_OUTBOUND_QUEUE | WF_OUTBOUND_QUEUE | SYSTEM. WF_PAYLOAD_T | 0 days | Standard background outbound queue |
| WF_INBOUND_QUEUE | WF_INBOUND_QUEUE | SYSTEM. WF_PAYLOAD_T | 0 days | Standard background inbound queue |
Note: These queues are also used by the Java Function Activity Agent. See: Setting Up the Java Function Activity Agent and Workflow Queue APIs, Oracle Workflow API Reference.
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 or database job 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).
Ensure that you have at least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities as well as stuck processes. However, for performance reasons we recommend that you run three separate background engines at different intervals.
Run a background engine to handle only deferred activities every 5 to 60 minutes.
Run a background engine to handle only timed out activities every 1 to 24 hours as needed.
Run a background engine to handle only stuck processes once a week to once a month, when the load on the system is low.
To Start a Background Engine
If you are using the standalone version of Oracle Workflow, then use the WF_ENGINE.BACKGROUND() API to start up a background engine. Sample scripts that repeatedly run the background engine are provided with the standalone version of Oracle Workflow. You can also use the procedures in the DBMS_JOB or DBMS_SCHEDULER packages to schedule and manage the background engine as a database job. See: Background, Oracle Workflow API Reference and Managing Job Queues, Oracle Database Administrator's Guide or Using the Scheduler, Oracle Database Administrator's Guide.
Additionally, in standalone Oracle Workflow, you can use the Oracle Workflow Manager component available through Oracle Enterprise Manager to submit and manage Workflow background engine database jobs. For more information, please refer to the Oracle Workflow Manager online help.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can start a background engine by submitting the Background Process concurrent program using the Submit Requests form. See: To Schedule Background Engines.
Additionally, in Oracle Applications, you can use the Oracle Workflow Manager component of Oracle Applications Manager to submit and manage the Workflow Background Process concurrent program. For more information, please refer to the Oracle Applications Manager online help.
Note: Make sure you have a least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities as well as stuck processes.
To Schedule Background Engines
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can submit the background engine procedure as a concurrent program to schedule different background engines to run at different times. Use the Submit Requests window in Oracle Applications to submit the Workflow Background Process. See: Overview of Concurrent Programs and Requests, Oracle Applications System Administrator's Guide.
Note: If you require a larger rollback segment for the Workflow Background Process than the default, you can use the Concurrent Programs window in the System Administrator responsibility to specify the rollback segment that you want. This rollback segment will be used instead of the default and will be used up until the first commit.
Query the Workflow Background Process concurrent program (FNDWFBG) in the Concurrent Programs window, and choose the Session Control button. Then in the Session Control window, enter the rollback segment you want in the Rollback Segment field, and save your work. See: Concurrent Programs Window, Oracle Applications System Administrator's Guide.
To Run a Workflow Background Process as a Concurrent Program
Navigate to the Submit Requests form.
Submit the Workflow Background Process concurrent program as a request. See: Running Reports and Programs, Oracle Applications User's Guide.
In the Parameters window, enter values for the following parameters:
| Variable | Description |
|---|---|
| Item Type | Specify an item type to restrict this engine to activities associated with that item type. If you do not specify an item type, the engine processes any deferred activity regardless of its item type. |
| Minimum Threshold | Specify the minimum cost that an activity must have for this background engine to execute it, in hundredths of a second. |
| Maximum Threshold | Specify the maximum cost that an activity can have for this background engine to execute it, in hundredths of a second. By using Minimum Threshold and Maximum Threshold you can create multiple background engines to handle very specific types of activities. The default values for these arguments are null so that the background engine runs activities regardless of cost. |
| Process Deferred | Specify whether this background engine checks for deferred activities. Setting this parameter to 'Yes' allows the engine to check for deferred activities. |
| Process Timeout | Specify whether this background engine checks for activities that have timed out. Setting this parameter to 'Yes' allows the engine to check for timed out activities. |
| Process Stuck | Specify whether this background engine checks for stuck processes. Setting this parameter to 'Yes' allows the engine to check for stuck processes. |
Note: Make sure you have a least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes.
Choose OK to close the Parameters window.
When you finish modifying the run options to define the schedule for the background engine, choose Submit to submit the request.
To Set Engine Thresholds
To set the thresholds of background engines, specify the minimum threshold and maximum threshold arguments when starting the engine. The background engine then only processes activities with costs within your specifications.
The Workflow Engine threshold is set to 50 as a default. Activities with a cost higher than 50 are deferred for background engines to process.
In some cases, you may want to force the engine to defer an activity although the activity's cost is less than fifty. You can do this by altering the Workflow Engine threshold in the PL/SQL stored procedure for a function activity.
The engine threshold is set in an externalized constant called THRESHOLD. Include the following line in your PL/SQL procedure to set the Workflow Engine threshold to a different value:
WF_ENGINE.THRESHOLD := n;
You should reset the threshold value afterwards in SQL*Plus or in the next function activity so that other activities are processed as expected.
Related Topics
Activity Cost, Oracle Workflow Developer's Guide
Timeout Transitions, Oracle Workflow Developer's Guide
Wait Activity, Oracle Workflow Developer's Guide
A notification mailer is a Java program that performs e-mail send and response processing for the Oracle Workflow Notification System, using the JavaMail API. You need to implement one or more notification mailers only if you want to have your workflow users receive their notifications by e-mail, as well as from the Worklist Web pages.
See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide and Defining Rules for Automatic Notification Processing, Oracle Workflow User's Guide.
Managing Notification Mailers
The notification mailer program is defined as a service component type in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services. For more information about managing service components, please refer to the Oracle Applications Manager online help or the Oracle Enterprise Manager online help.
Oracle Workflow provides one seeded notification mailer service component, called Workflow Notification Mailer. Most of the configuration parameters for this mailer are set to default values. You can enter the remaining required parameters using the Oracle Workflow Configuration Assistant for the standalone version of Oracle Workflow. For Oracle Applications, you can enter several of the remaining required parameters using AutoConfig and then simply enter the e-mail inbox password after installation in order to complete the configuration of the Workflow Notification Mailer. If the mail servers and Business Event System components used by the notification mailers are set up, and the service component container to which the Workflow Notification Mailer belongs is started, the seeded notification mailer automatically starts running once its configuration is complete. Alternatively, if you only want to send outbound messages and do not need to receive inbound messages, you only need to set the inbound thread count to zero and enter placeholder values for the inbound configuration parameters after installation.
You cannot delete the seeded Workflow Notification Mailer or edit its name, assigned agents, correlation ID value, or container. However, if necessary you can optionally update other configuration parameters, schedule control events, or manually choose control commands to start, stop, suspend, resume, or refresh this notification mailer.
You can also optionally create additional notification mailer service components. For example, you can create a notification mailer that processes only messages that belong to a particular workflow item type. You can also configure any notification mailer service component to process only inbound messages, or only outbound messages.
You associate inbound and outbound mailers with each other by assigning them the same mailer node name. You can optionally assign the same node name to multiple outbound mailers, but you must not assign the same node name to more than one mailer that performs inbound processing.
If you create an outbound-only mailer, but you still want to perform response processing for e-mail responses to the outbound messages it sends, you should create exactly one other mailer with the same node name that does perform inbound message processing. Otherwise, there will be no inbound mailer that can process incoming responses to outbound messages sent by this outbound mailer.
If you only want to implement outbound message processing, without inbound e-mail response processing, then you can configure an outbound-only mailer without creating a corresponding inbound mailer. In this case you should configure the mailer to use message templates for response-required notifications that do not request a response by e-mail, but instead direct recipients to respond from the Notification Details Web page. For example, you can configure the mailer to send response-required notifications using the Workflow View From UI message template, which is an alternative template provided by Oracle Workflow in the System: Mailer item type, or create your own custom message templates. The outbound-only mailer can still use the standard message templates to send outbound summary notifications or For Your Information (FYI) notifications that do not require a response.
If you create an inbound-only mailer, you should create at least one outbound mailer with the same node name. Otherwise, no inbound response messages will be marked with that node name and this inbound mailer will have no messages to process.
Note: The node name for each node must be unique. However, multiple outbound mailers and one inbound mailer can share the same node. The maximum length for a node name is eight characters, and the node name cannot include any spaces or any of the following characters: left bracket ([), right bracket (]), slash (/), or at sign (@).
Service components must be hosted by a service component container. If you create custom notification mailer service components, you can assign them to the seeded container for notification mailers.
In Oracle Applications, a service component container is implemented as a Generic Service Management (GSM) service. The seeded container for notification mailers is named Workflow Mailer Service.
In standalone Oracle Workflow, a service component container is implemented as a servlet within an OC4J instance. The seeded container for notification mailers is named WFMLRSVC, within an OC4J instance named OC4J_Workflow_Component_Container.
In Oracle Applications only, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers as GSM services in Oracle Applications Manager. If you create a custom GSM service in OAM, you can copy the service parameters from the seeded Workflow Mailer Service to your new service in order to specify how to run the new service. For more information about notification mailer configuration options, please refer to the Oracle Applications Manager online help or the Oracle Enterprise Manager online help.
Setting Up Notification Mailers
Currently, Oracle Workflow supports the Simple Mail Transfer Protocol (SMTP) for outbound messages and the Internet Message Access Protocol (IMAP) for inbound messages. You must have an SMTP server set up in order to send Oracle Workflow notification e-mail messages, and and an IMAP server set up if you want to receive e-mail notification responses. Users can receive e-mail notifications using various e-mail clients, although notifications may be displayed differently in different clients, depending on the features each client supports.
Note: Oracle Workflow supports IMAP version 4 (IMAP4) compliant mail servers. Ensure that your mail server uses this IMAP version. For more information, see the JavaMail API Design Specification: http://java.sun.com/products/javamail/JavaMail-1.2.pdf
Note: If you have certain types of software installed, you may already have the necessary mail server functionality available. For example, products such as Oracle Email, Microsoft Exchange, or Lotus Notes include IMAP services. You can use a UNIX server as an SMTP server by configuring the Sendmail program.
Additionally, you can choose to use IMAP server software that is available for download from some sources. For example, the University of Washington offers the UW IMAP Server as a public service, and Carnegie Mellon University offers the Cyrus IMAP Server. You might choose this option if your enterprise uses UNIX Sendmail e-mail accounts, for instance. For more information, see: http://www.washington.edu/imap/, http://asg.web.cmu.edu/cyrus/, and http://www.imap.org/.
Note: Third party software products are mentioned as examples only. Oracle makes no recommendation or endorsement of these third party software products.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you should use the Oracle Workflow Manager component of Oracle Applications Manager (OAM) to configure and run notification mailers. For more information, please refer to the Oracle Applications Manager online help.
If you are using the standalone version of Oracle Workflow, you should use the standalone Oracle Workflow Manager component available through Oracle Enterprise Manager to configure and run notification mailers. For more information, please refer to the Oracle Enterprise Manager online help.
To set up a notification mailer, you must perform the following steps.
To Set Up a Notification Mailer
Set up an SMTP mail server to send outbound messages.
Set up an IMAP4 compliant mail server if you want to receive inbound messages.
If you want to receive inbound messages, set up an e-mail account for the notification mailer on your IMAP mail server, and set up three folders within that account: one to use as an inbox, one to store processed messages, and one to store discarded messages. The default values for these folders in the notification mailer configuration wizard are INBOX, PROCESS, and DISCARD. To avoid having to change these configuration parameters, name the folders within your account with these default names. Use your e-mail client to create these folders. A notification mailer may not be able to access folders that were created using command line tools outside the e-mail client.
You can enter the following configuration parameters for the seeded Workflow Notification Mailer service component during installation.
In Oracle Applications, you can use AutoConfig to enter these parameters. For more information about running AutoConfig, see OracleMetaLink note 165195.1 and AutoConfig, Oracle Applications AD Utilities Reference Guide.
SMTP server
IMAP server (if you want to receive inbound messages)
Inbox username (if you want to receive inbound messages)
Reply to e-mail address (if you want to receive inbound messages)
HTML agent name (defaults to the value you enter for the Applications Web Agent parameter)
In the standalone version of Oracle Workflow, you can use the Oracle Workflow Configuration Assistant to enter these parameters. See the installation documentation for your release and platform.
SMTP server
IMAP server (if you want to receive inbound messages)
Inbox username (if you want to receive inbound messages)
Inbox password (if you want to receive inbound messages)
Reply to e-mail address (if you want to receive inbound messages)
Processed folder (if you want to receive inbound messages)
Discard folder (if you want to receive inbound messages)
Note: When you enter the SMTP Server and IMAP Server parameters, specify the actual host name for each server. Do not use localhost as the setting for these parameters. You can optionally specify the port number to use on each server. Note, however, that notification mailers do not support SSL (Secure Socket Layer) connections to these servers. If you do not specify a port number, the notification mailer uses port 143 on the IMAP server and port 25 on the SMTP server by default. Specify each server in the following format:
<server_name>[:<port_number>] Ensure that the Business Event System status is set to Enabled in the global workflow preferences, and that the JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES database initialization parameters, which are required for the Business Event System, are set to appropriate values. The Business Event System status is set to Enabled by default, and usually you do not need to change this status. If notification processing is not being completed, however, you should check this preference value.
(Recommended) In Oracle Applications, you can optionally set the WF: Workflow Mailer Framework Web Agent profile option to the host and port of the Web server that notification mailers should use to generate the content for Oracle Applications Framework regions that are embedded in notifications. If this profile option is not set, notification mailers will use the same Web agent specified in the Application Framework Agent profile option. However, if necessary for load balancing purposes, you can optionally specify a different Web agent for notification mailers to use. The WF: Workflow Mailer Framework Web Agent profile option should be set at site level. See: Overview of Setting User Profiles, Oracle Applications System Administrator's Guide.
Before a service component can run, the container which manages it must first be started. The seeded Workflow Notification Mailer service component belongs to a container named Workflow Mailer Service in Oracle Applications or WFMLRSVC in standalone Oracle Workflow. The seeded agent listener service components that are also required for notification mailer processing belong to a container named Workflow Agent Listener Service in Oracle Applications or WFALSNRSVC in standalone Oracle Workflow. You should ensure that these two containers are running, using Oracle Applications Manager for the version of Oracle Workflow embedded in Oracle Applications, or Oracle Enterprise Manager for the standalone version of Oracle Workflow. If you create your own custom containers in OAM for custom service components, ensure that those containers are running as well.
Note: In Oracle Applications, you can run a diagnostic test to verify the GSM services for Oracle Workflow. See: Oracle Workflow Diagnostic Tests.
When the Workflow Agent Listener Service or WFALSNRSVC container is running, it automatically starts seeded agent listener service components named Workflow Deferred Notification Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener, which are required for notification mailer processing. Ensure that these agent listeners are running.
Use the notification mailer configuration wizard to configure your notification mailer service component. If you entered configuration parameters for the seeded Workflow Notification Mailer in the Oracle Workflow Configuration Assistant for standalone Oracle Workflow, you can skip this step. If you entered configuration parameters for the seeded Workflow Notification Mailer in AutoConfig for Oracle Applications, you only need to enter the password for the e-mail inbox in order to complete the configuration for that mailer and begin running it.
If you did not enter parameters for the seeded mailer during installation, then in order to complete the configuration for that mailer you need to enter only the SMTP server, IMAP server, e-mail inbox username, e-mail inbox password, processed folder, discard folder, reply to e-mail address, and for Oracle Applications only, the HTML agent name. All other configuration parameters for the seeded Workflow Notification Mailer are initially set to default values and do not need to be changed, although you can optionally do so if you choose.
Note: The IMAP server, e-mail inbox username, e-mail inbox password, and reply to e-mail address are required only if you want to receive inbound messages. Alternatively, if you only want to send outbound messages and do not need to receive inbound messages, you only need to set the inbound thread count to 0 after installation and enter placeholder values for the inbound configuration parameters in order to complete the configuration of the Workflow Notification Mailer.
(Optional) By default, the seeded Workflow Notification Mailer has a Launch Summary Notifications event scheduled to send summary notifications once a day. You can optionally use the notification mailer configuration wizard to modify the start time and interval for this event's schedule, or to schedule the Launch Summary Notifications event at the interval you choose for any notification mailer service component. When this event is processed, a summary notification is sent to each role with a notification preference of SUMMARY or SUMHTML, listing all the notifications that are currently open for that role.
(Optional) In Oracle Applications, you can optionally use the WF: Mailer Cancellation Email profile option to determine whether notification mailers send cancellation messages when previously sent notifications are canceled. Set this profile option to Enabled if you want to send cancellation messages, or to Disabled if you do not want to send cancellation messages. The WF: Mailer Cancellation Email profile option must be set at site level. The default value is Enabled. See: Overview of Setting User Profiles, Oracle Applications System Administrator's Guide.
(Optional) By default, notification mailers require a response format for plain text notifications called the templated response method. If you want to use the direct response method instead, you can run a script named afsvcpup.sql to set the internal mailer parameter named DIRECT_RESPONSE to Y.
With the templated response method, a notification mailer sends plain text notifications requiring a templated response to users with a notification preference of MAILTEXT or MAILATTH. Users must reply using a template of response prompts and enter their response values between the quotes following each prompt.
With the direct response method, a notification mailer sends plain text notifications requiring a direct response to users with a notification preference of MAILTEXT or MAILATTH. Users must enter their response values directly as the first lines of a reply.
Note: Responses that are generated automatically from an HTML-formatted notification or attachment must always use a response template, regardless of which response method you select.
By default, the DIRECT_RESPONSE parameter is set to N, for the templated response method. To change this setting, run the afsvcpup.sql script located in the $FND_TOP/sql directory for Oracle Applications or the ORACLE_HOME/wf/admin directory for standalone Oracle Workflow. Use the script as follows:
sqlplus <user/pwd> @afsvcpup
At the prompts, enter the component ID for your notification mailer service component, the parameter ID for the DIRECT_RESPONSE parameter, and the value Y. You can find the IDs to enter in the lists displayed by the script, which show first the service components defined in your installation of Oracle Workflow and then the parameters defined for the specified service component. You can also find the component ID for a notification mailer in the Define page of the configuration wizard.
(Optional) By default, notification mailers use the standard Workflow Open Mail (More Information Request) message in the System: Mailer item type as the template for requests for more information about a notification from one user to another user. However, if you use an e-mail application such as Microsoft Outlook Express that cannot process the response link included in that template, you can set an internal mailer parameter named OPEN_MORE_INFO to use the alternative template named Workflow Open Mail (More Information Request for Outlook Express) instead. In particular, if you set the Open Notification parameter in the notification mailer configuration wizard to use the Workflow Open Mail for Outlook Express message, then you should also set the OPEN_MORE_INFO parameter to use the Workflow Open Mail (More Information Request for Outlook Express) message. See: Workflow Open Mail (More Information Request for Outlook Express) Message.
By default, the OPEN_MORE_INFO parameter is set to the value WFMAIL:OPEN_MORE_INFO, which is the internal name for the Workflow Open Mail (More Information Request) message in the System: Mailer item type. To change this setting, run the afsvcpup.sql script located in the $FND_TOP/sql directory for Oracle Applications or the ORACLE_HOME/wf/admin directory for standalone Oracle Workflow. Use the script as follows:
sqlplus <user/pwd> @afsvcpup
At the prompts, enter the component ID for your notification mailer service component, the parameter ID for the OPEN_MORE_INFO parameter, and the value WFMAIL:OPEN_MORE_INFO_OUTLOOK, which is the internal name for the Workflow Open Mail (More Information Request for Outlook Express) message. You can find the IDs to enter in the lists displayed by the script, which show first the service components defined in your installation of Oracle Workflow and then the parameters defined for the specified service component. You can also find the component ID for a notification mailer in the Define page of the configuration wizard.
(Optional) The seeded Workflow Notification Mailer uses the Automatic startup mode by default and will be started automatically when you complete its configuration. If you select the Manual startup mode for a notification mailer service component, use the Service Components page in Oracle Workflow Manager to start that notification mailer. You can also use this page to manage any notification mailer service component.
Outbound Notification Mailer Processing
When the Workflow Engine determines that a notification message must be sent, it raises an event in the Business Event System called oracle.apps.wf.notification.send. Oracle Workflow provides a seeded subscription to this event, which is defined to be deferred immediately so that the workflow process that owns the notification can continue. The event is placed on the standard WF_DEFERRED agent. Oracle Workflow provides a seeded agent listener named Workflow Deferred Notification Agent Listener that runs on this agent to continue notification processing. This agent listener is dedicated solely to processing deferred notification events.
When the event is dequeued from WF_DEFERRED and the subscription is processed, the subscription requires the event data for the event, causing the generate function for the event to be executed. The generate function for this event performs the following actions:
Resolves the notification recipient role to a single e-mail address, which itself can be a mail list.
Checks the notification preference of the recipient to determine whether an e-mail notification is required, and in what type of format.
Switches its database session to the recipient role's preferred language and territory as defined in the directory service.
Generates an XML representation of the notification message and any optional attachments using the appropriate message template.
Finally, the subscription places the event message on the standard WF_NOTIFICATION_OUT agent.
A notification mailer service component polls the WF_NOTIFICATION_OUT agent for messages that must be sent by e-mail. When the notification mailer dequeues a message from this agent, it uses a Java-based notification formatter to convert the XML representation of the notification into a MIME (Multi-purpose Internet Mail Extensions) encoded message and sends the message by the Simple Mail Transfer Protocol (SMTP).
Outbound Notification Mailer Processing
The e-mail notifications are based on message templates defined in Oracle Workflow Builder. Oracle Workflow provides a set of standard templates in the System: Mailer item type, which are used by default. It is not recommended to modify the standard templates. However, you can customize the message templates used to send your e-mail notifications by creating your own custom message templates in the System: Mailer item type using the Workflow Builder, and assigning these templates to a particular notification mailer service component in the mailer configuration parameters. The templates assigned to a mailer override the default System: Mailer templates. See: Modifying Your Message Templates.
Additionally, you can create your own custom message templates in a custom item type using the Workflow Builder, and assign these templates to a particular notification in a workflow process by defining special message attributes. In this case the templates assigned to the notification override both the templates assigned to a mailer and the default System: Mailer templates. See: Modifying Your Message Templates and Notification Mailer Message Template Attributes, Oracle Workflow Developer's Guide.
Inbound Notification Mailer Processing
Notification mailers can also process e-mail responses from users, using the Internet Message Access Protocol (IMAP). A notification mailer uses a Java-based e-mail parser to interpret the text of each message and create an XML representation of it.
A notification mailer uses three folders in your response mail account for response processing: one to receive incoming messages, one to store processed messages, and one to store discarded messages.
A notification mailer does the following to process response messages:
Logs into its IMAP e-mail account.
Checks the inbox folder for messages. If a message exists, the notification mailer reads the message, checking for the notification ID (NID) and node identifier in the NID line.
If the message is not a notification response, meaning it does not contain an NID line, the notification mailer moves the message to the discard folder and treats it as an unsolicited message. For the first unsolicited message from a particular e-mail address, the notification mailer also sends a warning message back to the sender of the message.
However, to avoid sending unnecessary warnings due to bounced or auto-reply messages, each mailer node stores a list of e-mail addresses from which it has received unsolicited mail, and does not send any further warning messages to those addresses. Instead, if the node receives a second unsolicited message from a particular address, the notification mailer discards the message and raises the oracle.apps.wf.mailer.unsolicited event. You can optionally define a subscription to this event if you want to perform some other action in response to the second unsolicited message. For all subsequent unsolicited messages, the notification mailer simply discards the message.
Note: Each mailer node can store up to 100 e-mail addresses in its warned list. If the node receives unsolicited messages from additional addresses when the list is already full, the notification mailer removes the oldest addresses from the list and adds the new addresses in their place. Also, the notification mailer clears the list by removing all addresses when you start the mailer for the first time, and again whenever you stop and restart its container. In these cases, the mailer may send another warning message if it receives further unsolicited e-mail from an address that is no longer on the warned list.
If the message is a notification response, but for the wrong node, the notification mailer leaves the message in the inbox.
If the message is a notification response for the current node, meaning it contains an NID line including the node identifier of the current node, the notification mailer processes the message.
The notification mailer performs the following steps for messages that belong to its node.
Retrieves the notification ID.
Checks to see if the message bounced by referring to the tags specified in the configuration parameters, if any. If the message bounced, the notification mailer reroutes it or updates the notification's status and stops any further processing, depending on the specifications of the tag list.
Checks the Oracle Workflow database for this notification based on the NID line.
If the notification does not exist, meaning the notification ID or the access key in the NID line is invalid, the notification mailer moves the message to the discard folder. If the NID line is incorrectly formatted, the notification mailer moves the message to the discard folder and and treats it as an unsolicited message.
If the notification exists, but is closed or canceled, the notification mailer moves the message to the discard folder and sends a Workflow Closed Mail or Workflow Canceled Mail message to the recipient role, respectively.
If the notification exists and is open, the notification mailer generates an XML representation of the message and places it on the standard WF_NOTIFICATION_IN agent as an event called oracle.apps.wf.notification.receive.message. The notification mailer then moves the e-mail message to the processed folder.
Note: If the character encoding of the response message is not compatible with the database codeset, the notification mailer may not be able to parse the response and recognize the response values. Ensure that the character encoding of messages in your mail client is compatible with the codeset of your database.
Finally, if there are no more unprocessed messages in the inbox, the notification mailer logs out of the e-mail account.
Oracle Workflow provides a seeded agent listener named Workflow Inbound Notifications Agent Listener that runs on the WF_NOTIFICATION_IN agent to continue notification processing for the valid response messages placed on that agent. When an event message is dequeued from WF_NOTIFICATION_IN, Oracle Workflow executes a seeded subscription that calls the appropriate notification response function. This function verifies the response values with the definition of the notification message's response attributes in the database. If a response value is invalid, or if no response value is included, the notification response function causes the notification mailer to send a Workflow Invalid Mail message to the recipient role. If the responses are valid, the notification response function records the response and completes the notification.
Inbound Notification Mailer Processing
See: Workflow Warning Mail Message, Workflow Closed Mail Message, Workflow Canceled Mail Message, Workflow Invalid Mail Message, and Workflow Invalid Open Mail (More Information Request) Message.
Wireless Notifications
If you are using the standalone version of Oracle Workflow available with Oracle Application Server, then you can also send wireless notifications using Oracle Application Server Wireless. Oracle Application Server Wireless integrates with Oracle Workflow by providing a subscriber to the WF_NOTIFICATION_OUT queue. This subscriber dequeues notification messages from the queue as JMS Text messages and can then send them to wireless devices. If a user sends a response from a wireless device, Oracle Application Server Wireless calls the appropriate notification response function to record the response and complete the notification. For more information, please refer to the Oracle Application Server Wireless Administrator's Guide and the Oracle Application Server Wireless Developer's Guide.
Note: You can run Oracle Workflow notification mailers concurrently with Oracle Application Server Wireless if you want to send both e-mail notifications and wireless notifications. Both components can access the same notification messages on the WF_NOTIFICATION_OUT queue.
Full MIME Support
Oracle Workflow fully supports MIME (Multi-purpose Internet Mail Extensions) encoded messages. This means that notification mailers can exchange messages with workflow users containing languages with different character sets and multi-media encoded content.
Notification Preferences
Oracle Workflow lets users determine how they view notifications by setting a notification preference. As a workflow administrator, you can set the default notification preference for all users in your enterprise using the Global Preferences page in standalone Oracle Workflow or the Workflow Configuration page in Oracle Applications. Users can override the default by modifying their individual notification preference setting in the User Preferences Web page for standalone Oracle Workflow or the Preferences page in Oracle Applications. See: Setting Global User Preferences, Setting User Preferences, Oracle Workflow User's Guide, and Set Preferences, Oracle Applications User's Guide.
Often, the functionality of a user's mail reader determines what the user's notification preference should be. Some mail readers can only display plain text, others can display HTML formatting, while still others can only display HTML formatting in an attachment. The following notification preferences are available:
Plain text mail (MAILTEXT) - The notification message appears as plain text, with no attachments. See: Plain Text E-mail.
HTML mail with attachments (MAILHTML) - The notification message appears as HTML-formatted text, with at least one standard attachment that is a link to the notification in the Notification Details Web page. If the notification message has 'Content-Attached' message attributes, these attributes appear as additional custom attachments to the message. See: HTML-Formatted E-mail with Attachments.
HTML mail (MAILHTM2) - The notification message appears as HTML-formatted text, but does not include any standard attachments. If the notification message has 'Content-Attached' message attributes, however, these attributes appear as custom attachments to the message. See: HTML-Formatted E-mail.
Attention: If you wish to view notifications with HTML formatting, but your mail reader is not able to interpret HTML formatting in the mail message body, change your notification preference to 'Plain text mail with HTML attachments' (MAILATTH). The MAILATTH preference delivers an HTML-formatted version of the notification as an attachment to the plain text notification.
Plain text mail with HTML attachments (MAILATTH) - The notification message appears as plain text, with at least two standard attachments. One attachment is an HTML-formatted version of the message, and the other is a link to the notification in the Notification Details Web page. If the notification message has 'Content-Attached' message attributes, these attributes appear as additional custom attachments to the message. See: Plain Text E-mail with an HTML Attachment.
Plain text summary mail (SUMMARY) - The message is a plain text summary of all open notifications. To respond to the individual notifications in the summary, you must access the notifications from the Worklist Web page.
HTML summary mail (SUMHTML) - The message is an HTML-formatted summary of all open notifications, with a link to the Worklist Web page as well as links to each notification in the Notification Details Web page. To respond to the individual notifications in the summary, you must access the notifications from the Web pages. This notification preference is currently available only in the version of Oracle Workflow embedded in Oracle Applications.
Do not send me mail (QUERY) - The notification mailers do not send you e-mail notifications. Instead you must query and respond to your notifications from the Worklist Web page.
Attention: You can always query and respond to your notifications from the Worklist Web page, even if you set your notification preference to send you mail.
In Oracle Applications, you can run a diagnostic test to check that all users with a notification preference to receive e-mail have an e-mail address defined. See: Oracle Workflow Diagnostic Tests.
See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide, Viewing Notifications from a Web Browser, Oracle Workflow User's Guide, and Reviewing a Summary of Your Notifications via Electronic Mail, Oracle Workflow User's Guide.
Plain Text E-mail
If the performer of a notification has a notification preference of plain text mail (MAILTEXT), when a notification mailer processes the notification, it generates a plain text e-mail message and sends it to the performer role. The notification mailer uses the Text Body defined for the message in the Oracle Workflow Builder message property page to generate the plain text e-mail. It token replaces all attribute values referenced in the message body with plain text values. For example:
PL/SQL and PL/SQL CLOB document attributes are token replaced with a plain text version of a PL/SQL document.
URL attributes are token replaced with the display name of the URL attribute, followed by a colon and the URL:
<URL_Attribute_Display_Name>:<URL>
In Oracle Applications, a document attribute that represents an Oracle Applications Framework region is token replaced with a plain text version of the region. Note that non-text content such as images, links, or special HTML formatting do not appear in the text version of the region. A notification with an embedded Oracle Applications Framework region can contain multiple regions. However, it cannot contain any tokens for content other than regions.
Attention: Message attributes that have Attach Content checked in their Attributes property page, are attached as plain text to their parent notification. Note that this may render some attachments unreadable if the attachment includes special formatting or your plain text e-mail reader does not recognize attachments. To view these attachments, you should display your notifications in the Worklist Web page. See: Viewing Notifications from a Web Browser, Oracle Workflow User's Guide.
A recipient of a plain text e-mail notification responds by manually replying to the notification and entering response values following the instructions provided in the notification. See: To Respond to a Plain Text E-mail Notification Using Templated Response, Oracle Workflow User's Guide and To Respond to a Plain Text E-mail Notification Using Direct Response, Oracle Workflow User's Guide.
HTML-Formatted E-mail with Attachments
If the performer of a notification has a notification preference of HTML mail with attachments (MAILHTML), when a notification mailer processes the notification, it generates an HTML-formatted e-mail notification and sends it to the performer role. The recipient should use an e-mail reader that can interpret and display HTML content within a message body.
Note: If your e-mail reader cannot interpret HTML formatting in a message body, you should set your notification preference to plain text mail with HTML Attachments (MAILATTH).
The notification mailer uses the HTML Body defined for the message in the Message Body property page to generate the HTML e-mail message. If no HTML Body is defined, it uses the Text Body to generate the HTML message. The notification mailer token replaces all message attributes referenced in the message body with HTML-formatted values. For example:
PL/SQL and PL/SQL CLOB document attributes are token replaced with HTML text or plain text between <pre>...</pre> HTML tags.
URL attributes are token replaced with HTML links, unless the URL points to an image file. When you select such a link, your e-mail reader takes you to the target URL page.
URL attributes that point to an image file are token replaced with <IMG>...</IMG> HTML tags to display the image inline within the message body. Notification mailers treat URL attributes as images if the URL points to a file with an extension of gif, jpg, png, tif, bmp, or jpeg.
In Oracle Applications, a document attribute that represents an Oracle Applications Framework region is token replaced with the HTML version of the region. A notification with an embedded Oracle Applications Framework region can contain multiple regions. However, it cannot contain any tokens for content other than regions.
Note: For notifications that do not include embedded Oracle Applications Framework regions, message attributes that have Attach Content checked in their Attributes property page, are appended as attachments to their parent message. For example:
If the message attribute is a URL attribute, an attachment called Notification References is appended to the message. This attachment includes a link to each URL attribute for the message that has Attach Content checked. You can navigate to a URL by choosing its link. Note that the Notification References attachment does not display images inline. If Attach Content is checked, a URL attribute always appears as a link in the Notification References attachment, even if the URL points to an image file. Notification mailers also do not have any special handling of video or audio URL content.
If the message attribute is a PL/SQL, PL/SQL CLOB, or PL/SQL BLOB document attribute, the fully generated PL/SQL document is fetched and attached to the message.
However, if a notification includes an embedded Oracle Applications Framework region, then Oracle Workflow includes the Related Applications region in the e-mail message with links to the attached URLs or PL/SQL documents, instead of appending them as separate attachments.
You can respond to your HTML-formatted notification by clicking on a link that represents the response in the HTML message body. The response link generates a plain text e-mail response that includes a response template modified with the predefined response value that you select. See: To Respond to an HTML E-mail Notification, Oracle Workflow User's Guide.
If your notification preference is MAILHTML, each HTML-formatted notification always includes at least one standard attachment. The attachment is called Notification Detail Link. When you select this attachment, your e-mail reader opens a browser window that displays your notification in the Notification Details Web page. You can alternatively respond directly to your notification from this Web page, bypassing the need to process your response through a notification mailer.
Note: Depending on your configuration, if you are not already logged in, you may be prompted to log in when you select the Notification Detail Link before you can access the Notification Details page. See: Responses through the Notification Detail Link Attachment.
Note: You can use the Inline Attachment configuration parameter to set the Content-Disposition MIME header to either inline or attachment for all attachments to notification messages, including the Notification Detail Link, Notification References containing attached URLs, and attached PL/SQL, PL/SQL CLOB, or PL/SQL BLOB documents. Note, however, that some e-mail clients may not support the Content-Disposition header, or may support it in varying ways. Consequently, the Inline Attachment setting may not always have the desired effect, depending on the e-mail clients with which users read their e-mail messages.
Note: The file name of the Notification Detail Link attachment is determined by the text value for the WF_URL_NOTIFICATION resource token, or by the token name if no text value is defined. Similarly, the file name of the Notification References attachment is determined by the text value for the WF_URLLIST_ATTACHMENT resource token, or by the token name if no text value is defined. The default file names are "Notification Detail Link.html" and "Notification References.html", respectively. If you want to specify different file names for these attachments, you must first create a .msg source file specifying the new file names as the text values for the WF_URL_NOTIFICATION and WF_URLLIST_ATTACHMENT resource tokens. Then use the Workflow Resource Generator program to upload the new seed data from the source file to the database table WF_RESOURCES. See: To Run the Workflow Resource Generator, Oracle Workflow API Reference and Setting the WF_RESOURCES Environment Variable.
If the performer of a notification has a notification preference of HTML mail (MAILHTM2), without standard attachments, when a notification mailer processes the notification, it generates an HTML-formatted e-mail notification and sends it to the performer role. The recipient should use an e-mail reader that can interpret and display HTML content within a message body.
Note: If your e-mail reader cannot interpret HTML formatting in a message body, you should set your notification preference to plain text mail with HTML Attachments (MAILATTH).
The notification mailer uses the HTML Body defined for the message in the Message Body property page to generate the HTML e-mail message. If no HTML Body is defined, it uses the Text Body to generate the HTML message. The notification mailer token replaces all message attributes referenced in the message body with HTML-formatted values. For example:
PL/SQL and PL/SQL CLOB document attributes are token replaced with HTML text or plain text between <pre>...</pre> HTML tags.
URL attributes are token replaced with HTML links, unless the URL points to an image file. When you select such a link, your e-mail reader takes you to the target URL page.
URL attributes that point to an image file are token replaced with <IMG>...</IMG> HTML tags to display the image inline within the message body. Notification mailers treat URL attributes as images if the URL points to a file with an extension of gif, jpg, png, tif, bmp, or jpeg.
In Oracle Applications, a document attribute that represents an Oracle Applications Framework region is token replaced with the HTML version of the region. A notification with an embedded Oracle Applications Framework region can contain multiple regions. However, it cannot contain any tokens for content other than regions.
Note: For notifications that do not include embedded Oracle Applications Framework regions, message attributes that have Attach Content checked in their Attributes property page, are usually appended as attachments to their parent message. For example:
If the message attribute is a URL attribute, an attachment called Notification References is appended to the message. This attachment includes a link to each URL attribute for the message that has Attach Content checked. You can navigate to a URL by choosing its link. Note that the Notification References attachment does not display images inline. If Attach Content is checked, a URL attribute always appears as a link in the Notification References attachment, even if the URL points to an image file. Notification mailers also do not have any special handling of video or audio URL content.
If the message attribute is a PL/SQL, PL/SQL CLOB, or PL/SQL BLOB document attribute, the fully generated PL/SQL document is fetched and attached to the message.
However, if a notification includes an embedded Oracle Applications Framework region, then Oracle Workflow includes the Related Applications region in the e-mail message with links to the attached URLs or PL/SQL documents, instead of appending them as separate attachments.
Note that although such message-specific attachments may be included, no standard attachments are included with the notification message if your notification preference is MAILHTM2.
You can respond to your HTML-formatted notification by clicking on a link that represents the response in the HTML message body. The response link generates a plain text e-mail response that includes a response template modified with the predefined response value that you select. See: To Respond to an HTML E-mail Notification, Oracle Workflow User's Guide.
Note: You can use the Inline Attachment configuration parameter to set the Content-Disposition MIME header to either inline or attachment for all attachments to notification messages, including Notification References containing attached URLs and attached PL/SQL, PL/SQL CLOB, or PL/SQL BLOB documents. Note, however, that some e-mail clients may not support the Content-Disposition header, or may support it in varying ways. Consequently, the Inline Attachment setting may not always have the desired effect, depending on the e-mail clients with which users read their e-mail messages.
Note: The file name of the Notification References attachment is determined by the text value for the WF_URLLIST_ATTACHMENT resource token, or by the token name if no text value is defined. The default file name is "Notification References.html". If you want to specify a different file name for this attachment, you must first create a .msg source file specifying the new file name as the text value for the WF_URLLIST_ATTACHMENT resource token. Then use the Workflow Resource Generator program to upload the new seed data from the source file to the database table WF_RESOURCES. See: To Run the Workflow Resource Generator, Oracle Workflow API Reference and Setting the WF_RESOURCES Environment Variable.
Plain Text E-mail with an HTML Attachment
If the performer of a notification has a notification preference of plain text mail with HTML attachments (MAILATTH), when a notification mailer processes the notification, it generates a plain text e-mail notification with HTML attachments and sends it to the performer role. The recipient should use an e-mail reader that supports HTML attachments.
The notification mailer uses the Text Body defined for the message in the Message Body property page to generate the plain text body of the e-mail. It also generates an HTML version of the notification message and sends it as an attachment called HTML Message Body to the plain text e-mail. The notification mailer generates the content of the HTML attachment from the HTML Body defined for the message. If no HTML Body is defined, it uses the Text Body to generate the HTML mail. The notification mailer token replaces all message attributes referenced in the plain text message body with plain text values and token replaces all message attributes referenced in the attached HTML message with HTML-formatted values. See: Plain Text E-mail and HTML-Formatted E-mail.
If your e-mail reader supports HTML formatting in the message body, you can optionally select the Inline Attachment configuration parameter to set the Content-Disposition MIME header to inline for attachments. Then the HTML attachment will also appear inline in the message body. Note, however, that some e-mail clients may not support the Content-Disposition header, or may support it in varying ways. Consequently, the Inline Attachment setting may not always have the desired effect, depending on the e-mail clients with which you read your e-mail messages.
Note: For notifications that do not include Oracle Applications Framework regions, message attributes that have Attach Content checked in their Attributes property page, are usually appended as attachments. For example:
If the message attribute is a URL attribute, an attachment called Notification References is appended to the message. This attachment includes a link to each URL attribute for the message that has Attach Content checked. You can navigate to a URL by choosing its link.
If the message attribute is a PL/SQL, PL/SQL CLOB, or PL/SQL BLOB document attribute, the fully generated PL/SQL document is fetched and attached to the message.
However, if a notification includes an embedded Oracle Applications Framework region, then Oracle Workflow includes the Related Applications region in the e-mail message with links to the attached URLs or PL/SQL documents, instead of appending them as separate attachments.
The notifications received by a user whose notification preference is 'Plain text with HTML attachments' always contain at least two standard attachments. The first attachment is HTML Message Body and the other is Notification Detail Link. When you select Notification Detail Link, your e-mail reader opens a browser window that displays your notification in the Notification Details Web page. You can respond directly to your notification from this Web page, bypassing the need to process your response through a notification mailer. See: To Respond to a Plain Text E-mail Notification with an HTML Attachment, Oracle Workflow User's Guide.
Note: Depending on your configuration, if you are not already logged in, you may be prompted to log in when you select the Notification Detail Link before you can access the Notification Details page. See: Responses through the Notification Detail Link Attachment.
Alternatively, a recipient of this type of notification can respond in one of two other ways:
Manually reply to the notification and enter response values following the instructions provided in the notification. See: To Respond to a Plain Text E-mail Notification Using Templated Response, Oracle Workflow User's Guide and To Respond to a Plain Text E-mail Notification Using Direct Response, Oracle Workflow User's Guide.
Select the HTML Message Body attachment to display the HTML-formatted version of the e-mail message, and click on the HTML link that represents the response. The response link generates a plain text e-mail response that includes a response template updated with the predefined response value you select.
Note: You can use the Inline Attachment configuration parameter to set the Content-Disposition MIME header to either inline or attachment for all attachments to notification messages, including the Notification Detail Link, HTML Message Body, Notification References containing attached URLs, and attached PL/SQL, PL/SQL CLOB, or PL/SQL BLOB documents. Note, however, that some e-mail clients may not support the Content-Disposition header, or may support it in varying ways. Consequently, the Inline Attachment setting may not always have the desired effect, depending on the e-mail clients with which users read their e-mail messages.
Note: The file name of the HTML Message Body attachment is determined by the text value for the WF_HTML_MESSAGE resource token, or by the token name if no text value is defined. Similarly, the file name of the Notification Detail Link attachment is determined by the text value for the WF_URL_NOTIFICATION resource token, or by the token name if no text value is defined; and the file name of the Notification References attachment is determined by the text value for the WF_URLLIST_ATTACHMENT resource token, or by the token name if no text value is defined. The default file names are "HTML Message Body.html", "Notification Detail Link.html", and "Notification References.html", respectively. If you want to specify different file names for these attachments, you must first create a .msg source file specifying the new file names as the text values for the WF_HTML_MESSAGE, WF_URL_NOTIFICATION, and WF_URLLIST_ATTACHMENT resource tokens. Then use the Workflow Resource Generator program to upload the new seed data from the source file to the database table WF_RESOURCES. See: To Run the Workflow Resource Generator, Oracle Workflow API Reference and Setting the WF_RESOURCES Environment Variable.
E-mail Notification Security
Each individual e-mail notification message sent by a notification mailer includes a line containing a notification ID (NID), access key, and node identifier, which are used to authenticate responses to the notification.
The NID identifies the notification in the database.
The notification access key is a distinct random key generated by the Notification System for each NID. The access key must be included in a response to the notification in order for a notification mailer to accept the response, thereby serving as a password that allows only users who actually received the notification containing the key to respond to that notification.
The node identifier specifies the notification mailer node to which the message belongs.
The format of the NID line is as follows:
NID[NID/access_key@node_identifier]
Responses by E-mail
When a user responds to a notification by e-mail, the response message must include the NID line from the original notification message. A notification mailer accepts the response only if the correct NID and access key combination is included in the response. Users can ensure that the response message contains the NID and access key either by including the entire original message when replying or by using a response template that includes the NID line.
Note: Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the NID line properly in a reply message. When responding to a notification, users should verify that the NID line is included in full and contains the prefix NID and all the details between the square brackets.
A user who receives an e-mail notification message may forward the message to another user through the e-mail application. When you configure a notification mailer, you can choose whether to allow a user to respond by e-mail to an e-mail notification that has been forwarded from another role.
If you deselect the Allow Forwarded Response configuration parameter, the notification mailer will check if the "From:" e-mail address of the notification response exactly matches the e-mail address of the recorded recipient role, or the e-mail address of a user in that role. If the two e-mail addresses match exactly, meaning the notification was not forwarded or was forwarded according to a valid vacation routing rule, the notification mailer treats the response as a valid response. If the two e-mail addresses do not match exactly, meaning the notification was simply forwarded using the e-mail Forward command, the notification mailer does not process the response and treats it as unsolicited mail.
If you select the Allow Forwarded Response configuration parameter, the notification mailer that receives the notification never checks the "From:" e-mail address of the notification response and always allows the response to be processed. In this case, users can delegate notifications to other users simply by forwarding the notification message through the e-mail application, and the new recipient of a forwarded notification automatically receives the authoritiy to respond to it.
Attention: Note that there are limitations when you deselect the Allow Forwarded Response parameter. For example, suppose a notification is sent to a distribution list mail alias that does not have a user/role relationship in the Oracle Workflow directory service. If any user from the distribution list responds to the notification, the notification mailer will always treat their notification response as unsolicited mail, because the "From:" e-mail address, which is an individual user's e-mail address, will never match the distribution list mail alias.
Responses through the Notification Detail Link Attachment
HTML-formatted e-mail notifications with attachments and plain text e-mail notifications with HTML attachments include an attachment called Notification Detail Link. When this link is clicked, it displays the notification in the Notification Details Web page. A user who receives a notification with a Notification Detail Link attachment can use this Web page to respond directly to the notification, instead of sending an e-mail response message to be processed by a notification mailer.
You can choose whether to require users to log in before they can access the Notification Details Web page for a notification through the Notification Detail Link.
For Oracle Applications:
By default, users must always log in before they can access the Notification Details page in Oracle Applications from the Notification Detail Link.
You can optionally enable guest access to the Notification Details page. Guest access lets users access this page from e-mail notifications without logging in to Oracle Applications with an individual user name and password. This feature is not recommended due to security considerations. However, if you choose to allow guest access, you can perform the following steps to enable it:
Set the WF: GUEST Access to Notification profile option to Enabled at the site level. See: Overview of Setting User Profiles, Oracle Applications System Administrator's Guide.
Create a grant assigning the "Workflow Guest User permission set" to the GUEST user. When defining the set for the grant, select the set type Navigation Menu and select the menu named "Workflow Guest User permission set" (internal code: WF_GUEST_GRANTS). After creating the grant, you must stop and restart Oracle HTTP Server for the change to take effect. See: Create Grant, Oracle Applications System Administrator's Guide.
In Oracle Applications Manager, stop and restart the service component container named Workflow Mailer Service. For more information, see the Oracle Applications Manager online help.
With guest access, if a user navigates to the Notification Details page and is not already logged in to Oracle Applications, the user is logged in automatically as the GUEST user. The user can then respond to the notification, and can also reassign the notification or request more information if those actions are available for that notification. However, the user cannot access any other notification in the Notification Details page, nor any other Oracle Workflow Web pages.
In cases where Oracle Workflow records the identity of the logged in user who acted on a notification, the action history will show those actions as being performed by the GUEST user.
When a user views a notification through guest access, Oracle Workflow displays the notification according to the language and territory preferences of the recipient role for the notification and the date and number preferences of the GUEST user. To view notifications with their own preferences, users can log in with their own user names and passwords before accessing the notifications.
Oracle Workflow does not support guest access for notifications that require electronic signatures. If you want users to sign their notification responses with password-based signatures or certificate-based digital signatures, those users must log in with their own user names and passwords to enter their signatures.
Note: If you enabled guest access but no longer want to allow it, you can disable it by setting the WF: GUEST Access to Notification profile option to Disabled and setting an end date for the grant you created. Then stop and restart Oracle HTTP Server and, in Oracle Applications Manager, stop and restart the service component container named Workflow Mailer Service. Users will then always be required to log in before they can access the Notification Details page from the Notification Detail Link.
For standalone Oracle Workflow:
If you select the Send Access Key configuration parameter for a notification mailer, the notification mailer includes the notification access key in the Notification Detail Link attachment. The access key allows users to access the Notification Details Web page in standalone Oracle Workflow directly by clicking the Notification Detail Link, whether they are currently logged in or not. However, if users are not already logged in, they cannot access any other notifications except the notification with which the attachment was sent.
If you deselect the Send Access Key configuration parameter, the notification mailer does not include the access key in the Notification Detail Link. When users click the link without the access key, they are prompted to log in, if they have not already done so, before they can access the Notification Details Web page.
E-mail Notification Summaries
Instead of individual e-mail notifications, users can also receive e-mail summaries listing all their open notifications. Users can indicate that they want to receive e-mail summaries by choosing a notification preference of SUMMARY or, for Oracle Applications only, SUMHTML.
SUMMARY - Users receive plain text e-mail summary messages, which do not enable any direct response through e-mail to the notifications they list. Instead, to respond to the individual notifications in a summary, users must log in to Oracle Workflow and access the notifications through the Worklist Web page.
SUMHTML - Users receive HTML-formatted e-mail summary messages. An HTML-formatted summary does not enable responses through e-mail. However, it includes a link to the Worklist Web page as well as links to each notification in the Notification Details Web page, where users can respond to the individual notifications. Users must log in to Oracle Applications before they can access the Worklist and Notification Details pages, unless you enable guest access to the Notification Details page. See: Responses Through the Notification Detail Link Attachment.
To send e-mail summaries, schedule a Launch Summary Notifications event for a notification mailer. For the seeded Workflow Notification Mailer, the Launch Summary Notifications event is scheduled to send e-mail summary notifications once a day by default.
Confirming Responses with Electronic Signatures
In Oracle Applications, you can require that the response to a notification be signed with either a password-based signature or a certificate-based digital signature. In this case, users cannot respond to that notification through e-mail. Instead, they must respond to the notification from the Notification Details Web page and enter the appropriate type of signature. To access the Notification Details page, users can either log into Oracle Applications separately, or, if their notification preference includes HTML attachments, use the Notification Detail Link.
Use the special message attribute #WF_SIG_POLICY to specify the signature policy for a notification. See: #WF_SIG_POLICY Attribute, Oracle Workflow Developer's Guide.
Excluding Notification Content From E-mail
If a particular notification contains sensitive information that you do not want to send in e-mail, you can choose to exclude the content of the notification from the e-mail version of the notification. In this case, users receive an e-mail message that only informs them that they must access the notification through the Notification Details Web page instead to view the content and respond. To access the Notification Details page, users can either log into Oracle Applications separately, or, if their notification preference includes HTML attachments, use the Notification Detail Link.
Use the special message attribute #WF_SECURITY_POLICY to specify the content security policy for a notification. See: #WF_SECURITY_POLICY Attribute, Oracle Workflow Developer's Guide.
Sending Outbound E-mail Notifications Only
If you do not want to allow responses by e-mail, you can choose to send only outbound e-mail notifications. To configure your notification mailers for outbound-only processing, set the inbound thread count to 0 (zero) in the configuration wizard for each notification mailer.
When you set up an outbound-only mailer, you should configure the mailer to use message templates for response-required notifications that do not request a response by e-mail, but instead direct recipients to respond from the Notification Details Web page. For example, you can configure the mailer to send response-required notifications using the Workflow View From UI message template, which is an alternative template provided by Oracle Workflow in the System: Mailer item type, or create your own custom message templates. The outbound-only mailer can still use the standard message templates to send outbound summary notifications or For Your Information (FYI) notifications that do not require a response.
Disabling E-mail Notifications
Ultimately, the security of e-mail notifications depends on the security of your e-mail application. If you do not want to send any workflow information by e-mail, you can choose not to run any notification mailers at all. In this case users must always log on to Oracle Workflow and access the Worklist Web page to view and respond to their notifications.
See: Overview of Notification Handling, Oracle Workflow User's Guide.
Handling Mailer Errors
To check the status of a particular notification or help investigate errors, you can run a script named wfmlrdbg.sql that displays debugging information. In Oracle Applications, you can also obtain this information by running a diagnostic test through Oracle Diagnostics. See: wfmlrdbg.sql and Oracle Workflow Diagnostic Tests.
Additionally, in Oracle Applications you can run diagnostic tests through Oracle Diagnostics to check that at least one notification mailer is configured, to validate the notification mailer configuration parameters, and to check that all users with a notification preference to receive e-mail have an e-mail address defined. See: Oracle Workflow Diagnostic Tests.
Note: In Oracle Applications, you must particularly check the notification preference and e-mail address for the SYSADMIN user. This user is the default recipient for several types of notifications such as error notifications. By default, the SYSADMIN user has a notification preference to receive e-mail notifications. To enable Oracle Workflow to send e-mail to this user, navigate to the Users window in Oracle Applications and assign SYSADMIN an e-mail address that is fully qualified with a valid domain. However, if you want to access notifications only through the Oracle Workflow Worklist Web page, then you should change the notification preference for SYSADMIN to "Do not send me mail" in the Preferences page. In this case you do not need to define an e-mail address. See: System Administration Setup Tasks, Oracle Applications System Administrator's Guide.
The Generic Service Component Framework lets you control how errors are handled through the component-level Max Error Count parameter and the container-level SVC_COMP_MAX_ERROR_COUNT parameter.
The Max Error Count (PROCESSOR_MAX_ERROR_COUNT) parameter for a service component determines how many consecutive errors the component can encounter before its container stops it and changes its status to Stopped with Error. If the component's startup mode is Automatic or On-Demand, the container will then restart the component. The default value for this parameter is 10.
The SVC_COMP_MAX_ERROR_COUNT parameter for a container determines how many times a component within that container can be stopped with error. If this maximum count is reached, the container changes the status of the component to System Deactivated and will no longer automatically restart it. The default value for this parameter is 5.
The total number of errors before a mailer is permanently stopped consists of the Max Error Count value multiplied by the SVC_COMP_MAX_ERROR_COUNT value. For example, using the default values, a mailer can encounter 10 * 5 = 50 errors before it becomes System Deactivated.
If a mailer encounters multiple consecutive errors, it may be advantageous to let the container restart the mailer. Restarting causes the mailer to establish new connections and instantiate new objects, which may resolve the errors. Consequently, if you want to allow more errors before you must manually intervene to restart the mailer, it is usually better to increase the SVC_COMP_MAX_ERROR_COUNT value than the Max Error Count value.
For more information about configuring service component and container parameters, please refer to the Oracle Workflow Manager online help.
In case of a large number of errored notifications, Oracle Workflow provides special scripts for mass mailer reprocessing. Do not run these scripts unless you are directed to do so by Oracle Support.
The following scripts are located in the $FND_TOP/patch/115/sql directory for Oracle Applications, or in the ORACLE_HOME/wf/admin/sql directory for standalone Oracle Workflow.
wfntfqup.sql - This script rebuilds the WF_NOTIFICATION_OUT queue. It drops and recreates the WF_NOTIFICATION_OUT queue, removes pending notification messages from the WF_DEFERRED queue, and repopulates the WF_NOTIFICATION_OUT queue from the Oracle Workflow Notification System tables.
You must stop the service component containers for notification mailers and agent listeners before you run this script, and restart the containers after the script completes. The container for notification mailers is named Workflow Mailer Service in Oracle Applications or WFMLRSVC in standalone Oracle Workflow. The container for agent listeners is named Workflow Agent Listener Service in Oracle Applications or WFALSNRSVC in standalone Oracle Workflow.
Use the script as follows:
sqlplus <user/pwd> @wfntfqup <APPSuser> <APPSpwd> <FND_schema>
Replace <APPSuser> and <APPSpwd> with the user name and password for the APPS user in Oracle Applications, or the ORACLE user name and password for Oracle Workflow in standalone Oracle Workflow. The user name is usually apps in Oracle Applications or owf_mgr in standalone Oracle Workflow. Replace <FND_schema> with the ORACLE username that connects to Oracle Application Object Library data in Oracle Applications, usually applsys, or the ORACLE username for Oracle Workflow in standalone Oracle Workflow, usually owf_mgr.
wfnequ.sql - This script moves all the oracle.apps.wf.notification.send event messages that are on the WF_ERROR queue back to the WF_DEFERRED queue for reprocessing.
Use the script as follows:
sqlplus <user/pwd> @wfnequ <APPSuser> <APPSpwd> <FND_schema>
Replace <APPSuser> and <APPSpwd> with the user name and password for the APPS user in Oracle Applications, or the ORACLE user name and password for Oracle Workflow in standalone Oracle Workflow. The user name is usually apps in Oracle Applications or owf_mgr in standalone Oracle Workflow. Replace <FND_schema> with the ORACLE username that connects to Oracle Application Object Library data in Oracle Applications, usually applsys, or the ORACLE username for Oracle Workflow in standalone Oracle Workflow, usually owf_mgr.
The following scripts are located in the $FND_TOP/patch/115/sql directory for Oracle Applications, or in the ORACLE_HOME/wf/sql directory for standalone Oracle Workflow.
wfntffix.sql - This script updates the MAIL_STATUS to NULL for notifications that are ineligible to be sent by e-mail. Notifications become ineligible if the recipient role does not have a valid e-mail address defined, or if the recipient role has a notification preference set not to receive e-mail. Running this script removes ineligible notifications from the notification mailer throughput displayed in Oracle Workflow Manager, so you can review the outstanding eligible notifications only.
Use the script as follows:
sqlplus <user/pwd> @wfntffix
wfntfsnd.sql - This script updates the MAIL_STATUS from null to MAIL for notifications of the specified item type that were sent on or after the specified date. The recipient role of each notification must have a valid e-mail address defined. Then the script enqueues those notifications on the WF_DEFERRED queue for reprocessing by the mailer.
For example, if users change their notification preference from not receiving e-mail to receiving e-mail, run this script to send any existing open notifications to those users by e-mail.
Use the script as follows:
sqlplus <user/pwd> @wfntfsnd <item_type> <begin_date_after>
Replace <item_type> with the internal name of the item type for the notifications to update. Replace <begin_date_after> with the earliest sent date for the notifications to update.
In Oracle Applications, Oracle Workflow also provides concurrent programs that help enable mass reprocessing of notifications. See: Running Reports and Programs, Oracle Applications User's Guide.
Resend Failed Workflow Notifications (FNDWF_NTF_RESEND) - This program lets you resend e-mail notifications with a mail status of FAILED after correcting the issues that prevented the e-mails from being sent. For example, a notification might have a mail status of FAILED if the e-mail address for the recipient was specified in an incorrect format and the e-mail could not be delivered. Use Standard Request Submission to run this program. Specify the recipient role whose notifications you want to resend, or leave this parameter blank to resend notifications to all recipient roles. The program then re-enqueues the notifications on the notification mailer's outbound queue to be sent by e-mail.
Note: Run the Resend Failed Workflow Notifications program only after taking action to correct the issues that prevented the e-mails from being sent. Do not schedule the program to run repeatedly without investigating the e-mail issues; otherwise the notifications may fail again due to the same issues.
Move Messages from Exception to Normal Queue of Workflow Agent (FNDWF_MOVE_MSGS_EXCEP2NORMAL) - This program lets you transfer messages from an Oracle Streams Advanced Queuing (AQ) exception queue back to the associated normal queue, for queues that are assigned to an inbound agent. AQ transfers messages to an exception queue if an agent listener repeatedly encounters exceptions when attempting to dequeue messages, or if messages expire before being dequeued. To aid in mass mailer reprocessing, you can run the concurrent program for the WF_DEFERRED agent or WF_NOTIFICATION_IN agent if necessary. You can then run the appropriate agent listener to reattempt processing for the messages that have been transferred back to the agent's normal queue. See: Exception Handling for Inbound Queues.
Notification mailers use message templates defined in Oracle Workflow Builder to generate e-mail notifications. Oracle Workflow provides a set of standard templates which are used by default, as well as some alternative templates for certain types of messages. These message templates are defined in the System: Mailer item type.
Although message templates are defined as messages in Oracle Workflow Builder, they are not true messages. Rather, they serve as outlines for e-mail messages sent by notification mailers. Message templates determine the basic format of an e-mail notification, including what header information to include, and whether and where to include details such as the message due date and priority. Message templates for notifications that require a response should also describe the syntax the reply should follow and list the information needed to confirm the notification.
It is not recommended to modify the standard templates. However, you can optionally customize the message templates used to send your e-mail notifications by either using the alternative templates provided in the System: Mailer item type by Oracle Workflow, or creating your own custom message templates in the System: Mailer item type using the Workflow Builder. You can implement alternative standard or custom templates in the following ways:
Assign the templates you want to a particular notification mailer service component in the mailer configuration parameters. The templates assigned to a mailer override the default System: Mailer templates. See the Oracle Applications Manager online help or the Oracle Enterprise Manager online help.
Assign the templates you want to a particular notification in a workflow process by defining special message attributes. In this case the templates assigned to the notification override both the templates assigned to a mailer and the default System: Mailer templates. See: Notification Mailer Message Template Attributes, Oracle Workflow Developer's Guide.
The templates in the System: Mailer item type have message attributes that represent every part of the notification message. Within the body of a template, the message attributes are token substituted to insert the specific information for a particular instance of a notification into the message outline.
Note: Do not modify, add new attributes to, or delete existing attributes from the standard message templates in the System: Mailer item type.
If you create new custom templates, you must name the message attributes for these templates with the same names as the message attributes for the standard templates. A notification mailer can only token substitute the attributes in the message body if you use the standard attribute names.
You can optionally omit some of the standard tokens from your custom templates, if you do not want to send the information they represent. However, you should not omit the tokens that represent the key information to be conveyed in the notification. For example, if you define a custom version of a template that includes the &BODY token, you must include the &BODY token in the custom template as well, in order to include the body text of the particular notification that is being sent into the template outline.
If you add a new token in a custom template, you must set up the necessary substitution yourself. By default, a notification mailer only performs token substitution for the standard tokens that are listed for the default templates.
Oracle Workflow provides the following message templates.
Note: In addition to the message templates listed here, the System: Mailer item type also includes some other messages which are not currently used.
Workflow Open Mail (More Information Request for Outlook Express) Message
Workflow Invalid Open Mail (More Information Request) Message
See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide.
Workflow Open Mail (Templated) Message
If you use the templated response method, the Notification System uses the Workflow Open Mail (Templated) message as a default template for e-mail notifications that require a response. The notification template includes generic instructions on how to respond to a notification. It also includes the date that a response is due and any history of actions on the notification.
Note: The templated response method is the default response method for Oracle Workflow. Notification mailers use the templated response method unless you have manually set the internal mailer parameter named DIRECT_RESPONSE to Y. See: Setting Up Notification Mailers.
The response instructions in the plain text message body describe how to reply manually using the templated response method. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
The Workflow Open Mail (Templated) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
You can customize the boilerplate text that appears in the body of the Workflow Open Mail (Templated) message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
____________Start of Response Template____________
Response Template for &NOTIFICATION
To submit your response, reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your response value between the quotes following each response prompt.
&RESPONSE
____________End of Response Template_____________
Notification Details:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE>
<STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
-->
</STYLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P>&BODY
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.
<P>&MAILTO
</SPAN>
<P>&HISTORY
</BODY>
</HTML> Orig. Workflow Open Mail (Templated) Message
Oracle Workflow provides the Orig. Workflow Open Mail (Templated) message as an alternative template that you can optionally use as a template for e-mail notifications that require a response if you use the templated response method. This template does not include the header attributes that are displayed in the Workflow Open Mail (Templated) message.
The Orig. Workflow Open Mail (Templated) notification template includes generic instructions on how to respond to a notification. It also includes the following information about a message: the name of the sender of the message, message priority, date that a response is due, and any comments from the sender or, if the notification is forwarded from another user, any comments from the forwarder.
Note: The templated response method is the default response method for Oracle Workflow. Notification mailers use the templated response method unless you have manually set the internal mailer parameter named DIRECT_RESPONSE to Y. See: Setting Up Notification Mailers.
The response instructions in the plain text message body describe how to reply manually using the templated response method. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
The Orig. Workflow Open Mail (Templated) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
From: &SENDER
&COMMENT
____________Start of Response Template____________
Response Template for &NOTIFICATION
To submit your response, reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your response value between the quotes following each response prompt.
&RESPONSE
____________End of Response Template_____________
Notification Details:
&BODY
Due Date: &DUE_DATE
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P>
<P>From: <B>&SENDER</B>
<P><B><FONT SIZE=+1>&COMMENT</FONT> </B>
<P>&BODY
<P><B>Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.</B>
<P>&MAILTO
</BODY>
</HTML> Workflow Open Mail (Direct) Message
If you select the direct response method, the Notification System uses the Workflow Open Mail (Direct) message as a default template for e-mail notifications that require a response. The notification template includes generic instructions on how to respond to a notification. It also includes the date that a response is due and any history of actions on the notification.
Note: To select the direct response method for a notification mailer, you must manually set the internal mailer parameter named DIRECT_RESPONSE to Y. See: Setting Up Notification Mailers.
The response instructions in the plain text message body describe how to reply using the direct response method. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: Responses that are generated automatically from an HTML-formatted notification or attachment always use a response template, regardless of which response method you select.
The Workflow Open Mail (Direct) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
You can customize the boilerplate text that appears in the body of the Workflow Open Mail (Direct) message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
____________________________________________________
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:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P>&BODY
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.
<P>&MAILTO </SPAN>
<P>&HISTORY
</BODY>
</HTML>
Orig. Workflow Open Mail (Direct) Message
Oracle Workflow provides the Orig. Workflow Open Mail (Direct) message as an alternative template that you can optionally use as a template for e-mail notifications that require a response if you select the direct response method. This template does not include the header attributes that are displayed in the Workflow Open Mail (Direct) message.
The Orig. Workflow Open Mail (Direct) notification template includes generic instructions on how to respond to a notification. It also includes the following information about a message: the name of the sender of the message, message priority, date that a response is due, and any comments from the sender of the message or, if the notification is forwarded from another user, any comments from the forwarder.
Note: To select the direct response method for a notification mailer, you must manually set the internal mailer parameter named DIRECT_RESPONSE to Y. See: Setting Up Notification Mailers.
The response instructions in the plain text message body describe how to reply using the direct response method. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: Responses that are generated automatically from an HTML-formatted notification or attachment always use a response template, regardless of which response method you select.
The Orig. Workflow Open Mail (Direct) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
From: &SENDER
&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
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P>
<P>From: <B>&SENDER</B>
<P><B><FONT SIZE=+1>&COMMENT</FONT> </B>
<P>&BODY
<P><B>Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.</B>
<P>&MAILTO
</BODY>
</HTML>
Workflow Open Mail for Outlook Express Message
If you use an e-mail application such as Microsoft Outlook Express as your e-mail client, you should select the standard Workflow Open Mail for Outlook Express message as a template for e-mail notifications that require a response, for users with a notification preference of MAILHTML, MAILHTM2, or MAILATTH. This message includes a link to the Notification Details Web page to let users respond to the notification there. This template is provided to accommodate e-mail applications that cannot process the response links included in the Workflow Open Mail (Templated) and Workflow Open Mail (Direct) templates.
Note: If you select the Workflow Open Mail for Outlook Express message template for a notification mailer, then you should also select the Workflow Open Mail (More Information Request for Outlook Express) message template for that notification mailer. See: Workflow Open Mail (More Information Request for Outlook Express) Message.
The response instructions in the plain text message body describe how to reply manually using the templated response method. This message is used for notifications sent to performers with a notification preference of MAILATTH. The HTML-formatted message body includes a link called "Click here to respond" which lets users access the notification in the Notification Details Web page to respond to the notification. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: When users choose the "Click here to respond" link, it automatically attempts to establish a Web session with the Web server. Users must be able to connect to the Web server to use this link to respond to a notification. Users must log in to Oracle Workflow to access the Notification Details page, unless you enable guest access in Oracle Applications. See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide and Responses Through the Notification Detail Link Attachment.
The Workflow Open Mail for Outlook Express message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
You can customize the boilerplate text that appears in the body of the Workflow Open Mail for Outlook Express message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
--------- Start of Response Template ------------
Response Template for &NOTIFICATION
To submit your response, reply to this message including this response template in your reply. Insert your response value between the quotes following each response prompt.
&RESPONSE
----------- End of Response Template ------------
Notification Details:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> <STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
-->
</STYLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P>&BODY
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">&CLICK_HERE_RESPONSE </SPAN>
<P>&HISTORY
</BODY>
</HTML>
Orig. Workflow Open Mail for Outlook Express Message
Oracle Workflow provides the Orig. Workflow Open Mail for Outlook Express message as an alternative template that you can optionally use as a template for e-mail notifications that require a response if you use an e-mail application such as Microsoft Outlook Express as your e-mail client. This template does not include the header attributes that are displayed in the Workflow Open Mail for Outlook Express message.
The Orig. Workflow Open Mail for Outlook Express message includes the name of the sender of the message, any comments from the sender or forwarder, and a link to the Notification Details Web page to let users respond to the notification there. This template can be used to accommodate e-mail applications that cannot process the response links included in the Orig. Workflow Open Mail (Templated) and Orig. Workflow Open Mail (Direct) templates.
Note: If you select the Orig. Workflow Open Mail for Outlook Express message template for a notification mailer, then you should also select the Workflow Open Mail (More Information Request for Outlook Express) message template for that notification mailer. See: Workflow Open Mail (More Information Request for Outlook Express) Message.
The response instructions in the plain text message body describe how to reply manually using the templated response method. This message is used for notifications sent to performers with a notification preference of MAILATTH. The HTML-formatted message body includes a link called "Click here to respond" which lets users access the notification in the Notification Details Web page to respond to the notification. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: When users choose the "Click here to respond" link, it automatically attempts to establish a Web session with the Web server. Users must be able to connect to the Web server to use this link to respond to a notification. Users must log in to Oracle Workflow to access the Notification Details page, unless you enable guest access in Oracle Applications. See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide and Responses Through the Notification Detail Link Attachment.
The Orig. Workflow Open Mail for Outlook Express message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
From: &SENDER
&COMMENT
---------- Start of Response Template --------------
Response Template for &NOTIFICATION
To submit your response, reply to this message including this response template in your reply. Insert your response value between the quotes following each response prompt.
&RESPONSE
----------- End of Response Template ---------------
Notification Details:
&BODY
Due Date: &DUE_DATE
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P>
<P>From: <B>&SENDER</B>
<P><B><FONT SIZE=+1>&COMMENT</FONT> </B>
<P>&BODY
<P>&CLICK_HERE_RESPONSE
</BODY>
</HTML>
Workflow Open FYI Mail Message
The Notification System uses the Workflow Open FYI Mail message as a default 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 history of actions on the notification.
The Workflow Open FYI Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| 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. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. This attribute is not currently used. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
| HISTORY | The history of actions on the notification. |
You can customize the text that appears in the body of the Workflow Open FYI Mail template, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent. The boilerplate text for the plain text message body is as follows:
Oracle Workflow Notification (FYI)
&TIMEZONE
_____________________________________________________
&HEADER
&BODY
&HISTORY
The boilerplate text for the HTML-formatted message body is as follows:
<HTML><HEAD><TITLE>Oracle Workflow Notification (FYI)</TITLE><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
-->
</STYLE></HEAD>
<BODY BGCOLOR="#FFFFFF">
<SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P>&BODY
<P>&HISTORY
</BODY>
</HTML>
Orig. Workflow Open FYI Mail Message
Oracle Workflow provides the Orig. Workflow Open FYI Mail message as an alternative template that you can optionally use as a template for e-mail notifications that do not require a response. This template does not include the header attributes that are displayed in the Workflow Open FYI Mail message.
The Orig. Workflow Open FYI Mail 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 the name of the sender of the message and any comments from the sender or forwarder.
The Orig. Workflow Open FYI Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| 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. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. |
The boilerplate text for the plain text message body is as follows:
Oracle Workflow Notification (FYI)
From: &SENDER
&COMMENT
_____________________________________________________
&BODY
The boilerplate text for the HTML-formatted message body is as follows:
<HTML><HEAD></HEAD>
<BODY BGCOLOR="#FFFFFF"><b>Oracle Workflow Notification (FYI)</b>
<br>
From: <B>&SENDER</B>
<br>&COMMENT
<hr>
<P>&BODY
</BODY>
</HTML>
Workflow View From UI Message
Oracle Workflow provides the Workflow View From UI message as an alternative template that you can optionally use for open response-required notifications whose content you do not want to send in e-mail. An e-mail message generated from this template will still include the header attributes for the notification, as well as any history of actions on the notification. However, the e-mail message will exclude the message body for the notification and will not enable responses through e-mail. Users can only view and respond to such notifications through the Notification Details Web page.
The notification template informs the recipient that the notification is best viewed from the Web page and directs the recipient to access the online version of the notification.
The Workflow View From UI message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| 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. |
| 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. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. This attribute is not currently used. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| HISTORY | The history of actions on the notification. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
You can customize the boilerplate text that appears in the body of the Workflow View From UI message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
Notification Details:
&HEADER
This notification is best viewed from the Notification Detail page.
Please access the online version of this notification.
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> <STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">This notification is best viewed from the Notification Detail page.<BR> Please access the online version of this notification.
</SPAN>
<P>&HISTORY
</BODY>
</HTML>
Workflow View FYI From UI Message
Oracle Workflow provides the Workflow View FYI From UI message as an alternative template that you can optionally use for open FYI notifications whose content you do not want to send in e-mail. An e-mail message generated from this template will still include the header attributes for the notification, as well as any history of actions on the notification. However, the e-mail message will exclude the message body for the notification. Users can only view such notifications through the Notification Details Web page.
The notification template informs the recipient that the notification is best viewed from the Web page and directs the recipient to access the online version of the notification.
The Workflow View FYI From UI message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| 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. |
| 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. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. This attribute is not currently used. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| HISTORY | The history of actions on the notification. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
You can customize the boilerplate text that appears in the body of the Workflow View FYI From UI message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
Notification Details:
&HEADER
This notification is best viewed from the Notification Detail page.
Please access the online version of this notification.
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> <STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">This notification is best viewed from the Notification Detail page.<BR> Please access the online version of this notification.
</SPAN>
<P>&HISTORY
</BODY>
</HTML>
Workflow URL Attachment Message
The Notification System uses the Workflow URL Attachment message as a default template to create the Notification References attachment for HTML-formatted notification messages that include URL attributes with Attach Content checked. The template includes a list with links to each URL.
Note: The Workflow URL Attachment message template is used only for notifications that do not include embedded Oracle Applications Framework regions. For a notification that includes an embedded region, Oracle Workflow includes the Related Applications region in the e-mail message, instead of appending the Notification References attachment.
The Workflow URL Attachment message has the following message attribute. The value is drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| URLLIST | The list of URLs to be included in the attachment. |
You can customize the text that appears in the body of the Workflow URL Attachment template, where an attribute preceded by an ampersand (&) is token substituted with a runtime value when the notification is sent. The boilerplate text for the HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification References </TITLE>
<STYLE> <!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><h1 style="color:#336699;font-family:Arial,Helvetica,Geneva,sans-serif;font-size:13pt;margin-bottom:0px;font-weight:bold"> Notification References</H1>
<HR WIDTH="100%">
<BR>
&URLLIST
<BR>
<HR WIDTH="100%">
<BR>
</BODY>
</HTML>
Workflow Canceled Mail Message
The default Workflow Canceled Mail message informs the recipient that a previously sent notification is canceled. If you are using the version of Oracle Workflow embedded in Oracle Applications, you can use the WF: Mailer Cancellation Email profile option to determine whether or not notification mailers should send Workflow Canceled Mail messages. See: Setting Up Notification Mailers.
The Workflow Canceled Mail message has the following message attributes, with values that are drawn from the message definition associated with the canceled notification activity:
| Variable | Description |
|---|---|
| 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. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
The boilerplate text for the plain text message body is as follows:
&TIMEZONE
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.
_____________________________________________________
&HEADER
&BODY
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
-->
<P></STYLE></Head>
<body><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">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.
<hr>
&HEADER
<P>&BODY</SPAN>
</body></html>
Orig. Workflow Canceled Mail Message
Oracle Workflow provides the Orig. Workflow Canceled Mail message as an alternative template that you can optionally use to inform the recipient that a previously sent notification is canceled. This template does not include the header attributes that are displayed in the Workflow Canceled Mail message.
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can use the WF: Mailer Cancellation Email profile option to determine whether or not notification mailers should send cancellation messages. See: Setting Up Notification Mailers.
The Orig. Workflow Canceled Mail message has the following message attributes, with values that are drawn from the message definition associated with the canceled notification activity:
| Variable | Description |
|---|---|
| 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 boilerplate text for the plain text message body is as follows:
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
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head></Head><body>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.
<hr>
&BODY
</body></html>
Workflow Invalid Mail Message
The Workflow Invalid Mail message is sent to a user by default when a user responds incorrectly to a notification. For example, if a response message from a user contains a valid notification ID (NID) line matching it with a notification, but does not contain any response value or contains an invalid response value, the notification mailer sends a Workflow Invalid Mail message to the user. This message describes how to respond to the notification correctly. The message attributes are as follows:
The boilerplate text for the plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
Important: Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
Error Message: &MAIL_ERROR_MESSAGE
Value Found: &MAIL_VALUE_FOUND
Remarks: &MAIL_EXP_VALUES
_____________________________________________________
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:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></Head>
<body><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<p><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
<P>Error Message: &MAIL_ERROR_MESSAGE
<BR>
<BR>Value Found: &MAIL_VALUE_FOUND
<BR>
<BR>Remarks: &MAIL_EXP_VALUES
<HR>
<P>&HEADER
<P>&BODY
<P><B>Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.</B>
<P><B>Important:</B> Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
<P>&MAILTO</SPAN>
<P>&HISTORY
</BODY>
</HTML>
Orig. Workflow Invalid Mail Message
Oracle Workflow provides the Orig. Workflow Invalid Mail message as an alternative template that you can optionally use when a user responds incorrectly to a notification. This template does not include the header attributes that are displayed in the Workflow Invalid Mail message.
The Orig. Workflow Invalid Mail message describes how to respond to the notification correctly. The message attributes are as follows:
The boilerplate text for the plain text message body is as follows:
Oracle Workflow Notification
&COMMENT
Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
Important: Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
Error Message: &MAIL_ERROR_MESSAGE
Value Found: &MAIL_VALUE_FOUND
Remarks: &MAIL_EXP_VALUES
--------------------------------------------------
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
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head></Head><body>Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
<P>Error Message: &MAIL_ERROR_MESSAGE
<BR>
<BR>Value Found: &MAIL_VALUE_FOUND
<BR>
<BR>Remarks: &MAIL_EXP_VALUES
<HR><P><B><FONT SIZE=+1>&COMMENT</FONT> </B>
<P>&BODY
<P><B>Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.</B>
<P><B>Important:</B> Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
<P>&MAILTO
</BODY>
</HTML>
Workflow Closed Mail Message
The default 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:
| Variable | Description |
|---|---|
| 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. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
The boilerplate text for the plain text message body is as follows:
&TIMEZONE
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.
--------------------------------------------
&HEADER
&BODY
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
-->
<P></STYLE></Head>
<body><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">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.
<hr>
&HEADER
<P>&BODY</SPAN>
</body></html>
Orig. Workflow Closed Mail Message
Oracle Workflow provides the Orig. Workflow Closed Mail message as an alternative template that you can optionally use to inform the recipient that a previously sent notification is now closed. This template does not include the header attributes that are displayed in the Workflow Closed Mail message.
The Orig. Workflow Closed Mail message has the following message attributes, with values that are drawn from the message definition associated with the closed notification activity:
| Variable | Description |
|---|---|
| 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 boilerplate text for the plain text message body is as follows:
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
The boilerplate text for the HTML-formatted message body is as follows:
<html><Head></Head><body>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.
<hr>
&BODY
</body></html>
Workflow Summary Mail Message
In standalone Oracle Workflow, the Notification System uses the Workflow Summary Mail message by default 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:
Note: In Oracle Applications, the Notification System uses the Workflow Summary Mail (HTML) message as the template for summary notifications. See: Workflow Summary Mail (HTML) Message.
| Variable | Description |
|---|---|
| SUMMARY | Summary report. |
| USER_NAME | The user/role the notification summary is sent to; the performer. |
| SYSDATE | The current date. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
The boilerplate text for the plain text message body is as follows:
Summary of Notifications for '&USER_NAME'
(Please use the Notifications web page to see details or respond.)
&TIMEZONE
------------------------------------------------------------
&SUMMARY
The HTML-formatted message body is not used for this template.
Workflow Summary Mail (HTML) Message
In Oracle Applications, the Notification System uses the Workflow Summary Mail (HTML) message by default as a template to send a summary of workflow notifications to users and roles that have their notification preference set to SUMMARY or SUMHTML in the Oracle Workflow directory service. The Workflow Summary Mail (HTML) message summarizes all currently open notifications for a given user/role. The HTML-formatted message body also provides a link to the Worklist Web page as well as links to each notification in the Notification Details Web page.
Note: The SUMHTML notification preference is currently supported only for the version of Oracle Workflow embedded in Oracle Applications.
Note: In standalone Oracle Workflow, the Notification System uses the Workflow Summary Mail message as the template for summary notifications. See: Workflow Summary Mail Message.
The Workflow Summary Mail (HTML) message has the following message attributes, with values that are drawn from the message definition associated with the open notification activity:
| Variable | Description |
|---|---|
| SUMMARY | Summary report. |
| USER_NAME | The user/role the notification summary is sent to; the performer. |
| SYSDATE | The current date. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
The plain text message body is used for notifications sent to performers with a notification preference of SUMMARY. The boilerplate text for the plain text message body is as follows:
&TIMEZONE
&SUMMARY
The HTML-formatted message body is used for notifications sent to performers with a notification preference of SUMHTML. The boilerplate text for the HTML-formatted message body is as follows:
<HTML><HEAD>
<STYLE>
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
</STYLE>
<TITLE>Summary Notification</TITLE></HEAD><BODY>
<SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&SUMMARY
</BODY>
</HTML>
Workflow Warning Mail Message
The Notification System uses the Workflow Warning Mail message as a default template to send a message to a user the first time it receives unsolicited mail from that user. For example, if a message from a user does not contain a notification ID (NID) line matching it with a notification, or contains an incorrectly formatted NID line, the notification mailer sends a Workflow Warning Mail message to the user. This message has the following message attributes, with values that are drawn from the unsolicited mail:
| Variable | Description |
|---|---|
| UBODY | The text of the unsolicited mail message body. |
| USUBJECT | The text of the unsolicited mail subject line. |
| UFROM | The address of the user that sent the unsolicited mail. |
The boilerplate text for the plain text message body is as follows:
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.
Important: Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
------------------------------------------------------------
From: &UFROM
Subject: &USUBJECT
&UBODY
The boilerplate text for the HTML-formatted message body is as follows:
<html><head></head><body>
<SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000"><B>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 auto-generated reply created when responding to the original message. This contains the 'NID' line which is necessary for identification. If you are not responding to a notification, please do not send mail to this account.
<P><B>Important:</B> Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
<hr>
<P>From: &UFROM
<BR>Subject: &USUBJECT</SPAN>
<P>&UBODY
</body></html>
Workflow Signature Required Mail Message
The Notification System uses the Workflow Signature Required Mail message as a default template for e-mail notifications that require an electronic signature in the user's response. Users can only respond to such notifications through the Notification Details Web page, where they can enter either a password-based signature or a certificate-based digital signature, depending on the notification's requirements, to sign the response. The notification template informs the recipient that a signature is required and that the response cannot be submitted through e-mail. Instead, the notification template directs the recipient to access the online version of the notification to submit a reponse.
Note: Electronic signatures are currently supported only for the version of Oracle Workflow embedded in Oracle Applications.
The Workflow Signature Required Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| DUE_DATE | The date by which a response is required, specified in the notification activity. |
| BODY | The text of the body defined in the message. |
| NOTIFICATION | Required notification code used to identify the information in the notification. For notifications that require an electronic signature to be entered online, this notification code does not include the access key or node identifier information that would be needed for an e-mail response. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. This attribute is not currently used. |
| SUBJECT | The subject line defined in the message. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| HISTORY | The history of actions on the notification. |
| COMMENT | Comments added by the sender or the forwarder. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
You can customize the boilerplate text that appears in the body of the Workflow Signature Required Mail message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
&HEADER
This notification requires a signature in your response. You cannot respond to this notification through e-mail. Please access the online version of the notification to submit your response.
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> <STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P>&HEADER
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000"><B>This notification requires a signature in your response. You cannot respond to this notification through e-mail. Please access the online version of the notification to submit your response.</B></SPAN>
<P>&HISTORY
</BODY>
</HTML>
See: #WF_SIG_POLICY Attribute, Oracle Workflow Developer's Guide.
Workflow Signature Warning Mail Message
The Workflow Signature Warning Mail message is sent to a user by default if that user sends an e-mail response containing the notification ID (NID) line of a notification that requires an electronic signature. A valid response to such a notification can only be submitted through the Notification Details Web page. The notification template informs the recipient that a signature is required and that the response cannot be submitted through e-mail. Instead, the notification template directs the recipient to access the online version of the notification to submit a response.
Note: Electronic signatures are currently supported only for the version of Oracle Workflow embedded in Oracle Applications.
The Workflow Signature Warning Mail message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| SUBJECT | The subject line of the original message. |
| COMMENT | Comments added by the sender or the forwarder. |
| BODY | The text of the original message. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
You can customize the boilerplate text that appears in the body of the Workflow Signature Warning Mail message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
&COMMENT
Warning: You earlier received the notification shown below. This notification requires a signature in your response. You cannot respond to this notification through e-mail. Please access the online version of the notification to submit your response.
____________________________________________________________
&HEADER
&BODY
The boilerplate text for an HTML-formatted message body is as follows:
<html><Head><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></Head>
<body><P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Warning: You earlier received the notification shown below. This notification requires a signature in your response. You cannot respond to this notification through e-mail. Please access the online version of the notification to submit your response.</SPAN>
<hr>
<P><B><FONT SIZE=+1>&COMMENT</FONT> </B>
<P>&HEADER
<P>&HISTORY
<P>&BODY
</body></html>
See: #WF_SIG_POLICY Attribute, Oracle Workflow Developer's Guide.
Workflow Secure Mail Content Message
The Notification System uses the Workflow Secure Mail Content message as a default template for notifications that include sensitive content that cannot be sent in e-mail for security reasons. You can mark notifications as including secure content using the special #WF_SECURITY_POLICY message attribute. Users can only view and respond to such notifications through the Notification Details Web page. The notification template informs the recipient that the notification content cannot be sent in e-mail and directs the recipient to access the online version of the notification instead.
The Workflow Secure Mail Content message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| NOTIFICATION | Required notification code used to identify the information in the notification. |
| SUBJECT | The subject line defined in the message. |
You can customize the boilerplate text that appears in the body of the Workflow Secure Mail Content message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
____________________________________________________________
Notification &NOTIFICATION
This notification contains secure content which cannot be sent through e-mail. Please access the online version of the notification to see the details.
____________________________________________________________
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Notification: &NOTIFICATION
<br><br>
<B>This notification contains secure content which cannot be sent through e-mail. Please access the online version of the notification to see the details.</B></SPAN>
</BODY>
</HTML>
See: #WF_SECURITY_POLICY Attribute, Oracle Workflow Developer's Guide.
Workflow Open Mail (More Information Request) Message
The Notification System uses the Workflow Open Mail (More Information Request) message as a default template to send a request for more information about a notification from one user to another user. The notification template includes generic instructions on how to respond with the requested information. It also includes the following information about a message: the name of the sender of the message, any history of actions on the notification, and the date that a response is due.
The response instructions in the plain text message body describe how to reply manually. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
The Workflow Open Mail (More Information Request) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
You can customize the boilerplate text that appears in the body of the Workflow Open Mail (More Information Request) message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
_________________Start of Response Template_________________
More Information Template for &NOTIFICATION
User &SENDER has requested more information for the notification. Please reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your comments between the quotes against the prompt.
Question: &QUESTION
&RESPONSE
__________________End of Response Template__________________
Notification Details:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">
<P>Question: <B>&QUESTION</B>
<P><B>Please click on the following link to automatically generate an E-mail response for this question. Before sending the E-mail response, ensure desired comments within quotes.</B>
<P>&MAILTO
<P><B>Notification Detail:</B></SPAN>
<P>&HEADER
<P>&BODY
<BR>
<SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Question:
<B>&QUESTION</B>
<P><B>Please click on the following link to automatically generate an E-mail response for this question. Before sending the E-mail response, ensure desired comments within quotes.</B>
<P>&MAILTO </SPAN>
<P>&HISTORY
</BODY>
</HTML>
Orig. Workflow Open Mail (More Information Request) Message
Oracle Workflow provides the Orig. Workflow Open Mail (More Information Request) message as an alternative template that you can optionally use as a template to send a request for more information about a notification from one user to another user. This template does not include the header attributes that are displayed in the Workflow Open Mail (More Information Request) message.
The Orig. Workflow Open Mail (More Information Request) notification template includes generic instructions on how to respond with the requested information. It also includes the following information about a message: the name of the sender of the message, the date that a response is due, and any history of actions on the notification.
The response instructions in the plain text message body describe how to reply manually. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
The Orig. Workflow Open Mail (More Information Request) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
_________________Start of Response Template_________________
More Information Template for &NOTIFICATION
User &SENDER has requested more information for the notification. Please reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your comments between the quotes against the prompt.
Question: &QUESTION
&RESPONSE
__________________End of Response Template__________________
Notification Details:
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P>
<P>User &SENDER has requested more information for the following notification.
<P>&BODY
<P>Question: <B>&QUESTION</B>
<P><B>Please click on the following link to automatically generate an E-mail response for this question. Before sending the E-mail response, ensure desired comments within quotes.</B>
<P>&MAILTO
<P>&HISTORY
</BODY>
</HTML>
Workflow Open Mail (More Information Request for Outlook Express) Message
If you use an e-mail application such as Microsoft Outlook Express as your e-mail client, you should select the standard Workflow Open Mail (More Information Request for Outlook Express) message as a template for requests for more information about a notification from one user to another user, for users with a notification preference of MAILHTML, MAILHTM2, or MAILATTH. This message includes a link to the Notification Details Web page to let users respond to the request there. This template is provided to accommodate e-mail applications that cannot process the response links included in the Workflow Open Mail (More Information Request) template. In particular, if you select the Workflow Open Mail for Outlook Express message template for a notification mailer, then you should also select the Workflow Open Mail (More Information Request for Outlook Express) message template for that notification mailer. See: Workflow Open Mail for Outlook Express Message.
Note: To select the Workflow Open Mail (More Information Request for Outlook Express) message template for a notification mailer, you must manually set the internal mailer parameter named OPEN_MORE_INFO to the value OPEN_MORE_INFO_OUTLOOK. See: Setting Up Notification Mailers.
The response instructions in the plain text message body describe how to reply manually using the templated response method. This message is used for notifications sent to performers with a notification preference of MAILATTH. The HTML-formatted message body includes a link called "Click here to respond" which lets users access the notification in the Notification Details Web page to respond to the request for information. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: When users choose the "Click here to respond" link, it automatically attempts to establish a Web session with the Web server. Users must be able to connect to the Web server to use this link to respond to a notification. See: Reviewing Notifications via Electronic Mail, Oracle Workflow User's Guide.
The Workflow Open Mail (More Information Request for Outlook Express) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
| Variable | Description |
|---|---|
| DUE_DATE | The date by which a response is required, specified in the notification activity. |
| BODY | The text of the body defined in the message. |
| SUBJECT | The subject line defined in the message. |
| COMMENT | Comments added by the sender or the forwarder. |
| SENDER | The name of the sender of the message, as displayed in the From column in the Worklist. |
| HISTORY | The history of actions on the notification. |
| QUESTION | Details about what information is being requested. |
| RESPONSE | The user response section. |
| NOTIFICATION | Required notification code used to identify the information in the notification. |
| HEADER | Standard header attributes and any custom header attributes defined to hold key information for the message. See: Header Attributes, Oracle Workflow Developer's Guide. |
| TIMEZONE | The time zone of the dates and times displayed in the notification, based on the time zone of the server from which the notification was sent. This attribute is not currently used. |
| CLICK_HERE_RESPONSE | The content of the HTML tag that a recipient would click on to access the Notification Details page to respond to a request for more information. This attribute is used only for HTML e-mail notifications. |
You can customize the boilerplate text that appears in the body of the Workflow Open Mail (More Information Request for Outlook Express) message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
&TIMEZONE
_________________Start of Response Template_________________
More Information Template for &NOTIFICATION
User &SENDER has requested more information for the notification. Please reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your comments between the quotes against the prompt.
Question: &QUESTION
&RESPONSE
__________________End of Response Template__________________
Notification Details:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<HTML> <HEAD> <TITLE> Oracle Workflow Notification </TITLE><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE> </HEAD>
<BODY BGCOLOR="#FFFFFF" >
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<P><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">From: &SENDER
<P>Question: <B>&QUESTION</B>
<P><B>Please click on the following link to respond to this request for more information</B>
<P>&CLICK_HERE_RESPONSE
<P><B>Notification Detail:</B></SPAN>
<P>&HEADER
<P>&BODY
<BR>
<SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Question:
<B>&QUESTION</B>
<P><B>Please click on the following link to respond to this request for more information</B>
<P>&CLICK_HERE_RESPONSE </SPAN>
<P>&HISTORY
</BODY>
</HTML>
Workflow Invalid Open Mail (More Information Request) Message
The Workflow Invalid Open Mail (More Information Request) message is sent to a user by default when a user responds incorrectly to a request for more information. For example, if an answering message from a user contains a valid notification ID (NID) line matching it with a request for more information about a notification, but does not contain any response value, the notification mailer sends a Workflow Invalid Open Mail (More Information Request) message to the user. This message describes how to respond to the request for information correctly.
The Workflow Invalid Open Mail (More Information Request) message has the following message attributes. The values are drawn from the message definition associated with a notification activity.
You can customize the boilerplate text that appears in the body of the Workflow Invalid Open Mail (More Information Request) message, where attributes preceded by an ampersand (&) are token substituted with runtime values when the notification is sent.
The boilerplate text for a plain text message body is as follows:
Oracle Workflow Notification
Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
Important: Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
Error Message: &MAIL_ERROR_MESSAGE
Value Found: &MAIL_VALUE_FOUND
Remarks: &MAIL_EXP_VALUES
_________________Start of Response Template_________________
More Information Template for &NOTIFICATION
User &SENDER has requested more information for the notification. Please reply to this message, including this response template with your reply. Copy and paste from this message if necessary to obtain an editable copy of the template. Insert your comments between the quotes against the prompt.
Question: &QUESTION
&RESPONSE
__________________End of Response Template__________________
Notification Details:
&HEADER
&BODY
Due Date: &DUE_DATE
&HISTORY
The boilerplate text for an HTML-formatted message body is as follows:
<html><Head><STYLE>
<!--
A:link {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#663300}
A:active {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#ff6600}
A:visited {font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;color:#996633}
--> </STYLE></Head>
<body><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#336699">&TIMEZONE
</SPAN>
<p><SPAN style="font-family:Arial,Helvetica,Geneva,sans-serif;font-size:10pt;font-weight:normal;color:#000000">Warning: Your previous response to this message was invalid (see error message below). Please resubmit your response.
<P>Error Message: &MAIL_ERROR_MESSAGE
<BR>
<BR>Value Found: &MAIL_VALUE_FOUND
<BR>
<BR>Remarks: &MAIL_EXP_VALUES
<HR><P>Question: <B>&QUESTION</B>
<P><B>Please click on the following link to automatically generate an E-mail response for this question. Before sending the E-mail response, ensure desired comments within quotes.</B>
<P>&MAILTO
<P>&HEADER
<P>&BODY
<P><B>Please click on one of the following choices to automatically generate an E-mail response. Before sending the E-mail response to close this notification, ensure all response prompts include a desired response value within quotes.</B>
<P><B>Important:</B> Some mail clients, notably early releases of Microsoft Outlook Express, may not copy the 'NID' line properly in your response. Please verify that the 'NID' line is included in full and contains the prefix 'NID' and all the details between the square brackets when responding.
<P>Question: <B>&QUESTION</B>
<P><B>Please click on the following link to automatically generate an E-mail response for this question. Before sending the E-mail response, ensure desired comments within quotes.</B>
<P>&MAILTO</SPAN>
<P>&HISTORY
</BODY> </HTML>
If you are using the version of Oracle Workflow embedded in Oracle Applications, you can optionally give users access to the Advanced Worklist and Personal Worklist Web pages from any responsibility you choose. To make a Worklist available from a particular responsibility, you must add the appropriate function to the menu associated with that responsibility. Then you can assign that responsibility to your users. See: Overview of Function Security, Oracle Applications System Administrator's Guide and Overview of Menus and Function Security, Oracle Applications Developer's Guide.
The following table shows the functions that correspond to each version of the Worklist.
| Function | User Function Name | Description |
|---|---|---|
| WF_WORKLIST | Advanced Workflow Worklist | Advanced Workflow worklist based on the Oracle Applications Framework |
| WF_WORKLIST_CUSTOM | Personal Worklist | Advanced Workflow worklist based on the Oracle Applications Framework, with options to personalize search and display |
The Advanced Worklist is seeded on the menu for the Workflow User Web Applications responsibility by default. You can also add this function to other responsibilities from which you want users to access notifications.
The Personal Worklist is an optional feature that is not seeded on any Oracle Applications menu. If you want users to access this version of the Worklist, you must first add the Personal Worklist function to the menu for a responsibility assigned to those users.
Related Topics
To View Notifications from the Advanced Worklist, Oracle Workflow User's Guide
To View Notifications from the Personal Worklist, Oracle Workflow User's Guide
In Oracle Applications, you can use the WF: Notification Reassign Mode profile option to control which reassign modes are available to users. Oracle Workflow provides the following reassign modes.
Delegate - This mode lets users give another user authority to respond to a notification on their behalf, while still retaining ownership of the notification themselves. For example, a manager might delegate all vacation scheduling approvals to an assistant.
Transfer - This mode lets users give another user complete ownership of and responsibility for a notification. For example, users might select this option if they should not have received a certain notification and they want to send it to the correct recipient or to another recipient for resolution. A transfer may have the effect of changing the approval hierarchy for the notification. For example, a manager might transfer a notification about a certain project to another manager who now owns that project.
You can specify which reassign modes users can select by setting the WF: Notification Reassign Mode profile option to one of the following values.
Reassign - This setting provides users access to both the Delegate and Transfer reassign modes. With this setting, the Advanced Worklist, the Personal Worklist, and the Response section of the Notification Details page display a Reassign button. Users can select this button to navigate to a Reassign page that lets them choose to either delegate or transfer the notification to another user. The Reassign setting is the default value for the WF: Notification Reassign Mode profile option.
Delegate - This setting provides users access only to the Delegate reassign mode. With this setting, the Advanced Worklist, the Personal Worklist, and the Response section of the Notification Details page display a Delegate button in place of the Reassign button. Users can select the Delegate button to navigate to a Reassign page that only lets them delegate the notification to another user.
Transfer - This setting provides users access only to the Transfer reassign mode. With this setting, the Advanced Worklist, the Personal Worklist, and the Response section of the Notification Details page display a Transfer button in place of the Reassign button. Users can select the Transfer button to navigate to a Reassign page that only lets them transfer the notification to another user.
You can set the WF: Notification Reassign Mode profile option in the System Profile Values window. This profile option can be set at site, application, responsibility, and user levels. The internal name for this profile option is FND_NTF_REASSIGN_MODE.
Related Topics
Overview of Setting User Profiles, Oracle Applications System Administrator's Guide
To View Notifications from the Advanced Worklist, Oracle Workflow User's Guide
To View Notifications from the Personal Worklist, Oracle Workflow User's Guide
To View the Details of a Notification, Oracle Workflow User's Guide
To Reassign a Notification to Another User, Oracle Workflow User's Guide
Vacation rules handle notifications automatically when users are not available to manage their notifications personally. These rules are defined according to the item type with which notifications are associated. In Oracle Applications, you can control what item types are available for vacation rules using the WF: Routing Rule Item Types lookup type and the WF: Vacation Rules - Allow All profile option.
Adding Item Types for Vacation Rules
By default, the list of item types a user can select when creating a vacation rule displays those item types for which the user has previously received at least one notification. You can also choose to add item types that you want to appear in the list for all users. In this way you can allow users to create rules to handle any notifications they may receive from those item types in the future.
To add an item type to the list, define the internal name of the item type as a lookup code for the WF: Routing Rule Item Types lookup type.
Navigate to the Application Object Library Lookups window in the Application Developer responsibility.
Query the WF_RR_ITEM_TYPES lookup type with the meaning WF: Routing Rule Item Types in the Application Object Library application.
Define the item type you want as a new lookup code for this lookup type. Ensure that you enter the item type internal name in the Code field exactly as the name is defined in your database. See: Application Utilities Lookups and Application Object Library Lookups, Oracle Applications online help.
Allowing Vacation Rules that Apply to All Item Types
Use the WF: Vacation Rules - Allow All profile option to determine whether the list of item types for vacation rules includes the "All" option. The "All" option lets users create a generic rule that applies to notifications associated with any item type.
Set the profile option to Enabled if you want the "All" option to appear in the list of item types for vacation rules, or to Disabled if you do not want the "All" option to appear. If you choose Disabled, then users must always specify the item type to which a vacation rule applies. The WF: Vacation Rules - Allow All profile option must be set at site level. The default value is Enabled. See: Overview of Setting User Profiles, Oracle Applications System Administrator's Guide.
After changing the value of this profile option, you must stop and restart Oracle HTTP Server for the change to take effect.
Related Topics
Defining Vacation Rules for Users
Vacation Rules, Oracle Workflow User's Guide
In Oracle Applications, notifications can require that a user's response be signed by a password-based signature or a certificate-based digital signature. Perform the following setup steps to enable users to provide these signatures.
Note: Electronic signatures are currently supported only for the version of Oracle Workflow embedded in Oracle Applications.
See: #WF_SIG_POLICY Attribute, Oracle Workflow Developer's Guide.
Implementing Password-based Signatures with Single Sign-On
Oracle Workflow supports password-based signatures for notifications based on Oracle Application Object Library (FND) passwords. If you maintain your directory service based on Oracle Application Object Library users and passwords, no additional setup is required. However, if you have implemented single sign-on functionality for your site through Oracle Internet Directory, and you want to use password-based signatures, you must perform the following steps.
Set the Applications SSO Login Types profile option to either Local or Both at user level for all users who need to enter password-based signatures.
Ensure that these users have valid passwords defined in Oracle Application Object Library. See: Managing Oracle Applications Security, Oracle Applications System Administrator's Guide.
For more information, see: Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On (OracleMetaLink note 261914.1).
Loading Certificates for Digital Signatures
If a notification requires a certificate-based digital signature, the user must sign the response with a valid X.509 certificate issued by a certificate authority. Before users can sign responses with their certificates, you must load these certificates into your Oracle Applications database using the Workflow Certificate Loader.
When you load a certificate, you must also specify the Oracle Applications user to whom that certificate is assigned. Oracle Workflow uses this information to validate that the user attempting to sign with a certain certificate is the same user to whom that certificate is assigned.
A user can have more than one certificate assigned to him or her. However, each certificate can only be assigned to one user. Additionally, after you have loaded a certificate for a user, you cannot delete it from the database or assign it to a different user. If a certificate is incorrectly assigned, the user to whom it belongs must revoke it and obtain a new certificate instead.
You can load several certificates at once by listing the information for all the certificates in a data file for the loader. You can also load a single certificate by specifying the certificate information in the command line for the loader.
Note: If your users access Oracle Applications with Microsoft Internet Explorer, ensure that you also set the Browser Signing DLL Location global preference in the Workflow Configuration page. See: To Set Global Preferences for Oracle Workflow Embedded in Oracle Applications.
For each certificate, obtain the following information:
The Oracle Applications user name of the user to whom the certificate belongs.
The personal certificate itself, in the DER encoded binary X.509 format. The certificate should be provided as a file with an extension of .cer.
The root certificate of the certificate authority that issued the personal certificate, as well as any intermediate certificates required for this type of personal certificate.
A URL for each root and intermediate certificate, specifying the location from which the corresponding Certificate Revocation List (CRL) can be downloaded.
Note: You only need to load the root certificate for a particular certificate authority, and the intermediate certificates for a particular type of certificate, once. If you already loaded the root and intermediate certificates required for a new personal certificate, you can simply load the personal certificate without reloading the others.
If you want to load several certificates at once, create a data file for the Workflow Certificate Loader that specifies the location of the certificates to be loaded and the users to whom they belong. The data file should be a text file containing one entry for each root, intermediate, or personal certificate to be loaded.
All certificate entries in the file must appear in the order of the certification path, beginning with the root certificate for the certificate authority, followed by any intermediate certificates and then by the personal certificate. However, if the root or intermediate certificates required for a particular personal certificate were loaded previously, you do not need to reload them.
Each certificate entry must be a single line. For a root or intermediate certificate, use the following format:
user=CA; domain=CA; filename=<certificate_file>; crl_url=<URL>
where <certificate_file> is the full path and file name specifying the location of the certificate file, and <URL> is the location from which the corresponding Certificate Revocation List (CRL) can be downloaded.
For a personal certificate, use the following format:
user=<user_name>; domain=U; filename=<certificate_file>
where <user_name> is the Oracle Applications user name of the user to whom the certificate belongs, and <certificate_file> is the full path and file name specifying the location of the certificate file.
You can also include comments in the data file. Start each comment line with a number sign (#).
The following example shows a sample data file. Note that although the lines may appear to wrap in this document, each certificate entry is a single line in the data file.
#Root certificate for certificate authority myCA
user=CA; domain=CA; filename=/certs/myCA.cer;
crl_url=http://myCA.com/myCA.crl
#
#Personal certificate for user BLEWIS
user=BLEWIS; domain=U; filename=/certs/blewis.cer
To load several certificates at once using a data file, run the Workflow Certificate Loader with the following command:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader
[-v] <user_name> <password> <connect_string> <data_file>
You can optionally specify the -v option to run the Workflow Certificate Loader in verbose mode, displaying additional diagnostic information in the output.
Replace the variables with your parameters as follows:
<user_name> - The user name of your Oracle Applications database account.
<password> - The password for your Oracle Applications database account.
<connect_string> - The connect string for the database, including the host name, TNS port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID><data_file> - The full path and file name specifying the location of the data file you created in the previous step.
For example:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader
-v apps apps myserv:4105:mySID myCertData.txt
To load a single certificate without using a data file, run the Workflow Certificate Loader specifying the certificate information in the command line. For a root or intermediate certificate, use the following command:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader
[-v] -s <user_name> <password> <connect_string> user=CA
domain=CA filename=<certificate_file> crl_url=<URL>
For a personal certificate, use the following command:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader
[-v] -s <user_name> <password> <connect_string> user=<user_name>
domain=U filename=<certificate_file>
You can optionally specify the -v option to run the Workflow Certificate Loader in verbose mode, displaying additional diagnostic information in the output.
Replace the variables with your parameters as follows:
<user_name> - The user name of your Oracle Applications database account.
<password> - The password for your Oracle Applications database account.
<connect_string> - The connect string for the database, including the host name, TNS port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID><user_name> - The Oracle Applications user name of the user to whom the personal certificate belongs.
<certificate_file> - The full path and file name specifying the location of the certificate file.
<URL> - The location from which the corresponding Certificate Revocation List (CRL) for the root or intermediate certificate can be downloaded.
For example:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader
-s apps apps myserv:4105:mySID user=BLEWIS domain=U
filename=/certs/blewis.cer
Note: You can display a help message describing the usage of the Workflow Certificate Loader by specify the -h option with the following command:
java oracle.apps.fnd.wf.DigitalSignature.loader.CertificateLoader -h
Troubleshooting the Workflow Certificate Loader
The following list shows Workflow Certificate Loader error messages and suggested steps to resolve them.
No parent certificate found for certificate - The loader could not locate the root or intermediate certificate that should precede the current certificate in the certificate path. Ensure that either the parent certificate is already loaded to the database, or a valid entry for the parent certificate appears before the entry for the current certificate in the data file.
Unable to create certificate object from file - The data in the certificate file may be corrupted. Check that the certificate is valid by double-clicking the certificate file and viewing its status. Also, ensure that the certificate is stored in the DER encoded binary X.509 format.
FND USER does not exist - The user name specified in a certificate entry in the data file is not defined as an Oracle Applications user. Ensure that the user name is specified as either CA for a certificate authority or a valid Oracle Applications user name for an individual user.
Certificate already associated with another user - The certificate has already been loaded to the database and assigned to a different user. If a certificate is incorrectly assigned, the user to whom it belongs must revoke it and obtain a new certificate instead.
Certdatafile not in proper format - The data file for the loader does not follow the required format. Ensure that the data file contains only certificate entries and comments, each certificate entry is a single line containing the appropriate arguments, and each comment line begins with a number sign (#).
The Network Adapter could not establish the connection - The loader was unable to connect to the database using the specified parameters. Ensure that you specify the correct database user name, password, and connect string when you run the loader.
Illegal Argument Exception - The loader could not process the parameters provided in the run command. Ensure that you specify the loader parameters in the required format.
After Oracle HTTP Server is installed and configured for your Oracle Workflow instance, you can customize the company logo that appears in the upper right corner of Oracle Workflow's Web pages.
To Customize Oracle Workflow's Web Pages
Copy or rename your company logo file (in .gif format) to FNDLOGOS.gif if you are using Oracle Workflow embedded in Oracle Applications or WFLOGO.gif if you are using the standalone version of Oracle Workflow.
Move the file to the physical directory that your Web server's /OA_MEDIA/ virtual directory points to.
Note: If you are using Oracle Workflow embedded in Oracle Applications, the mapping of /OA_MEDIA/ is completed as part of the Oracle Applications installation and setup steps.
If you are using the standalone version of Oracle Workflow, the mapping of /OA_MEDIA/ is completed after you install Oracle Workflow, during configuration of the Oracle Workflow middle tier components.
For more information, see the installation documentation for your release.
Oracle 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 wf subdirectory within your Oracle home.
Oracle Workflow provides a variety of icons that you can use to represent your activities and processes. You can add custom 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 diagram, perform the following steps.
Convert the custom icon files (.ico) to gif format (.gif).
Copy the .gif files to the physical directory that your Web server's /OA_MEDIA/ virtual directory points to, so that the Workflow Monitor can access them.
Note: If you are using Oracle Workflow embedded in Oracle Applications, the mapping of /OA_MEDIA/ is completed as part of the Oracle Applications installation and setup steps.
If you are using the standalone version of Oracle Workflow, the mapping of /OA_MEDIA/ is completed after you install Oracle Workflow, during configuration of the Oracle Workflow middle tier components.
For more information, see the installation documentation for your release.
To execute external Java function activities, you must set up the Java Function Activity Agent. This functionality is currently only available for the standalone version of Oracle Workflow. The Java Function Activity Agent dequeues the messages related to external Java activities from the 'Outbound' queue for external function processing, calls the appropriate Java functions, and places the results on the 'Inbound' queue for external function processing.
Note: These 'Outbound' and 'Inbound' queues are separate from the queues used for the Business Event System. See: Setting Up Background Workflow Engines and Workflow Queue APIs, Oracle Workflow API Reference.
After a Java function completes, you must run a background engine to process the 'Inbound' queue and complete the function activity. See: Setting Up Background Engines.
Some standard Workflow activities are external Java function activities and require the Java Function Activity Agent. You can also define your own external Java function activities. See: Standard Activities, Oracle Workflow Developer's Guide, To Create a Function Activity, Oracle Workflow Developer's Guide, and Standard API for Java Procedures Called by Function Activities, Oracle Workflow Developer's Guide.
To run the Java Function Activity Agent, you must have Java Development Kit (JDK) Version 1.4 installed.
Note: The Java Runtime Environment is available for download from: http://www.javasoft.com
Starting the Java Function Activity Agent
If you are using the standalone version of Oracle Workflow, you can run scripts provided by Oracle Workflow to start the Java Function Activity agent. You can also start the agent manually.
When you start the Java Function Activity Agent, you must specify the user name of your Oracle Workflow database account and the database connect string. You can also optionally specify the character set and the JDBC driver type that you want to use.
After starting, the Java Function Activity Agent prompts you to enter the password for your Oracle Workflow database account.
You use different commands to start the agent depending on whether you are running it from a script or manually, and which platform you are running it on.
Starting the Java Function Activity Agent From a Script
You can run scripts called wfjvlsnr.csh or wfjvlsnr.bat to start the Java Function Activity Agent on UNIX or on Windows, respectively. These scripts are located on your server in the ORACLE_HOME/wf/admin directory.
If you define your own external Java function activities, you must edit the scripts to include the path to the JAR files containing your custom Java classes. The custom class files should reside on the same platform where the Java Function Activity Agent is run. The Java Function Activity Agent does not need to reside on the same tier as the database, however.
Running the wfjvlsnr.csh Script on UNIX
Use the following command to run the wfjvlsnr.csh script on UNIX:
wfjvlsnr.csh "<user_name> <connect_string>
[<JDBC_driver>]" [<character_set>]
Replace the parameters in the command as follows:
<user_name> - The user name of your Oracle Workflow database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>
For a JDBC THIN driver, you can use two different types of connect string. For the first type, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID>
For the second type, the connect string should include an Oracle Net name-value pair with the host name, protocol, port number, and SID in the following format:
(description=(address=(host=<host_name>)
(protocol=<protocol>)(port=<port_number>))
(connect_data=(sid=<database_SID>)))
<JDBC_driver> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin. If you do not specify a driver type, Oracle Workflow uses the JDBC OCI8 driver by default.
<character_set> - The character set to use for the database session. If you do not specify a character set, Oracle Workflow uses UTF8 by default.
Note: The connection details, including the user name, connect string, and JDBC driver type, must be enclosed in double quotes to separate them from the character set parameter.
Running the wfjvlsnr.bat Script on Windows
Use the following command to run the wfjvlsnr.bat script on Windows:
wfjvlsnr.bat "<user_name> <connect_string>
[<JDBC_driver>]" [<character_set>]
Replace the parameters in the command as follows:
<user_name> - The user name of your Oracle Workflow database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>
For a JDBC THIN driver, you can use two different types of connect string. For the first type, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID>
For the second type, the connect string should include an Oracle Net name-value pair with the host name, protocol, port number, and SID in the following format:
(description=(address=(host=<host_name>)
(protocol=<protocol>)(port=<port_number>))
(connect_data=(sid=<database_SID>)))
<JDBC_driver> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin. If you do not specify a driver type, Oracle Workflow uses the JDBC OCI8 driver by default.
<character_set> - The character set to use for the database session. If you do not specify a character set, Oracle Workflow uses UTF8 by default.
Note: The connection details, including the user name, connect string, and JDBC driver type, must be enclosed in double quotes to separate them from the character set parameter.
Starting the Java Function Activity Agent Manually
To start the Java Function Activity Agent manually, run JRE against oracle.apps.fnd.wf.WFFALsnr, specifying your CLASSPATH, the user name of your Oracle Workflow database account, and the database connect string. You can also optionally specify the character set and the JDBC driver type that you want to use.
The CLASSPATH must point to the Java Runtime Environment, the directory containing the Workflow JAR files, the Oracle XML parser, the Oracle JDBC implementation, and the following Workflow JAR files:
wfjava.jar - The Java Function Activity Agent.
wfapi.jar - Workflow Java APIs.
The Share JAR file - Utilities referenced by the Workflow Java APIs. In standalone Oracle Workflow, this file is named share-<version>.jar, such as share-1_1_9.jar, or whichever version is current.
The Ewt JAR file - Utilities referenced by the Workflow Java APIs. In standalone Oracle Workflow, this file is named ewt-<version>.jar, such as ewt-3_3_18.jar, or whichever version is current.
The Swing JAR file - Optional additional utilities. In standalone Oracle Workflow, this file is named swingall-<version>.jar, such as swingall-1_1_1.jar, or whichever version is current.
fndctx.jar - Utilities referenced by the Workflow Java APIs.
Note: In standalone Oracle Workflow, the Workflow JAR files are located in the ORACLE_HOME/jlib directory.
If you define your own external Java function activities, you must also include the JAR files containing your custom Java classes in the CLASSPATH. The custom class files should reside on the same platform where the Java Function Activity Agent is run. The Java Function Activity Agent does not need to reside on the same tier as the database, however.
Starting the Java Function Activity Agent on UNIX
Use the following command to start the Java Function Activity Agent on UNIX:
jre -classpath "$<JREPATH>/rt.jar:$<Workflow_JAR_file_directory>:
$<Workflow_JAR_file_directory>/wfjava.jar:$<ORACLE_HOME>/wf/
xml/java/lib/xmlparserv2.jar:$<Workflow_JAR_file_directory>/
wfapi.jar:$<ORACLE_HOME>/jdbc/lib/classes111.zip:
$<Workflow_JAR_file_directory>/<Share_JAR_file>:
$<Workflow_JAR_file_directory>/<Ewt_JAR_file>:
$<Workflow_JAR_file_directory>/<Swing_JAR_file>:
$<Workflow_JAR_file_directory>/fndctx.jar:"
[-DCHARSET=<character_set>] oracle.apps.fnd.wf.WFFALsnr
<user_name> <connect_string> [<JDBC_driver>]
In this command, you can optionally use the -DCHARSET option to specify the character set that you want to use. If you do not specify a character set, Oracle Workflow uses UTF8 by default.
Replace the parameters in the command as follows:
<character_set> - The character set to use for the database session.
<user_name> - The user name of your Oracle Workflow database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>
For a JDBC THIN driver, you can use two different types of connect string. For the first type, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID>
For the second type, the connect string should include an Oracle Net name-value pair with the host name, protocol, port number, and SID in the following format:
(description=(address=(host=<host_name>)
(protocol=<protocol>)(port=<port_number>))
(connect_data=(sid=<database_SID>)))
<JDBC_driver> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin. If you do not specify a driver type, Oracle Workflow uses the JDBC OCI8 driver by default.
Starting the Java Function Activity Agent on Windows
Use the following command to start the Java Function Activity Agent on Windows:
jre -classpath ";<JREPATH>\rt.jar;<Workflow_JAR_file_directory>;
<Workflow_JAR_file_directory>\wfjava.jar;<ORACLE_HOME>\wf\
xml\java\lib\xmlparserv2.jar;<Workflow_JAR_file_directory>\
wfapi.jar;<ORACLE_HOME>\jdbc\lib\classes111.zip;
<Workflow_JAR_file_directory>\<Share_JAR_file>;
<Workflow_JAR_file_directory>\<Ewt_JAR_file>;
<Workflow_JAR_file_directory>\<Swing_JAR_file>;
<Workflow_JAR_file_directory>\fndctx.jar;"
-nojit [-DCHARSET=<character_set>] oracle.apps.fnd.wf.WFFALsnr
<user_name> <connect_string> [<JDBC_driver>]
In this command, you can optionally use the -DCHARSET option to specify the character set that you want to use. If you do not specify a character set, Oracle Workflow uses UTF8 by default.
Replace the parameters in the command as follows:
<character_set> - The character set to use for the database session.
<user_name> - The user name of your Oracle Workflow database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>
For a JDBC THIN driver, you can use two different types of connect string. For the first type, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID>
For the second type, the connect string should include an Oracle Net name-value pair with the host name, protocol, port number, and SID in the following format:
(description=(address=(host=<host_name>)
(protocol=<protocol>)(port=<port_number>))
(connect_data=(sid=<database_SID>)))
<JDBC_driver> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin. If you do not specify a driver type, Oracle Workflow uses the JDBC OCI8 driver by default.
Stopping the Java Function Activity Agent
Normally, the Java Function Activity Agent runs as a perpetual job. However, you can stop the agent by running a script called wfjvstop.sql, located in the ORACLE_HOME/wf/admin/sql directory. This script places a stop message on the 'Outbound' queue. See: wfjvstop.sql.
Note: If you are running more than one Java Function Activity Agent simultaneously, you must run the wfjvstop.sql script once for each Java Function Activity Agent.
The Business Event System is an application service delivered with Oracle Workflow that uses Oracle Advanced Queuing (AQ) to communicate business events between systems. You need to perform this step to use event processing. See: Overview of the Oracle Workflow Business Event System, Oracle Workflow API Reference and Managing Business Events, Oracle Workflow Developer's Guide.
To set up the Business Event System and enable message propagation, perform the following steps:
If you want to communicate business events between the local system and external systems, create database links to those external systems.
If you want to use custom queues for propagating events, set up your queues.
If you are using the version of Oracle Workflow embedded in Oracle Applications, synchronize event and subscription license statuses with product license statuses.
Ensure that the WF_CONTROL queue is periodically cleaned up to remove inactive subscribers.
You should recheck your setup whenever you make changes to your agents that affect the physical implementation required for propagation. See: Agents, Oracle Workflow Developer's Guide.
Note: Oracle Workflow sets the status of the local system to Enabled by default. After you finish setting up the Business Event System, you can update your global workflow preferences to set the system status that you want for event processing. See: Setting Global User Preferences.
Creating Database Links
To propagate event messages between systems, you must create database links from your local system to the remote systems. You should fully qualify the database link name with the domain name.
You can either create database links manually, or use Oracle DBA Studio in the Oracle Enterprise Manager to perform this step. Oracle DBA Studio allows workflow administrators to quickly and easily create and administer database links, queue tables, queues, and queue propagation without requiring knowledge of the SQL DDL commands. See: DBA Management Pack, Oracle Enterprise Manager Administrator's Guide or the Oracle Enterprise Manager online help.
You can use the following syntax to create a database link manually:
CREATE DATABASE LINK <database link name> CONNECT TO
<user> IDENTIFIED BY <password> USING '<connect string>';
For example:
CREATE DATABASE LINK wf10g.us.oracle.com CONNECT TO
wfuser IDENTIFIED BY welcome
USING 'wf817';
If you have multiple installations of Oracle Workflow on both the local database and the remote database, and you want to use the same username and password to access both systems, you can omit the <user> IDENTIFIED BY <password> clause. In this case, the database link uses the username and password of the user who is connected to the database.
CREATE DATABASE LINK <database link name> CONNECT TO
USING '<connect string>';
If you want to create a public database link available to all users, specify the parameter PUBLIC.
CREATE PUBLIC DATABASE LINK <database link name> CONNECT TO
<user> IDENTIFIED BY <password>
USING '<connect string>';
To verify the names of your database links, use the following syntax:
SELECT db_link FROM all_db_links;
See: CREATE DATABASE LINK, Oracle SQL Reference.
Setting Up Queues
The Business Event System uses Oracle Advanced Queuing (AQ) to communicate event messages between systems. You must associate a queue with each agent on a Workflow-enabled system that you define in the Event Manager.
When you install Oracle Workflow, several standard queues are created automatically for the standard Workflow agents. These queues all use either the standard WF_EVENT_T structure or JMS Text messages as their payload type. See: Standard Agents, Oracle Workflow Developer's Guide, Event Message Structure, Oracle Workflow API Reference, and Mapping Between WF_EVENT_T and SYS.AQ$_JMS_TEXT_MESSAGE, Oracle Workflow API Reference.
The following table lists the standard queues.
| Queue Table | Queue Name | Payload Type | Retention Time | Description |
|---|---|---|---|---|
| WF_CONTROL | WF_CONTROL | SYS.AQ$_JMS_ TEXT_MESSAGE | 1 day | Oracle Workflow internal queue, not for customer use |
| WF_DEFERRED | WF_DEFERRED | WF_EVENT_T | 1 day | Standard queue for deferred subscription processing in the database |
| WF_ERROR | WF_ERROR | WF_EVENT_T | 0 days | Standard queue for error handling in the database |
| WF_IN | WF_IN | WF_EVENT_T | 7 days | Default inbound queue |
| WF_JAVA_DEFERRED | WF_JAVA_DEFERRED | SYS.AQ$_JMS_ TEXT_MESSAGE | 1 day | Standard queue for deferred subscription processing in the middle tier |
| WF_JAVA_ERROR | WF_JAVA_ERROR | SYS.AQ$_JMS_ TEXT_MESSAGE | 0 days | Standard queue for error handling in the middle tier |
| WF_JMS_IN | WF_JMS_IN | SYS.AQ$_JMS_ TEXT_MESSAGE | 7 days | Default inbound queue for JMS Text messages |
| WF_JMS_OUT | WF_JMS_OUT | SYS.AQ$_JMS_ TEXT_MESSAGE | 7 days | Default outbound queue for JMS Text messages |
| WF_NOTIFICATION_IN | WF_NOTIFICATION_IN | SYS.AQ$_JMS_ TEXT_MESSAGE | 1 day | Standard inbound queue for e-mail notification responses |
| WF_NOTIFICATION_OUT | WF_NOTIFICATION_OUT | SYS.AQ$_JMS_ TEXT_MESSAGE | 1 day | Standard outbound queue for e-mail notifications |
| WF_OUT | WF_OUT | WF_EVENT_T | 7 days | Default outbound queue |
| WF_WS_JMS_IN | WF_WS_JMS_IN | SYS.AQ$_JMS_ TEXT_MESSAGE | 7 days | Default inbound queue for Web service messages |
| WF_WS_JMS_OUT | WF_WS_JMS_OUT | SYS.AQ$_JMS_ TEXT_MESSAGE | 7 days | Default outbound queue for Web service messages |
Note: Oracle Workflow also includes three queues named WF_REPLAY_IN, WF_REPLAY_OUT, and WF_SMTP_O_1_QUEUE, which are not currently used. The WF_JAVA_DEFERRED, WF_JAVA_ERROR, WF_WS_JMS_IN, and WF_WS_JMS_OUT queues are currently used only in Oracle Applications. Also, in Oracle Applications, Oracle XML Gateway provides additional standard queues.
Oracle Workflow includes three queues for background engine processing named WF_DEFERRED_QUEUE_M, WF_OUTBOUND_QUEUE, and WF_INBOUND_QUEUE. These queues are separate from the Business Event System queues. See: Setting Up Background Workflow Engines.
If necessary, you can change the default retention time set for consumed messages on the standard Workflow queues, using the PL/SQL procedure DBMS_AQADM.Alter_Queue. You must not change any other part of the setup of these queues.
You can also set up your own queues for event message propagation. You can either set up queues manually, or use Oracle DBA Studio in the Oracle Enterprise Manager to perform this step. Oracle DBA Studio allows workflow administrators to quickly and easily create and administer database links, queue tables, queues, and queue propagation without requiring knowledge of the SQL DDL commands. See: DBA Management Pack, Oracle Enterprise Manager Administrator's Guide or the Oracle Enterprise Manager online help.
To set up a queue manually, you must create the queue table, create the queue, and start the queue. You should perform these tasks using a schema that is appropriate for the application for which you will use the queue. You must specify the schema that owns the queue as part of the queue name when you assign the queue to a Business Event System agent.
To create a queue table, use the PL/SQL procedure DBMS_AQADM.Create_Queue_Table. Use the following syntax:
DBMS_AQADM.Create_Queue_Table (
queue_table => '<queue table name>',
queue_payload_type => '<queue payload type>',
sort_list => 'PRIORITY,ENQ_TIME',
multiple_consumers => TRUE
compatible => '8.1');
For queues that should use the standard Workflow format, specify the queue payload type as WF_EVENT_T. These queues can use the standard queue handler provided with Oracle Workflow, WF_EVENT_QH. For queues that should use the JMS Text message format, specify the queue payload as $AQ_JMS_TEXT_MESSAGE. These queues can use the standard JMS queue handler provided with Oracle Workflow, WF_EVENT_OJMSTEXT_QH. If you define a queue with a different payload type, you must create a queue handler to translate between the standard Workflow format and the format required by the queue. See: Standard APIs for a Queue Handler, Oracle Workflow Developer's Guide.
You can also use the storage_clause parameter to specify the tablespace where you want to create the queue table. You may want to specify a tablespace if you expect a queue to be very large.
To create a queue, use the PL/SQL procedure DBMS_AQADM.Create_Queue. Use the following syntax:
DBMS_AQADM.Create_Queue (
queue_name => '<queue name>',
queue_table => '<queue table name>');
Note: If you want other database users to enqueue messages onto or dequeue messages from your queue, you must grant those users the appropriate privileges using the PL/SQL procedure DBMS_AQADM.Grant_Queue_Privilege.
To start a queue, use the PL/SQL procedure DBMS_AQADM.Start_Queue. Use the following syntax:
DBMS_AQADM.Start_Queue (
queue_name => '<queue name>');
Oracle Workflow provides a sample script called wfevquec.sql which you can modify to set up your queues, as well as a sample script called wfevqued.sql which you can modify to drop queues. These scripts are located on your server in the ORACLE_HOME/wf/sql directory for the standalone version of Oracle Workflow, or in the $FND_TOP/sql directory for the version of Oracle Workflow embedded in Oracle Applications.
You can verify that your queues are set up properly using the Oracle Workflow Manager component of Oracle Applications Manager or Oracle Enterprise Manager. See the Oracle Workflow Manager online help.
In Oracle Applications, you can also run a diagnostic test to verify your queues. See: Oracle Workflow Diagnostic Tests.
Note: SQL*Plus version 8.1.6 does not allow you to select the USER_DATA column from queue tables. You must have SQL*Plus version 8.1.7 or higher, which allows you to select USER_DATA, if you want to be able to select the event message payload from your Workflow queues.
See: Administrative Interface, Oracle Application Developer's Guide - Advanced Queuing or Oracle Streams AQ Administrative Interface, Oracle Streams Advanced Queuing User's Guide and Reference and DBMS_AQADM, Oracle Supplied PL/SQL Packages Reference or DBMS_AQADM, PL/SQL Packages and Types Reference
Checking the Business Event System Setup
Use the Oracle Workflow Manager component of Oracle Applications Manager or Oracle Enterprise Manager to verify that the required parameters and components have been set up to enable message propagation for the Business Event System, including the required database initialization parameters. For more information, please refer to the Oracle Workflow Manager online help.
If you are using Oracle9i Database and higher, you can either modify the parameters in the init.ora file and restart the database, or you can use the ALTER SYSTEM statement to dynamically modify the parameters for the duration of the instance.
AQ_TM_PROCESSES - This parameter enables the time manager process in Oracle Advanced Queuing (AQ). The time manager process is required by Oracle Workflow to monitor delay events in queues, as in the case of the Oracle Workflow standard Wait activity. The recommended number of time manager processes for Oracle Workflow is two or more.
JOB_QUEUE_PROCESSES - This parameter defines the number of SNP job queue processes for your instance. Oracle Workflow requires job queue processes to handle propagation of Business Event System event messages by AQ queues. You must start at least one job queue process to enable message propagation. The minimum recommended number of processes for Oracle Workflow is ten.
Note: If you want to review more detailed information about AQ processing, you can optionally use another initialization parameter, EVENT, for detailed database level tracing of issues related to AQ. Add the following line to your init.ora file:
event = "24040 trace name context forever, level 10"
Then restart your database to make this change effective. Be aware that using this parameter may generate large trace files.
See: Oracle Application Developer's Guide - Advanced Queuing or Oracle Streams Advanced Queuing User's Guide and Reference.
Scheduling Listeners for Local Inbound Agents
To communicate events between different agents, you must schedule listeners for the inbound agents on your local system. The Business Event System requires listeners to be scheduled to receive inbound event messages. Run PL/SQL agent listeners to process event subscriptions with a PL/SQL rule function in the database. In Oracle Applications, you can also run Java agent listeners to process event subscriptions in the middle tier.
When you schedule a listener for an agent, it monitors the agent's queue, dequeuing any inbound event messages. When an event message is received, the Event Manager searches for and executes any enabled subscriptions by the local system to that event with a source type of External, and also any enabled subscriptions by the local system to the Any event with a source type of External. The listener exits after all event messages on the agent's queue have been dequeued.
The PL/SQL and Java agent listener programs are defined as service component types in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.
You can use Oracle Workflow Manager to submit and manage agent listener service components. You can also view the distribution of event messages on different agents, drill down to view details about individual event messages, and review queue details for the agents. Oracle Workflow Manager is available as a component of Oracle Applications Manager if you are using the version of Oracle Workflow embedded in Oracle Applications, or as a component of Oracle Enterprise Manager if you are using the standalone version of Oracle Workflow. For more information, please refer to the Oracle Applications Manager online help or the Oracle Enterprise Manager online help.
Oracle Workflow also provides an administrative script named wfagtlst.sql that you can use to run a PL/SQL agent listener. See Wfagtlst.sql.
Oracle Workflow provides seeded PL/SQL agent listener service components for the standard WF_DEFERRED, WF_ERROR, and WF_NOTIFICATION_IN agents. These agent listeners are named Workflow Deferred Agent Listener, Workflow Deferred Notification Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener, and they support deferred subscription processing in the database, dedicated deferred subscription processing for notification messages, error handling for the Business Event System in the database, and inbound e-mail processing for notification mailers, respectively.
In Oracle Applications, Oracle Workflow provides seeded Java agent listener service components for the standard WF_JAVA_DEFERRED, WF_JAVA_ERROR, and WF_WS_JMS_IN agents. These agent listeners are named Workflow Java Deferred Agent Listener, Workflow Java Error Agent Listener, and Web Services IN Agent, and they support deferred subscription processing in the middle tier, error handling for the Business Event System in the middle tier, and inbound Web service message processing, respectively.
In Oracle Applications, Oracle XML Gateway also provides two seeded PL/SQL agent listener service components for the standard ECX_INBOUND and ECX_TRANSACTION agents. These agent listeners are named ECX Inbound Agent Listener and ECX Transaction Agent Listener, respectively. For more information, see Monitor Workflow Processes, Oracle XML Gateway User's Guide.
You can also optionally create additional agent listener service components. For example, you can configure agent listeners for other inbound agents that you want to use for event message propagation, such as the standard WF_IN and WF_JMS_IN agents, or any custom agents. You can also configure an agent listener service component that only processes messages on a particular agent that are instances of a specific event.
Service components must be hosted by a service component container. If you create custom agent listener service components, you can assign them to the seeded container for agent listeners.
In Oracle Applications, a service component container is implemented as a Generic Service Management (GSM) service. The seeded container for agent listeners is named Workflow Agent Listener Service.
In standalone Oracle Workflow, a service component container is implemented as a servlet within an OC4J instance. The seeded container for agent listeners is named WFALSNRSVC, within an OC4J instance named OC4J_Workflow_Component_Container.
In Oracle Applications only, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers as GSM services in Oracle Applications Manager. If you create a custom GSM service in OAM, you can copy the service parameters from the seeded Workflow Agent Listener Service to your new service in order to specify how to run the new service.
Before agent listener service components can run, the container which manages them must first be started. In order to run the seeded agent listeners, you should ensure that the Workflow Agent Listener Service container is running using Oracle Applications Manager for the version of Oracle Workflow embedded in Oracle Applications, or ensure that the WFALSNRSVC container is running using Oracle Enterprise Manager for the standalone version of Oracle Workflow. If you create your own custom containers in OAM for custom service components, ensure that those containers are running as well.
Note: In Oracle Applications, you can run a diagnostic test to verify the GSM services for Oracle Workflow. See: Oracle Workflow Diagnostic Tests.
See: Agents, Oracle Workflow Developer's Guide and Listen, Oracle Workflow API Reference.
Exception Handling for Inbound Queues
Oracle Streams Advanced Queuing (AQ) transfers event messages from an agent's normal queue to the associated exception queue in the following cases:
A message expires before being dequeued.
An agent listener repeatedly attempts to process a message but rolls back the transaction due to an error, and the number of attempts exceeds the queue's retry limit.
In Oracle Applications, you can run the Move Messages from Exception to Normal Queue of Workflow Agent concurrent program (FNDWF_MOVE_MSGS_EXCEP2NORMAL) to transfer such messages back to the agent's normal queue. This program helps enable mass reprocessing in case of a large number of errors. Use Standard Request Submission to run the program, specifying the inbound agent for which you want to transfer messages back to the normal queue. After the program completes, run the appropriate agent listener to reattempt normal processing for these event messages. See: Running Reports and Programs, Oracle Applications User's Guide and Exception Handling, Oracle Streams Advanced Queuing User’s Guide and Reference.
Scheduling Propagation for Local Outbound Agents
To communicate events between different agents, you must schedule propagation for the outbound agents on your local system. The Business Event System requires propagation to be scheduled to send outbound event messages.
When you send an event message to an agent, the Event Manager places the message on the queue associated with the outbound agent. The message is then asynchronously delivered to the inbound agent by propagation.
You can schedule AQ propagation for agents that use the SQLNET protocol by the following methods:
Use the Distributed Database Management feature to manage AQ through Oracle Enterprise Manager. See: Oracle Enterprise Manager Support, Oracle Application Developer's Guide - Advanced Queuing or Oracle Streams Advanced Queuing User's Guide and Reference, and Distributed Management, Oracle Enterprise Manager Administrator's Guide or the Oracle Enterprise Manager online help.
Run the DBMS_AQADM.Schedule_Propagation API in SQL*Plus. See: DBMS_AQADM, PL/SQL Packages and Types Reference.
If you want to use the standard WF_OUT and WF_JMS_OUT agents or custom agents for event message propagation, ensure that you schedule propagation for those agents. You do not need to schedule propagation for the WF_CONTROL, WF_NOTIFICATION_OUT, or WF_WS_JMS_OUT agents, however. The middle tier processes that use WF_CONTROL dequeue messages directly from its queue, and notification mailers send messages placed on the WF_NOTIFICATION_OUT queue. For WF_WS_JMS_OUT, you can optionally start a Web services outbound component named Web Services OUT Agent, provided by Oracle Workflow.
For agents that use protocols other than the SQLNET protocol, you must provide external propagation logic. See: Agents, Oracle Workflow Developer's Guide.
You can use Oracle Workflow Manager to review the propagation schedules for your local outbound agents. You can also view the distribution of event messages on different agents, drill down to view details about individual event messages, and review queue details for the agents. Oracle Workflow Manager is available as a component of Oracle Applications Manager if you are using the version of Oracle Workflow embedded in Oracle Applications, or as a component of Oracle Enterprise Manager if you are using the standalone version of Oracle Workflow. For more information, please refer to the Oracle Applications Manager online help or the Oracle Enterprise Manager online help.
See: Agents, Oracle Workflow Developer's Guide.
Synchronizing License Statuses
This step is required only for the version of Oracle Workflow embedded in Oracle Applications. Some Oracle Applications products provide seeded events and subscriptions. In these cases, Oracle Workflow executes subscriptions only if the triggering event and the subscription are both owned by products that you have licensed with a status of Installed or Shared.
You can use the License Manager AD utility to review which products you currently have licensed. See: License Manager, Oracle Applications AD Utilities Reference Guide.
To ensure that the license status of the seeded events and subscriptions in the Business Event System is updated according to the status of the products you currently have licensed, you can run the Synchronize Product License and Workflow BES License concurrent program. Use the Submit Requests form in Oracle Applications to submit this concurrent program.
If you upgrade from an Oracle Applications release earlier than Release 11.5.9, you should run the Synchronize Product License and Workflow BES License concurrent program once after the upgrade to update the license status of the existing events and subscriptions in your Event Manager. Otherwise, subscriptions may not be correctly processed after the upgrade. Subsequently, when you license a product, Oracle Workflow automatically updates the license status for all the events and subscriptions owned by that product.
Note: Any events and subscriptions that you define with a customization level of User are always treated as being licensed.
See: Events (for Oracle Applications), Oracle Workflow Developer's Guide and Event Subscriptions (for Oracle Applications), Oracle Workflow Developer's Guide.
To submit the Synchronize Product License and Workflow BES License concurrent program
Navigate to the Submit Requests form in Oracle Applications to submit the Synchronize Product License and Workflow BES License concurrent program. When you install and set up Oracle Applications and Oracle Workflow, 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. The executable name for this concurrent program is "Synchronize Product License and Workflow BES License" and its short name is FNDWFLIC. See: Overview of Concurrent Programs and Requests, Oracle Applications System Administrator's Guide.
Select the Synchronize Product License and Workflow BES License concurrent program as the request to run. This program does not require any parameters. See: Running Reports and Programs, Oracle Applications User's Guide.
When you finish modifying the print and run options to define the schedule for this request, choose Submit to submit the request.
Cleaning Up the Workflow Control Queue
Oracle Workflow contains a standard Business Event System agent named WF_CONTROL, which is associated with a standard queue that is also named WF_CONTROL. This queue has a payload type of JMS Text message. The WF_CONTROL agent is used for internal processing only, and is not meant for customer use. You should not place custom event messages on this queue.
The Generic Service Component Framework uses WF_CONTROL to handle control events for containers and service components, such as notification mailer or agent listener service components. In Oracle Applications, WF_CONTROL is also used for other Oracle Applications internal processing.
You do not need to schedule propagation for the WF_CONTROL agent, because the middle tier processes that use WF_CONTROL dequeue messages directly from its queue.
However, the subscribers to the WF_CONTROL queue need to be cleaned up periodically.
In the standalone version of Oracle Workflow, you can use an API called WF_BES_CLEANUP.Cleanup_Subscribers() to perform this cleanup.
In Oracle Applications, a concurrent program named Workflow Control Queue Cleanup is automatically scheduled to perform this cleanup for you.
When a middle tier process for Oracle Applications or for standalone Oracle Workflow starts up, it creates a JMS subscriber to the queue. Then, when an event message is placed on the queue, a copy of the event message is created for each subscriber to the queue. If a middle tier process dies, however, the corresponding subscriber remains in the database. For more efficient processing, you should ensure that WF_CONTROL is periodically cleaned up by removing the subscribers for any middle tier processes that are no longer active.
The WF_BES_CLEANUP.Cleanup_Subscribers() procedure sends an event named oracle.apps.wf.bes.control.ping to check the status of each subscriber to the WF_CONTROL queue. If the corresponding middle tier process is still alive, it sends back a response. The next time the cleanup procedure runs, it checks whether responses have been received for each ping event sent during the previous run. If no response was received from a particular subscriber, that subscriber is removed. See: Cleanup_Subscribers, Oracle Workflow API Reference.
The recommended frequency for performing cleanup is every twelve hours. In order to allow enough time for subscribers to respond to the ping event, the minimum wait time between two cleanup runs is thirty minutes. If you run the procedure again less than thirty minutes after the previous run, it will not perform any processing.
Control Queue Cleanup for Standalone Oracle Workflow
If you are using the standalone version of Oracle Workflow, then use the WF_BES_CLEANUP.Cleanup_Subscribers() API to clean up the WF_CONTROL queue. You can use the Oracle Workflow Manager component available through Oracle Enterprise Manager to submit and manage Workflow control queue cleanup database jobs. You can also use the procedures in the DBMS_JOB or DBMS_SCHEDULER packages to schedule and manage the WF_BES_CLEANUP.Cleanup_Subscribers() procedure as a database job. See the Oracle Workflow Manager online help and Managing Job Queues, Oracle Database Administrator's Guide or Using the Scheduler, Oracle Database Administrator's Guide.
Control Queue Cleanup for Oracle Applications
If you are using the version of Oracle Workflow embedded in Oracle Applications, Oracle Workflow provides a concurrent program named Workflow Control Queue Cleanup, which uses the WF_BES_CLEANUP.Cleanup_Subscribers() API to perform the necessary cleanup. This concurrent program is scheduled to run every twelve hours by default, which is the recommended frequency for performing cleanup. You can optionally run this program with a different schedule if you want to perform cleanup at a different frequency.
To submit the Workflow Control Queue Cleanup concurrent program
Navigate to the Submit Requests form in Oracle Applications to submit the Workflow Control Queue Cleanup concurrent program. When you install and set up Oracle Applications and Oracle Workflow, 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. The executable name for this concurrent program is "Workflow Control Queue Cleanup" and its short name is FNDWFBES_CONTROL_QUEUE_CLEANUP. See: Overview of Concurrent Programs and Requests, Oracle Applications System Administrator's Guide.
Select the Workflow Control Queue Cleanup concurrent program as the request to run. This program does not require any parameters. See: Running Reports and Programs, Oracle Applications User's Guide.
When you finish modifying the print and run options to define the schedule for this request, choose Submit to submit the request.
In Oracle Applications, you can run a diagnostic test to check that the Workflow control queue is properly accessible. See: Oracle Workflow Diagnostic Tests.
See: Business Event System Control Events, Oracle Workflow Developer's Guide, Standard Agents, Oracle Workflow Developer's Guide, and Business Event System Cleanup API, Oracle Workflow API Reference.
