Skip Headers

Oracle Workflow Administrator's Guide
Release 2.6.4

Part Number B15852-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

Skip Headers

Oracle Workflow Administrator's Guide
Release 2.6.4
Part Number B15852-02
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Oracle Workflow Loaders

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 a workflow process. In Oracle Workflow, seed data refers to either of the following:

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.

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:

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.

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 makes 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:

Variable Description
0-9 Oracle Workflow
10-19 Oracle Application Object Library
20-99 Oracle Applications development
100-999 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.
1000 Public

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:

Protection Level

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 helps control whether other users can modify the object based on their access levels, by allowing only users with an access level equal to or lower than the object's protection level to modify the object.

Note: The range of access levels allowed to modify the object may be further restricted by the object's customization level.

To set the protection level of an object, display the Access tab of the object's property page and either check or clear the Lock at this Access Level check box. The protection level that you set for an object is dependent on the setting of the Lock at this Access Level check box and on your current access level.

Customization Level

Every workflow object, in addition to having a protection level, also records a customization level when you modify the object and save it to a database or file. An object's customization level helps control whether other users can modify the object based on their access levels, by allowing only users with an access level equal to or higher than the object's customization level to modify the object.

Note: The range of access levels allowed to modify the object may be further restricted by the object's protection level.

Setting the customization level 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 customization level of an object, display the Access tab of the object's property page and either check or clear the Preserve Customizations check box. The customization level that you set for an object is dependent on the setting of the Preserve Customizations check box and on your current access level.

Combining Protection and Customization Levels to Control Access

You control access to an object by the combined settings of the protection level and the customization level. You can set the Preserve Customizations and Lock at this Access Level check boxes for an object in one of four ways to specify the type of access you want to allow:

The following table summarizes which access levels can access an object under different settings of the Preserve Customizations and Lock at this Access Level options.

Object Access Under Combined Customization and Protection Levels
Preserve Customizations Lock at this Access Level Access Level Applied to Object
Cleared Cleared Object may be updated by any access level.
Checked Cleared Object may only be updated by users with access levels equal to or higher than your current access level.
Cleared Checked Object may only be updated by users with access levels equal to or lower than your current access level.
Checked Checked 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. This feature 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.

See: To Set the Access Level for an Object, Oracle Workflow Developer's Guide.

Setting Up a Default Access Level

When you install Oracle Workflow Builder on a Windows PC, Oracle Universal Installer assigns a default access level that is global to the PC and the operating system you are installing on. After installing Oracle Workflow Builder, you can have individual users on the PC change their access level to a new setting which overrides the default access level set for the PC. If a user does not define an access level, Oracle Workflow Builder assumes the value of the default access level for the PC. The access levels are stored in the Microsoft Windows registry.

If you are deploying Oracle Workflow Builder and workflow seed data to users in other parts of your organization, and you wish to discourage those users from modifying the seed data that you provide, you can have them operate Oracle Workflow Builder at an access level that is higher than the data's protection level. For example if you, as a seed data provider, are operating at an access level of 100 and the seed data you create is protected at a level of 100, then you should require the access level for your users or seed data consumers to be 101 or higher.

You can set a user's access level in Oracle Workflow Builder by having them choose About Oracle Workflow Builder... from the Help menu. In the About Oracle Workflow Builder window, change the Access Level field to a number higher than your seed data protection level, then choose OK.

You can also set the access level directly in the Microsoft Windows registry by using a registry editor such as regedit to edit the decimal value under HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\Workflow\Level.

For the Workflow Definitions Loader program, you set the default access level that the program operates at for downloading process definitions to a file, by defining an environment variable called WF_ACCESS_LEVEL and setting its value using the appropriate operating system command.

Caution: Although you can modify your access level, Oracle Workflow does not support any customizations to seed data originally protected at a level 99 or lower. We STRONGLY RECOMMEND that you not change your access level to an unauthorized level for modifying protected data.

