Overview of Oracle Workflow Access Protection
Access protection is a feature that prevents workflow seed data created by a 'seed data provider' from being modified by a 'seed data consumer'. Here, a 'seed data provider' is any organization that creates 'seed data' for other organizations ('seed data consumers') to use in defining and customizing workflow process. In Oracle Workflow, seed data refers to either of the following:
- Workflow object definitions that can and should be customized to meet a certain consumer's needs.
For example, the Oracle Workflow development team is a provider of seed data called the Standard item type. The Standard item type contains standard activities that can be dropped into any custom workflow process. The development team at your organization's headquarters may create a custom workflow process definition that references activities from the Standard item type. This makes the headquarters team a consumer of the Standard item type seed data.
- Workflow object definitions protected against customization because they represent standards that may also be upgraded in the future by the provider.
Now suppose the headquarters team wants to deploy the custom workflow definition that it created to teams at other regional offices. The headquarters team, as seed data providers, may want to do the following:
- Identify certain workflow objects in its custom workflow definition as corporate standards that the regional teams should adhere to and not modify.
The headquarters team can satisfy both requirement using the access protection feature in Oracle Workflow. Access protection lets seed data providers protect certain data as 'read-only', while allowing other data to be customized. Also during a seed data upgrade, access protection lets the seed data provider overwrite any existing protected seed data with new versions of that seed data, while preserving any customizations made to customizable seed data.
- Designate certain objects in its deployed process as customizable for the regional offices to alter to their offices' needs.
Oracle Workflow assigns a protection and customization level to every workflow object definition stored in the database and requires every user of Oracle Workflow to operate at a certain access level. The combination of protection, customization, and access levels make up the access protection feature and determines whether a user can modify a given workflow object. The level in all three cases, is a numeric value ranging from 0 to 1000 that indicates the relationship between different organizations as providers and consumers of seed data.
The following range of levels are presumed by Oracle Workflow:
||Oracle Application Object Library
||Oracle Applications development
||Customer organization. You can determine how you want this range to be interpreted. For example, 100 can represent headquarters, while 101 can represent a regional office, and so on.
Setting Up a Default Access Level
Each user of Oracle Workflow operates the system at a certain access level according to the range of levels listed above. A "user of Oracle Workflow" in this case, represents someone who is operating Oracle Workflow Builder, or the Workflow Definitions Loader program, which loads workflow process definitions from a file into a database. As a seed data provider, you should always operate Oracle Workflow Builder at the same consistent access level because the level you work at affects the protection level of the seed data you create.
You can view your access level as follows:
- In Oracle Workflow Builder, select About Workflow from the Help menu.
- If you are going to run the Workflow Definitions Loader program, check the value for the environment variable WF_ACCESS_LEVEL on your workflow server. See: Using the Workflow Definitions Loader.
Note: The Workflow Definitions Loader program references the access level stored in the environment variable called WF_ACCESS_LEVEL, which you must define when you install Oracle Workflow on your server. If you do not define this environment variable, the Workflow Definitions Loader simply assumes a default access level of 100.
Note: When you install the standalone version of Oracle Workflow on your server, you need to define this variable in an environment file. The default environment file is APPLSYS.env. If you do not define this environment variable, the Workflow Definitions Loader simply assumes a default access level of 100. Refer to your Oracle Applications Installation Manual for more information about environment files.
Whenever you create a workflow object in Oracle Workflow Builder, you have the option of protecting the object at a certain level. An object's protection level controls whether other users can modify the object based on their access levels.
To change the protection level of an object, display the Access tab of the object's property page. The protection level that you set for an object is dependent on your current access level. You can control access to an object in one of four ways:
- Allow access to everyone--By default, all users are allowed access to an object if both "Preserve Customizations' and 'Lock at this Access Level' are unchecked in the Access tab, that is the protection level is equal to 1000.
- Limit access to users with access levels equal to your own or higher--If you check 'Preserve Customizations' in the Options region of the Access tab, you designate the object as being customizable by anyone with an access level equal to or higher than your current access level. You should only mark objects as customizable if you are sure that you will not be providing upgraded versions of this object in the future that would overwrite other user's customizations to it.
- Limit access to users with access levels equal to your own or lower--If you check 'Lock at this Access Level', you protect the object and ensure that the object may only be modified by users with an access level equal to or lower than your current access level. Users operating at a higher access level will see a small lock on the workflow object's icon, indicating that the object can be used but not modified. Protect any objects that you want to define as standard components that will not change unless you provide a global upgrade. For this reason, it is important that you always operate at the same consistent access level.
- Limit access to users with access levels equal to your own--If you check both 'Lock at this Level' and 'Preserve Customizations' you ensure that the object cannot be modified by anyone other than users operating at your current access level.
||Object may be updated by any access level.
||Object may only be updated by users with access levels equal to or higher than your current
||Object may only be updated by users with access levels equal to or lower than your current access level.
||Object cannot be updated by any access level except for your
current access level.
Attention: If you have installed the beta version of Microsoft's Internet Explorer on your PC, which automatically installs an early version of a file called comctl32.dll, you may not see the lock icons appear on the locked objects in Oracle Workflow Builder. To correct this problem, install the production version of Microsoft's Internet Explorer to replace comctl32.dll with the latest copy.
The protection and access levels in Oracle Workflow are present to remind you that certain workflow objects should not be modified or should only be modified by someone accessing the tool at an authorized access level. It is not intended as a means of securing or source controlling your workflow objects.
Attention: Most workflow objects provided by Oracle Workflow have a protection level of 0, which means the objects can only be modified by the Oracle Workflow team, operating at an access level of 0. If you attempt to alter your access level to 0 and modify the data anyway, your customizations will not be supported, especially if Oracle Workflow provides an upgrade to the seed data that may overwrite the modifications you make to the originally protected data.
Every workflow object, in addition to having a protection level, also records a customization level equal to your access level when you modify the object and save it to a database or file. For example, if a workflow object is customizable (protection level is 1000), and you customize it at an access level of 100, you now mark the object as having a customization level of 100. The customization level indicates that the object can only be further modified by someone operating at an access level equal to or higher than the customization level. So in this example, you can only customize the object further if your access level is 100 or higher. If you are operating at an access level lower than an object's customization level, you will see a small lock on that workflow object's icon, indicating that the object can be used but not modified
This ensures that a customizable object that has been customized never gets overwritten during a seed data upgrade because the upgrade always occurs with the Workflow Definitions Loader operating at an access level below the customized object's customization level.
To Set the Access Level for an Object