Overview of Oracle Workflow Access levels

Overview of Oracle Workflow Access Protection levels

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.

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

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

See Also

Setting Up a Default Access Level

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.

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

Preserve Customizations        Lock at this Access Level      Access Level applied to Object

                Object may be updated by any access level.

X               Object may only be updated by users with access levels equal to or higher than your current access level.

        X       Object may only be updated by users with access levels equal to or lower than your current access level.

X       X       Object cannot be updated by any access level except for your current access level.

Table 1 - 1. (Page 1 of 1)

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.

Customization Level

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.

Ways to call work flow from pl/sql

There are many ways to invoke workflow. Let’s see how we can start a workflow from pl/sql package.

Inputs needed: Obviously, validated workflow which is saved in database.

Itemkey: Get the itemkey for the workflow you want to initiate.

Process Name: Get internal name of the procedure in the workflow which you want to initiate.

Call following APIs in the given sequence.

1> wf_engine.createprocess

This API creates a new runtime instance of the workflow process, Pass the item type and item key for the workflow.

2> wf_engine.setitemuserkey

Use this API to mark the new runtime instance of the workflow process with an

end–user key

3> wf_engine.SetItemAttrText

Use this API to set values for the item type attributes defined for workflow process .E.g.: Email ID, Description defined in the workflow.

4> wf_engine.setitemowner

Use this API to set the value of owner (Of Workflow)

5> wf_core.context

In case of exception, it will help in locating source of an error.

6> wf_engine.startprocess

Use this API to invoke the workflow for the item type and item key specified.

All the APIs are explain in Oracle Workflow API Reference Guide.

---Sample Code ---

DECLARE

l_itemtype VARCHAR2(30) := 'XX_TEST';

l_itemkey VARCHAR2(300) := 'TEST';

BEGIN

Begin

wf_engine.createprocess(l_itemtype, l_itemkey, 'XX_MAIN_TEST');

Exception

when others then

dbms_output.put_line('Error in create process:' sqlerrm);

End;

BEGIN

wf_engine.setitemuserkey(itemtype => l_itemtype

,itemkey => l_itemkey

,userkey => 'USERKEY: ' l_itemkey);

EXCEPTION

when others then

dbms_output.put_line('Error in set userkey process:' sqlerrm);

END;

BEGIN

wf_engine.setitemowner(itemtype => l_itemtype

,itemkey => l_itemkey

,owner => 'SYSADMIN');

EXCEPTION

when others then

dbms_output.put_line('Error in set owner process:' sqlerrm);

END;

BEGIN

wf_engine.startprocess(l_itemtype, l_itemkey);

dbms_output.put_line('Process started');

commit;

EXCEPTION

when others then

dbms_output.put_line('Error in set owner process:' sqlerrm);

END;

END;

/

-- Download the code.

Get the Code

When to use pl/sql calls?

Pl/sql calls can be used for mass uploads (not conversion), interface with the 3rd

party systems. Also to initiate approvals and to send emails from pl/sql.

Standard API for PL/SQL Procedures in Oracle WorkFlow

Standard API for PL/SQL Procedures Called by Function Activities

All PL/SQL stored procedures that are called by function or notification activities in an Oracle Workflow process should follow this standard API format so that the Workflow Engine can properly execute the activity.

Attention: The Workflow Engine traps errors produced by function activities by setting a savepoint before each function activity. If an activity produces an unhandled exception, the engine performs a rollback to the savepoint, and sets the activity to the ERROR status. For this reason, you should never commit within the PL/SQL procedure of a function activity. The Workflow Engine never issues a commit as it is the responsibility of the calling application to commit.

For environments such as database triggers or distributed transactions that do not allow savepoints, the Workflow Engine automatically traps "Savepoint not allowed" errors and defers the execution of the activity to the background engine.

The example in this section is numbered with the notation 1--> for easy referencing. The numbers and arrows themselves are not part of the procedure.

1--> procedure <procedure name=""> (itemtype in varchar2,

                                  itemkey in varchar2,

                                  actid in number,

                                  funcmode in varchar2,

                                  resultout out varchar2) is

2--> <local declarations="">

3--> begin

      if ( funcmode = 'RUN' ) then

           <your executable="" run="" statements="">

           resultout := 'COMPLETE:<result>';

           return;

      end if;

4--> if ( funcmode = 'CANCEL' ) then

           <your cancel="" executable="" statements="">

           resultout := 'COMPLETE';

           return;

      end if;

5--> if ( funcmode = 'RESPOND' ) then

           <your executable="" respond="" statements="">

           resultout := 'COMPLETE';

           return;

      end if;

6--> if ( funcmode = 'FORWARD' ) then

           <your executable="" forward="" statements="">

           resultout := 'COMPLETE';

           return;

      end if;

7--> if ( funcmode = 'TRANSFER' ) then

           <your executable="" statements="" transfer="">

           resultout := 'COMPLETE';

           return;

      end if;

8--> if ( funcmode = 'TIMEOUT' ) then

           <your executable="" statements="" timeout="">

           if (<condition_ok_to_proceed>) then

              resultout := 'COMPLETE';

           else

              resultout := wf_engine.eng_timedout;

           end if;

           return;

      end if;

9--> if ( funcmode = '<other funcmode="">' ) then

           resultout := ' ';

           return;

      end if;

10--> exception

           when others then

            WF_CORE.CONTEXT ('<package name="">', '<procedure name="">', <itemtype>,

                            <itemkey>, to_char(<actid>), <funcmode>);

           raise;

