Advanced: Viewing all workflows owned by all users using Workflow Administrator responsibility

Below listed are the ways of assigning a role to view all workflows in Oracle Applications

Note: A role is created automatically when a new user or a responsibility is defined in Oracle Applications. These roles are available in the table wf_local_roles which is consolidate in the view wf_roles.

1)      From Oracle Applications, Workflow Administrator responsibility

a.       Navigate to the responsibility à Administration tab à Workflow Configuration and select the Workflow System Administrator value from the LOV field. 
b.      Set to ‘*’ if all users are given access to view all workflows

2)      Using Backend (database) Update

a.       Get the role at the level which the access needs to be provided

User Level

In order to assign workflow admin access to view all workflows in Oracle then select the role for the user created in Oracle Applications from the view wf_roles, this is stored in the column ‘NAME’ of the view.

Example: SYSADMIN (or) PATRICK

Responsibility Level

In order to assign workflow admin access to view all workflows for all users through a responsibility in Oracle then select the role for the responsibility created in Oracle Applications from the view wf_roles, this is stored similar to above in the column ‘NAME’ of the view.

FORMAT: FND_RESP|FND|<RESP_SHORT_NAME>|STANDARD

b.      Update the table WF_RESOURCES which holds the access information using the role arrived from step 2.a. Prior to update always check what is stored currently and get a backup of the information, which is easier to revert back the changes.

UPDATE WF_RESOURCES

SET TEXT=<ROLE_NAME>

WHERE NAME = 'WF_ADMIN_ROLE';

COMMIT;

3)      Default using AUTOCONFIG

When autoconfig is run, the default admin role defined in the CONTEXT file is picked and configured. This context file is specific to application server and stores most of the default configuration variables. The value for wfadmin is stored in the variable 's_wf_admin_role'. Once you ahve sourced the environment file you can echo the context file location using $CONTEXT_FILE variable and then search for the variable in the file. The value from this file will be considered when the next autoconfig is run.

Example:

<username oa_var="s_wf_admin_role">FND_RESP|FND|FNDWF_ADMIN_WEB|STANDARD</username>

Running Autoconfig

$OAD_TOP/admin/scripts/$CONTEXT_NAME/adautocfg.sh (11i)

$ADMIN_SCRIPTS_HOME/adautocfg.sh (R12)

Script: Loading data into Shared Type Values for Documents of Record functionality in Oracle Applications

I was working on the functionality of Documents of Records and found some ways to create categories from the front end as well as the backend. You will find the quicksteps to configure and use documents of record in my blog post http://plsql-apps.blogspot.co.at/2013/09/hrms-functionality-quick-tips-to-start.html

Defining documents of record configuration from backend involves adding lookup values to already existing lookup type 'DOCUMENT_CATEGORY' and entering categories / subcategories in Shared Types and then finally registering your document type by running a concurrent program 'Register Document Type'. You can check how to create and add lookup types / values using APIs in the blog post http://plsql-apps.blogspot.co.at/2013/09/script-oracle-applications-package-to.html

The below script is to load data into the shared types table using standard API, which automatically inserts data into the _vl table too.

DECLARE
   ln_shared_type_id          NUMBER;
   ln_object_version_number   NUMBER;
BEGIN
   per_shared_types_api.create_shared_type (p_business_group_id          => 81,
                                            p_shared_type_name           => 'HR Test',
                                            p_shared_type_code           => 'HR_TEST',
                                            p_system_type_cd             => 'HR_INFO',
                                            p_lookup_type                => 'DOCUMENT_CATEGORY',
                                            p_effective_date             => TO_DATE ('07-08-2013',
                                                                                     'DD-MM-YYYY'
                                                                                    ),
                                            p_shared_type_id             => ln_shared_type_id,
                                            p_object_version_number      => ln_object_version_number
                                           );
   DBMS_OUTPUT.put_line (ln_shared_type_id);
   DBMS_OUTPUT.put_line (ln_object_version_number);
   COMMIT;
END;