Access Protection for Business Event System Data

Oracle Workflow also provides access protection for business event and event subscription definitions, in order to protect Oracle seed data and preserve your customizations in an upgrade. In the Business Event System, access protection is based on a customization level assigned to each event and subscription. The customization level determines who can update the event or subscription definition.

An event or subscription can have one of the following customization levels:

During an Oracle Workflow or Oracle Applications seed data upgrade, the Workflow XML Loader loads Business Event System object definitions in normal upload mode, preserving any customized data according to these customization levels. See: Using the Workflow XML Loader.

Related Topics

Events (for standalone Oracle Workflow), Oracle Workflow Developer's Guide

Events (for Oracle Applications), Oracle Workflow Developer's Guide

Event Subscriptions (for standalone Oracle Workflow), Oracle Workflow Developer's Guide

Event Subscriptions (for Oracle Applications), Oracle Workflow Developer's Guide

Using the Workflow Definitions Loader

Rather than use the File Save or File Open menu options in Oracle Workflow Builder, you can also run a program called Workflow Definitions Loader to save or load process definitions from a database or flat file.

Before you upgrade your database, you can use the Workflow Definitions Loader to preserve and back up your process definitions to a flat file. After the database upgrade is complete, you can use the Loader program again to upload the definitions back into your database if you need to reload your saved definitions for any reason. You can also use the Loader program to upgrade your database with a newer version of a process definition or to transfer process definitions to other databases.

When you upload or upgrade a process definition, the Workflow Definitions Loader automatically validates the process definition to ensure that it conforms to specific process design rules. It performs the same validation as the Oracle Workflow Builder Verify feature. See: To Validate a Process Definition, Oracle Workflow Developer's Guide.

The standalone version of Oracle Workflow provides scripts to run the Workflow Definitions Loader. In Oracle Applications, run the Workflow Definitions Loader as a concurrent program.

Note: When you upload or upgrade a workflow definition onto an existing definition in a database, it is possible that an object in the upload/upgrade definition has a Display Name that is already in use by a different object in the target database. If this occurs, the Workflow Definitions Loader automatically resolves the display name conflict by adding a '@' character to the beginning of conflicting display names in the target database. The upload/upgrade definition is then applied as is and a warning message is generated.

Note: In standalone Oracle Workflow you can use the Workflow Definitions Loader Release 2.6.4 to upload and download process definitions from the Release 2.6.4, Release 2.6.3, Release 2.6.2, Release 2.6.1, base Release 2.6, and Release 2.5 versions of the Oracle Workflow server. In Oracle Applications you can use the Workflow Definitions Loader Release 2.6.3 to upload and download process definitions from all versions of the Oracle Workflow server embedded in Oracle Applications Release 11i. However, when you use the Workflow Definitions Loader to upload process definitions to an earlier Oracle Workflow server version, those processes cannot include any new features introduced in later releases. For more details about which features you must not use with earlier versions, see: Using Oracle Workflow Builder with Different Server Versions, Oracle Workflow Developer's Guide.

To run the Workflow Definitions Loader for the standalone version of Oracle Workflow

To run the Workflow Definitions Loader, run the wftload.sh script on UNIX or the wftload.bat script on Windows. These scripts are located in the ORACLE_HOME/wf/admin directory. Enter the following command at your operating system prompt.

Specify the following parameters for the script:

After starting, the Workflow Definitions Loader prompts you to enter the password for your Oracle Workflow database account.

The following command shows an example of how to upload a process definition on Windows.

wftload.bat /mode upload /user OWF_MGR  /connectstring 
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=wfhost.oracle.com)
(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=orawf)))" /filename 
D:\Oracle\wf\res\US\wfstd.wft

The following command shows an example of how to download process definitions on Windows.

wftload.bat /mode download /user OWF_MGR /connectstring 
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=wfhost.oracle.com)
(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=orawf)))" /language ZHT /filename 
D:\Temp\newtest.wft /itemtype WFSTD /itemtype WFPING

