Setting Up an Oracle Workflow Directory Service (Oracle Workflow Administrator's Guide)

Oracle Workflow Administrator's Guide
Release 2.6.3.5
Part Number B12160-02


	Previous	Next		Contents	Index	Glossary

Step 3 Setting Up an Oracle Workflow Directory Service

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 (OID) as your directory repository. In this case, directory service views that support OID 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 OID, 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 OID, the Workflow local tables store user information that is retrieved from and synchronized with OID, 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 OID 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 OID to maintain users after integrating with OID. You can still use ad hoc roles, however, since Workflow roles are not maintained through OID. 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.

Context: You need to perform this step only once.

Step 3 Setting Up an Oracle Workflow Directory Service

See Also