Release 2.6.4
Part Number B15852-02
Contents
Previous
Next
| Oracle Workflow Administrator's Guide Release 2.6.4 Part Number B15852-02 | Contents | Previous | Next |
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:
Workflow object definitions that can and should be customized to meet a certain consumer's needs.
Workflow object definitions protected against customization because they represent standards that may also be upgraded in the future by the provider.
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:
Identify certain workflow objects in its custom workflow definition as corporate standards that the regional teams should adhere to and not modify.
Designate certain objects in its deployed process as customizable for the regional offices to alter to their offices' needs.
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 |
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 to download workflow process definitions from the database to a file, 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 1.
When you install the version of Oracle Workflow embedded in Oracle Applications, 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 1. 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 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.
If you check the Lock at this Access Level check box, the protection level for the object is set to your current access level. Users with an access level higher than your current access level will not be able to modify the object. These users will see a small lock on the workflow object's icon, indicating that the object can be used but not modified. For users with an access level equal to or lower than your current access level, the customization level for the object will determine whether they can modify the object.
If you do not check the Lock at this Access Level check box, the protection level for the object is set to 1000. In this case all users who are not restricted by the customization level can modify the object.
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.
If you check the Preserve Customizations check box, the customization level for the object is set to your current access level. Users with an access level lower than your current access level will not be able to modify the object. These users will see a small lock on the workflow object's icon, indicating that the object can be used but not modified. For users with an access level equal to or lower than your current access level, the protection level for the object will determine whether they can modify the object.
If you do not check the Preserve Customizations check box, the customization level for the object is set to 0. In this case all users who are not restricted by the protection level can modify the object.
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:
Allow access to everyone - By default, all users are allowed access to an object if the Preserve Customizations and the Lock at this Access Level check box are both not checked. That is, the protection level is 1000 and the customization level is 0.
Limit access to users with access levels equal to your own or higher - If you check the Preserve Customizations check box but do not check the Lock at this Access Level check box, you designate the object as being customizable by anyone with an access level equal to or higher than your current access level. However, users with a lower access level will not be able to modify the object. That is, the protection level is 1000 and the customization level is your current access level. You should only mark objects as customizable in this way if you are sure that you will not be providing upgraded versions of this object in the future that would overwrite other users' customizations to it.
Limit access to users with access levels equal to your own or lower - If you check the Lock at this Access Level check box but do not check the Preserve Customizations check box, you protect the object and ensure that the object can only be modified by users with an access level equal to or lower than your current access level. Users with a higher access level will not be able to modify the object. That is, the protection level is your current access level and the customization level is 0. 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 the Lock at this Level and Preserve Customizations check boxes, you ensure that the object cannot be modified by anyone other than users operating at your current access level. That is, the protection level and customization level are both set to your current access level.
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.
| 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.
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.
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:
Core - This level is used only for events and subscriptions seeded by Oracle. At this level, you cannot make any changes to the event or subscription definition. However, any property in the definition can be changed by an Oracle seed data upgrade.
Limit - This level is used only for events and subscriptions seeded by Oracle. At this level, you can update the event or subscription status to Enabled or Disabled, but you cannot make any other changes to the object definition. Conversely, an Oracle seed data upgrade cannot change the status setting, but can change any other property in the definition.
User - This level is automatically set for events and subscriptions that you define. At this level, you can change any property in the event or subscription definition. However, an Oracle seed data upgrade cannot make any changes in the definition.
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
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.
On Unix:
wftload.sh /mode [upload | forceupload | download]
[/effectivedate <date>] /user <user> /connectstring
<connectstring> /filename <filename> [/debug true]
/language <languagecode> [/itemtype <itemtype>]On Windows:
wftload.bat /mode [upload | forceupload | download]
[/effectivedate <date>] /user <user> /connectstring
<connectstring> /filename <filename> [/debug true]
/language <languagecode> [/itemtype <itemtype>]Specify the following parameters for the script:
/mode - Specify the mode in which to run the Workflow Definitions Loader.
upload - Use this mode to upload process definitions from an input file to a database.
This mode when developing a new workflow process or applying a seed data upgrade to a database from an input file. The Workflow Definitions Loader uses the access level specified in the input file. It overwrites any objects protected at a level equal to or above the input file’s access level, but preserves any customizations made to customizable seed data in the database.
forceupload - Use this mode to force an upload of the process definitions from an input file to a database regardless of an object's protection level.
When using forceupload mode, you should be certain that the process definition in the file is correct, because it overwrites the entire process stored in the database. The forceupload mode is useful for fixing data integrity problems in a database with a known, reliable file backup. This mode is also useful for loading process definition files from Oracle Workflow Release 1.0 or 1.0.1, which reflect an older data model.
Note: When using the forceupload mode to load a process definition file from Oracle Workflow Release 1.0 or 1.0.1 into a database, you must also complete a manual step once the definition is loaded. You must associate the lookup types that you load with an item type. To do this, in the Navigator window of Oracle Workflow Builder, drag the lookup types from the independent Lookup Types branch to a Lookup Types branch associated with an item type.
download - Use this mode to download the process definition of one or more item types from a database to an output file.
When you download a process definition, the Workflow Definitions Loader sets the output file's access level to the value stored in the WF_ACCESS_LEVEL environment variable.
/effectivedate - For download mode only, optionally include this parameter to specify the effective date of the process definition you want to download. Specify the date in the following format: YYYY/MM/DD HH24:MI:SS. If you do not include this parameter, the Workflow Definitions Loader downloads the process definition that is currently in effect.
/user - Specify the user name of your Oracle Workflow database account.
/connectstring - Specify the Oracle Net connect string for the database.
/filename - Specify the full path and name of the input file from which you want to upload or the output file to which you want to download. Workflow definition files must have the extension .wft.
/debug - Optionally include this parameter with the value true to report more extensive debugging information in the program output.
/language - For download mode only, specify the language of the definitions to download, using a language abbreviation supported by the Oracle Database. For example, specify JA for Japanese. See: Locale Data, Oracle Database Globalization Support Guide.
Do not include this parameter in upload or forceupload mode. For uploads, the Workflow Definitions Loader uses the language specified within the input file.
/itemtype - For download mode only, optionally include this parameter to specify the internal name of a particular item type that you want to download. You can include this parameter multiple times to specify multiple item types. For example:
/itemtype <item type1> /itemtype <item type2>If you do not include this parameter for download mode, the Workflow Definitions Loader downloads all item types.
Do not include this parameter in upload or forceupload mode. The Workflow Definitions Loader uploads all item types specified within the input file.
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.wftThe 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 WFPINGTo run the Workflow Definitions Loader for the version of Oracle Workflow embedded in Oracle Applications
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.
Submit the Workflow Definitions Loader concurrent program as a request. See: Running Reports and Programs, Oracle Applications User's Guide.
In the Parameters window, enter values for the following parameters:
| Variable | Description |
|---|---|
| Mode |
|
| 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. |
Choose OK to close the Parameters window.
When you finish modifying the print and run options for this request, choose Submit to submit the request.
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:
To upgrade:
WFLOAD apps/pwd 0 Y UPGRADE file.wftTo upload:
WFLOAD apps/pwd 0 Y UPLOAD file.wftTo force:
WFLOAD apps/pwd 0 Y FORCE file.wftTo download:
WFLOAD apps/pwd 0 Y DOWNLOADfile.wft ITEMTYPE1 [ITEMTYPE2 ...ITEMTYPEN]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
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):
Events - WF_EVENTS DTD, Oracle Workflow API Reference
Event group members - WF_EVENT_GROUPS DTD, Oracle Workflow API Reference
Event subscriptions - WF_EVENT_SUBSCRIPTIONS DTD, Oracle Workflow API Reference
Systems - WF_SYSTEMS DTD, Oracle Workflow API Reference
Agents - WF_AGENTS DTD, Oracle Workflow API Reference
Agent group members - WF_AGENT_GROUPS DTD, Oracle Workflow API Reference
Note: Agent groups are currently only available for the version of Oracle Workflow embedded in Oracle Applications.
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.
Normal download mode lets you save a generic copy of object definitions from one system that you can use to create similar definitions in other systems. In this mode, the Workflow XML Loader replaces certain system-specific data within the object definitions with tokens. Choose normal download mode, for example, when you want to save Business Event System object definitions from a development system as seed data that can be uploaded to a production system.
Exact download mode lets you save object definitions exactly as they are specified in the database. In this mode, the Workflow XML Loader does not convert any data to tokens; instead, all values, including system-specific values, are copied to the XML file. Choose exact download mode, for example, when you want to save Business Event System object definitions from one production system so that you can replicate them to another production system that communicates with the first.
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 #.
#NEW - Replaces the global unique identifier for an agent within an agent definition, or for an event subscription within a subscription definition.
#LOCAL - Replaces the global unique identifier for the local system wherever it appears within an agent or subscription definition.
#OWNER - Replaces the name of the schema that owns a queue when the schema appears as part of the queue name and agent address within an agent definition.
#SID - Replaces the database system identifier (SID) when it appears as part of the agent address within an agent definition.
#WF_IN - Replaces the global unique identifier for the WF_IN agent on the local system when it appears as the Source Agent, Out Agent, or To Agent within an event subscription definition.
#WF_OUT - Replaces the global unique identifier for the WF_OUT agent on the local system when it appears as the Source Agent, Out Agent, or To Agent within an event subscription definition.
#WF_ERROR - Replaces the global unique identifier for the WF_ERROR agent on the local system when it appears as the Source Agent, Out Agent, or To Agent within an event subscription definition.
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.
In normal upload mode, the Workflow XML Loader loads the object definitions from the source XML file into the Business Event System tables in the database, but does not update any event or subscription definition with a customization level of User. Oracle Workflow uses this mode to preserve your customizations during upgrades.
In force upload mode, the Workflow XML Loader loads the object definitions from the source XML file into the Business Event System tables in the database and overwrites any existing definitions, even for events or subscriptions with a customization level of User. Use this mode when you want to update the definitions for your own custom events and subscriptions.
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:
wfjava.jar - Workflow Java utilities
wfapi.jar - Workflow Java APIs
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.
-d - Normal download mode. The loader converts system-specific data within the object definitions to tokens prefixed with #, where appropriate.
-de - Exact download mode. The loader copies the object definitions exactly and does not convert any data to tokens.
Additionally, replace the variables in the download command with your parameters as follows:
<user> - The user name of your database account.
<password> - The password for your database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>For a JDBC THIN driver, you can use two different types of connect string. For the first type, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID>For the second type, the connect string should include an Oracle Net name-value pair with the host name, protocol, port number, and SID in the following format:
(description=(address=(host=<host_name>)(protocol= <protocol>)
(port=<port_number>))(connect_data=(sid=<database_SID>)))<protocol> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin.
<lang> - The abbreviation for the language of the XML file. This parameter is case insensitive. Use the standard language abbreviations for the Oracle Database, such as US for American or JA for Japanese. For a list of the standard language abbreviations, see: Locale Data, Oracle National Language Support Guide.
<output_file> - The name and full path of the output file to which you want to save the definitions. The output file should have the extension .wfx.
<object> - The type of object definitions you want to download.
EVENTS - Event and event group member definitions
SUBSCRIPTIONS - Event subscription definitions
AGENTS - Agent and system definitions, and, for Oracle Applications, agent group member definitions
Note: The Workflow XML Loader only downloads event subscription, agent, agent group member, and system definitions that belong to the local system.
<key> - An optional key to restrict the definitions that are downloaded. If you specify a key, the loader retrieves definitions only for those objects whose internal names include that key. The key value is case sensitive and cannot contain any spaces. To retrieve all object definitions of the specified type, you can omit this parameter.
Note: The Workflow XML Loader downloads event group membership information for each individual event along with that event's definition. That is, if you choose the object type EVENTS and you specify a particular event name as the key, the Workflow XML Loader downloads the event definition as well as information about the event's membership in any event groups. However, if you choose the object type EVENTS and you specify a particular event group name as the key, the Workflow XML Loader downloads only the definition of the event group itself, without any information about the member events.
OWNER_TAG <owner_tag> - An optional program ID code for the program or application that owns the object definitions you want to download. This value is case sensitive and cannot contain any spaces. If you pass this parameter, you must include the OWNER_TAG marker before the owner tag value to identify the parameter.
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:
wfjava.jar - Workflow Java utilities
wfapi.jar - Workflow Java APIs
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.
-u - Normal upload mode. The Workflow XML Loader loads the object definitions from the source XML file into the Business Event System tables in the database, but does not make any updates to events or subscriptions with a customization level of User.
-uf - Force upload mode. The Workflow XML Loader loads the object definitions from the source XML file into the Business Event System tables in the database and overwrites any existing definitions, even for events or subscriptions with a customization level of User.
Additionally, replace the variables with your parameters as follows:
<user> - The user name of your database account.
<password> - The password for your database account.
<connect_string> - The connect string for the database. The format of the connect string depends on the JDBC driver type.
For a JDBC OCI8 driver, the connect string should be the database name as specified in its TNSNAMES entry, in the following format:
<database_name>For a JDBC THIN driver, the connect string should include the host name, port number, and database system identifier (SID) in the following format:
<host_name>:<port_number>:<database_SID><protocol> - The JDBC driver type you want to use to connect to the database. The JDBC driver type can be either oci8 or thin.
<lang> - The abbreviation for the language of the XML file. This parameter is case insensitive. Use the standard language abbreviations for the Oracle Database, such as US for American or JA for Japanese. For a list of the standard language abbreviations, see: Locale Data, Oracle National Language Support Guide.
<source_file> - The name and full path of the source file from which you want to upload definitions. The source file should have the extension .wfx.
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>