To run the Workflow Definitions Loader for the version of Oracle Workflow embedded in Oracle Applications

  1. Navigate to the Submit Requests form in Oracle Applications to submit the Workflow Definitions Loader 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. See: Overview of Concurrent Programs and Requests, Oracle Applications System Administrator's Guide.

  2. Submit the Workflow Definitions Loader concurrent program as a request. See: Running Reports and Programs, Oracle Applications User's Guide.

  3. In the Parameters window, enter values for the following parameters:

    Variable Description
    Mode
    • Specify "Download" to download a process definition from the database to a flat file.

    • Specify "Upgrade" to apply a seed data upgrade to a database from an input file. The Workflow Definitions Loader assumes the access level of the file's creator (seed data provider) and overwrites any objects protected at a level equal to or above the upgrade file's access level. The Loader program preserves any customizations made to customizable seed data in the database.

    • Specify "Upload" to load a process definition from a flat file into the database. The upload mode is useful to someone who is developing a workflow process. It allows the developer to save definitions to the database without concern that accidental customizations to existing objects might prevent the upload of some process definition elements. The Workflow Definitions Loader uses the access level defined by the input file to upload the process definitions from the file and therefore will overwrite objects in the database that are protected at a level equal to or higher than that file's access level.

    • Specify "Force" to force an upload of the process definitions from an input file to a database regardless of an object's protection level You should be certain that the process definition in the file is correct as it overwrites the entire process stored in the database. The Force mode is useful for fixing data integrity problems in a database with a known, reliable file backup.

    File Specify the full path and name of the file that you want to download a process definition to, or upgrade or upload a process definition from.
    Item Type If you set Mode to "Download", use the List button to choose the item type for the process definition you want to download.

    Note: When you submit the Workflow Definitions Loader from the Submit Requests form to download process definitions to a file, you can only specify to download one item type at a time. If you wish to download multiple or all item types simultaneously, you should submit the Workflow Definitions Loader concurrent program from the command line. See Step 6 below for details.

  4. Choose OK to close the Parameters window.

  5. When you finish modifying the print and run options for this request, choose Submit to submit the request.

  6. Rather than use the Submit Requests form, you can also run the Workflow Definitions Loader concurrent program from the command line by entering the following commands:

    Replace apps/pwd with username and password to the APPS schema, replace file.wft with the file specification of a workflow process definition file, and replace ITEMTYPE1, ITEMTYPE2, ... ITEMTYPEN with the one or more item type(s) you want to download. You can also download all item types simultaneously by replacing ITEMTYPE1 with '*' (make sure you enclose the asterisk in single quotes).

    A file specification is specified as:

    @<application_short_name>:[<dir>/.../]file.ext
    
    

    or

    <native path>
    
    

Related Topics

Overview of Oracle Workflow Access Protection

Using the Workflow XML Loader

The Workflow XML Loader is a command line utility that lets you upload and download XML definitions for Business Event System objects between a database and a flat file. When you download Business Event System object definitions from a database, Oracle Workflow saves the definitions as an XML file. When you upload object definitions to a database, Oracle Workflow loads the definitions from the source XML file into the Business Event System tables in the database, creating new definitions or updating existing definitions as necessary.

The XML definitions for Business Event System objects are structured according to the following document type definitions (DTDs):

XML files uploaded or downloaded by the Workflow XML Loader should have the extension .wfx to identify them as Workflow object XML definitions.

You can download Business Event System object definitions in either normal download mode or exact download mode.

In normal download mode, the Workflow XML Loader uses the following tokens to replace system-specific data within Business Event System object definitions. The tokens are prefixed by #.

By converting these system-specific values to tokens, the loader produces template definitions that you can use to create similar objects in other systems. When you upload object definitions that contain tokens to a database, Oracle Workflow replaces the tokens with the appropriate values for that system.