11--> end <procedure name="">;

1--> When the Workflow Engine calls a stored procedure for a function activity, it passes four parameters to the procedure and may expect a result when the procedure completes. The parameters are defined here:

itemtype The internal name for the item type. Item types are defined in the Oracle Workflow Builder.

itemkey A string that represents a primary key generated by the workflow-enabled application for the item type. The string uniquely identifies the item within an item type.

actid The ID number of the activity from which this procedure is called.

funcmode The execution mode of the activity. If the activity is a function activity, the mode is either 'RUN' or 'CANCEL'. If the activity is a notification activity, with a post-notification function, then the mode can be 'RESPOND', 'FORWARD', 'TRANSFER', 'TIMEOUT', or 'RUN'. Other execution modes may be added in the future.

resultout If a result type is specified in the Activities properties page for the activity in the Oracle Workflow Builder, this parameter represents the expected result that is returned when the procedure completes. The possible results are:

COMPLETE:<result_code>--activity completes with the indicated result code. The result code must match one of the result codes specified in the result type of the function activity.

WAITING--activity is pending, waiting on another activity to complete before it completes. An example is the Standard 'AND' activity.

DEFERRED:<date>--activity is deferred to a background engine for execution until a given date. <date> must be of the format: to_char(<date_string>, wf_engine.date_format)

NOTIFIED:<notification_id>:<assigned_user>--an external entity is notified that an action must be performed. A notification ID and an assigned user can optionally be returned with this result. Note that the external entity must call CompleteActivity( ) to inform the Workflow Engine when the action completes.

ERROR:<error_code>--activity encounters an error and returns the indicated error code.

2--> This section declares any local arguments that are used within the procedure.

3--> The procedure body begins in this section with an IF statement. This section contains one or more executable statements that run if the value of funcmode is 'RUN'. One of the executable statements can return a result for the procedure. For example, a result can be 'COMPLETE:APPROVED'.

Note: The Workflow Engine automatically runs a post-notification function in RUN mode after the Notification System completes execution of the post-notification function in RESPOND mode. The RUN mode executable statements can perform processing such as vote tallying and determine what result to return for the notification activity.

4--> This section clears the activity and can contain executable statements that run if the value of funcmode is 'CANCEL'. Often, this section contains no executable statements to simply return a null value, but this section also provides you with the chance to 'undo' something if necessary. An activity can have a funcmode of 'CANCEL' in the special case where the activity is part of a loop that is being revisited.

The first activity in a loop must always have the Loop Reset flag checked in the Activities properties Detail page. When the Workflow Engine encounters an activity that has already run, it verifies whether the activity's Loop Reset flag is set. If the flag is set, the engine then identifies the activities that belong in that loop and sets funcmode to 'CANCEL' for those activities. Next, the engine transitions through the loop in reverse order and executes each activity in 'CANCEL' mode to clear all prior results for the activities so they can run again. See: Looping and Loop Counter Activity.

5--> This section is needed only for post-notification functions. Use this section to include execution statements that run if the value of funcmode is 'RESPOND', that is, when a RESPOND operation is performed. For example, include execution statements that validate the response of the notification. After the Notification System completes execution of the post-notification function in RESPOND mode, the Workflow Engine then runs the post-notification function again in RUN mode. See: Post-notification functions.

6--> This section is needed only for post-notification functions. Use this section to include execution statements that run if the value of funcmode is 'FORWARD', that is, when a notification's state changes to 'FORWARD'. For example, include execution statements that validate the role to which the notification is being forwarded.

7--> This section is needed only for post-notification functions. Use this section to include execution statements that run if the value of funcmode is 'TRANSFER', that is, when a notification's state changes to 'TRANSFER'. For example, include execution statements that validate the role to which the notification is being transferred.

Note: For 'RESPOND', 'FORWARD', and 'TRANSFER' funcmodes, the resultout parameter is ignored, except if the returned value looks something like 'ERROR%'. Therefore, if you do not want the Respond, Forward or Transfer operation to occur after having executed your post-notification function, you can do one of two things:

Return 'ERROR:<errcode>' in the resultout parameter to convert it to a generic exception with the errcode mentioned in the message.

Raise an exception directly in your procedure with a more informative error message. See: Post-notification Functions and Notification Model:

8--> This section is needed only for post-notification functions. Use this section to include execution statements that run if a notification activity times out. You can include logic to test whether the workflow can proceed normally, and if so, to complete the activity so that the workflow can continue to the next activity. For example, if a Voting activity times out before all recipients respond, you can include logic that determines how to interpret the responses based on the current response pool and completes the activity with the appropriate result.

You should also include logic to return a result of wf_engine.eng_timedout if the workflow cannot proceed normally. Model any subsequent behavior in your process diagram using a <timeout> transition to another activity. The Workflow Engine will follow the <timeout> transition when the result wf_engine.eng_timedout is returned.

9--> This section handles execution modes other than 'RUN', 'CANCEL', 'RESPOND', 'FORWARD', 'TRANSFER', or 'TIMEOUT'. Other execution modes may be added in the future. Since your activity does not need to implement any of these other possible modes, it should simply return null.

10--> This section calls WF_CORE.CONTEXT( ) if an exception occurs, so that you can include context information in the error stack to help you locate the source of an error. See: CONTEXT.

Welcome..

Hi Welcome to the Oracle Apps Knowledge Hub.Here in this blog you can find the stuff regarding day to day issues in oracle Apps and their solutions