Previous	Next		Contents	Index	Glossary

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 WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES 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, and WF_USER_ROLES 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, and WF_USER_ROLES 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.

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 WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES 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.

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:

Note: Normally each partition contains only records that originate from the corresponding system. However, the FND_USR partition can contain both roles with an orig_system value of FND_USR, which are unlinked Oracle Applications users, and roles with an orig_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.

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

Note: You can still use the bulk synchronization program to synchronize the product's data for troubleshooting and diagnostic purposes, if necessary.

   To submit the Synchronize Workflow LOCAL Tables request set:

   To submit a single request for the Synchronize WF LOCAL Tables concurrent program:

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.

For example, the originating system FND_USR provides views named WF_FND_USR_ROLES and WF_FND_USR_UR.

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 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 and WF_LOCAL_USER_ROLES tables to update the partitions for that system in the Workflow local tables.

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.

See: Setting Up an Oracle Workflow Directory Service

Copyright © 2003 Oracle Corporation.
All rights reserved.