Note: Because the Workflow XML Loader replaces the global unique identifier for a subscription with a token in normal download mode, each subscription must be identified instead by a unique combination of subscribing system, source type, triggering event, source agent, phase, owner name, and owner tag. If you define several subscriptions with similar properties, ensure that each subscription has a different phase number to differentiate it from the others. Otherwise, when you upload the subscription definitions to a database, the Workflow XML Loader may overwrite one subscription with another that has the same identifying properties.

You can upload Business Event System object definitions in either normal upload mode or force upload mode.

See: Access Protection for Business Event System Data and Managing Business Events, Oracle Workflow Developer's Guide.

To Download Business Event System XML Definitions from a Database

To download Business Event System object definitions from a database to a flat XML file, you can either run the Workflow XML Loader manually, or, if you are using the standalone version of Oracle Workflow, you can use a script to run the loader.

To run the Workflow XML Loader manually, run JRE against oracle.apps.fnd.wf.WFXLoad. You must specify your CLASSPATH pointing to the Java Runtime Environment, the directory containing the Workflow JAR files, the Oracle JDBC implementation, and the following Workflow JAR files:

Note: If you are using the standalone version of Oracle Workflow, the Workflow JAR files are located in the <ORACLE_HOME>/jlib directory. If you are using the version of Oracle Workflow embedded in Oracle Applications, the Workflow JAR files are located in the <ORACLE_HOME>/wf/java/oracle/apps/fnd/wf/jar/ directory.

For example, on UNIX, use the following command to run the Workflow XML Loader:

jre -classpath "$<JREPATH>/rt.jar:$<Workflow_JAR_file_directory>:
$<Workflow_JAR_file_directory>/wfjava.jar:
$<Workflow_JAR_file_directory>/wfapi.jar:
$<ORACLE_HOME>/jdbc/lib/classes111.zip:" 
oracle.apps.fnd.wf.WFXLoad -d[e] <user> <password> 
<connect_string> <protocol> <lang> <output_file> <object> <key> 
OWNER_TAG <owner_tag>

On Windows, use the following command:

jre -classpath ";<JREPATH>\rt.jar;<Workflow_JAR_file_directory>;
<Workflow_JAR_file_directory>\wfjava.jar;
<Workflow_JAR_file_directory>\wfapi.jar;
<ORACLE_HOME>\jdbc\lib\classes111.zip;" 
oracle.apps.fnd.wf.WFXLoad -d[e] <user> <password> 
<connect_string> <protocol> <lang> <output_file> <object> <key> 
OWNER_TAG <owner_tag>

If you are using the standalone version of Oracle Workflow, you can use sample scripts called wfxload for UNIX or wfxload.bat for Windows to run the Workflow XML Loader. These scripts are located on your server in the Oracle Workflow admin subdirectory. For example, on UNIX, use the following command:

wfxload -d[e] <user> <password> <connect_string> <protocol> 
<lang> <output_file> <object> <key> OWNER_TAG <owner_tag>

On Windows, use the following command:

wfxload.bat -d[e] <user> <password> <connect_string> 
<protocol> <lang> <output_file> <object> <key> 
OWNER_TAG <owner_tag>

When running the Workflow XML Loader, use either the -d option or the -de option to specify the download mode that you want.

Additionally, replace the variables in the download command with your parameters as follows:

Note: To report more extensive debugging information in the program output, you can run the Workflow XML Loader in debug mode by including the DebugMode argument just before the -d or -de option. For example, use the following command:

jre -classpath <classpath> oracle.apps.fnd.wf.WFXLoad 
DebugMode -d[e] <user> <password> <connect_string> 
<protocol> <lang> <output_file> <object> <key> 
OWNER_TAG <owner_tag>

Attention: To use the Workflow XML Loader in download mode, your Oracle Database version must be Oracle8i Database Release 3 (8.1.7) or higher.. The download utility is not supported for earlier versions of Oracle8i Database. To replicate Business Event System objects from one system to another for earlier database versions, you should follow the steps to synchronize systems using predefined subscriptions provided with the Business Event System. See: Synchronizing Systems, Oracle Workflow Developer's Guide.

You can, however, use the Workflow XML Loader in upload mode with versions of Oracle8i Database earlier than Release 3 (8.1.7).

To Upload Business Event System XML Definitions to a Database

To upload Business Event System object definitions from an XML file to a database, you can either run the Workflow XML Loader manually, or, if you are using the standalone version of Oracle Workflow, you can use a script to run the loader.

To run the Workflow XML Loader manually, run JRE against oracle.apps.fnd.wf.WFXLoad. You must specify your CLASSPATH pointing to the Java Runtime Environment, the directory containing the Workflow JAR files, the Oracle JDBC implementation, and the following Workflow JAR files:

Note: If you are using the standalone version of Oracle Workflow, the Workflow JAR files are located in the <ORACLE_HOME>/jlib directory. If you are using the version of Oracle Workflow embedded in Oracle Applications, the Workflow JAR files are located in the <ORACLE_HOME>/wf/java/oracle/apps/fnd/wf/jar/ directory.

For example, on UNIX, use the following command to run the Workflow XML Loader:

jre -classpath "$<JREPATH>/rt.jar:$<Workflow_JAR_file_directory>:
$<Workflow_JAR_file_directory>/wfjava.jar:
$<Workflow_JAR_file_directory>/wfapi.jar:
$<ORACLE_HOME>/jdbc/lib/classes111.zip:" 
oracle.apps.fnd.wf.WFXLoad -u[f] <user> <password> 
<connect_string> <protocol> <lang> <source_file>

On Windows, use the following command:

jre -classpath ";<JREPATH>\rt.jar;<Workflow_JAR_file_directory>;
<Workflow_JAR_file_directory>\wfjava.jar;
<Workflow_JAR_file_directory>\wfapi.jar;
<ORACLE_HOME>\jdbc\lib\classes111.zip;" 
oracle.apps.fnd.wf.WFXLoad -u[f] <user> <password> 
<connect_string> <protocol> <lang> <source_file>

If you are using the standalone version of Oracle Workflow, you can use sample scripts called wfxload for UNIX or wfxload.bat for Windows to run the Workflow XML Loader. These scripts are located on your server in the Oracle Workflow admin subdirectory. For example, on UNIX, use the following command:

wfxload -u[f] <user> <password> <connect_string> <protocol> 
<lang> <source_file>

On Windows, use the following command:

wfxload.bat -u[f] <user> <password> <connect_string> 
<protocol> <lang> <source_file>

When running the Workflow XML Loader, use either the -u option or the -uf option to specify the upload mode that you want.

Additionally, replace the variables with your parameters as follows:

Each subscription definition that you want to upload must include a phase number, owner name, and owner tag. The Workflow XML Loader cannot upload a source file containing subscription definitions that are missing this information.

If the source file contains subscription definitions downloaded in exact mode, the subscriptions are loaded into the Business Event System tables according to their global unique identifiers. However, if the subscription definitions were downloaded in normal mode, using tokens, each subscription is identified instead by a unique combination of subscribing system, source type, triggering event, source agent, phase, owner name, and owner tag. If you define several subscriptions with similar properties, ensure that each subscription has a different phase number to differentiate it from the others. Otherwise, during upload, the Workflow XML Loader may overwrite one subscription with another that has the same identifying properties.

Note: To report more extensive debugging information in the program output, you can run the Workflow XML Loader in debug mode by including the DebugMode argument just before the -u option. For example, use the following command:

jre -classpath <classpath> oracle.apps.fnd.wf.WFXLoad 
DebugMode -u[f] <user> <password> <connect_string> 
<protocol> <lang> <source_file>