Workflow Major Components:
Component Description
WF Builder - Graphical Interface.
- Used to Modify & create business process.
- 2 Windows available [navigator, process Diagram].
WF Engine - It is embedded in oracle DB.
- Monitors the WF status and co-‐ordinates the routing of activities.
WF Definition Loader - The utility program that moves WF definitions b/w DB and corresponding flat file representation.
- It’s a standalone server program.
- Integrated into WF builder.
Notification Systems - Automatically Notify users.
- Send Notification to individuals or roles.
- Automatic Notification forwarding.
WF Monitor - Graphically monitors & administrate workflow transactions.
- It supports the below features.
§ Java Applet: To view WF Activity diagrammatically.
§ View Transaction action history.
§ Retry / Skip Activity.
§ Resend & rerun any process.
- Action Summary of Key Activities.
Workflow Data model:
Objects Description
Item Type Classification of components that makes Workflow process.
Attribute An item type attribute is a property associated with a given item type.
A Global variable that can be used across by any activity inside WF.
Process Manages Business Process according to the business process rules defined.
It derives relationship b/w the activities.
Function An automated unit of work usually defined as a PLSQL stored procedures & functions.
Event An event activity represents a business event from the Business Event System within a workflow process.
Notification When the workflow engine reaches a notification activity, it issues a Send ( ) API call to the Notification System to send the message to an assigned performer.
Message A message is what a notification activity sends to a role in a workflow process.
Lookup
Types A lookup type is a static list of values. These lists can be referenced by activities and by item type, message or activity attributes.
Transactions The relationship b/w two activities represented by an arrow [transition].
Workflow Tables:
Table Name Description
WF_ITEM_TYPES The details of internal names of item types will be stored.
WF_ITEM_TYPES_TL Translation table for WF_ITEM_TYPES
WF_ITEM_ATTRIBUTES The details of Item attribute.
WF_ACTIVITIES The details of activities involved in business process.
WF_ACTIVITY_ATTRIBUTES The details of attributes associated with activities.
WF_ACTIVITY_TRANSITIONS The transition details b/w the activities of the process WF_PROCESS_ACTIVITIES All details of process includes Activity, sub-‐processes etc.
WF_MESSAGES The message definition details.
WF_MESSAGE_ATTRIBUTES The details about Attributes associated with Messages.
WF_LOOKUP_TYPES The details of Lookup Type definitions.
WF_LOOKUPS Details of lookup Codes created for lookup types.
WF_NOTIFICATIONS Notification details defined inside item type.
WF_NOTIFICATION_ATTRIBUTES Details of attributes associated with notification.
WF_ITEMS Information of all the workflow process & its history.
WF_ITEM_ACTIVITY_STATUSES Activity status of all activity for different item type instance.
WF_ITEM_ATTRIBUTE_VALUES The values of all the attributes associated with the item type at the particular instance.
WF_ACTIVITY_ATTR_VALUES The values of activity attributes for all the activities for different instances of the workflow items.
WF_ROUTING_RULES The routing rules defined by user like forward, re-‐assign, reject etc.
Types of Workflow Process:
Synchronous • A synchronous process is a process that can be executed without interruption from start to finish. The Workflow Engine executes a process synchronously when the process includes activities that can be completed immediately, such as function activities that are not deferred to the background engine.
• The Workflow Engine does not return control to the calling application that initiated the workflow until it completes the process.
• With a synchronous process, you can immediately check for process results that were written to item attributes or directly to the database. However, the user must wait for the process to complete.
Asynchronous • An asynchronous process is a process that the Workflow Engine cannot complete immediately because it contains activities that interrupt the flow.
• Examples of activities that force an asynchronous process include deferred activities, notifications with responses, blocking activities, and wait activities.
• Rather than waiting indefinitely when it encounters one of these activities, the Workflow Engine sets the audit tables appropriately and returns control to the calling application.
• The workflow process is left in an unfinished state until it is started again. The process can be restarted by the Notification System, such as when a user responds to a
notification; by the background engine, such as when a deferred activity is executed; or by the Business Event System, such as when an event message is de-‐queued from an inbound queue and sent to the workflow process. With an asynchronous process, the
user does not have to wait for the process to complete to continue using the application.
However, the results of the process are not available until the process is completed at a later time.
Forced Synchronous • A forced synchronous process completes in a single SQL session from start to finish and never inserts into or updates any database tables.
• As a result, the execution speed of a forced synchronous process is significantly faster than a typical synchronous process.
• The process results are available immediately upon completion. However, no audit trail is recorded.
Activity Cost:
• Each function activity and event activity has a cost associated with it. The cost is a value representing the number of seconds it takes for the Workflow Engine to execute the activity.
• If you do not know how long it takes for the Workflow Engine to perform the activity, you can enter an estimated cost and update it later as you accumulate more information about its performance. Generally, you should assign complex, long running activities a high cost.
The valid range for cost is 0 to 1,000,000.
Note** although the cost is entered and displayed in seconds in Oracle Workflow Builder, it is actually converted and stored in the database as hundredths of a second.
• In normal processing, the Workflow Engine completes the execution of a single activity before continuing to a subsequent activity.
• In some cases, an activity might take so long to process that background processing would be more appropriate.
The default threshold for the Workflow Engine is 50 hundredths of a second. Activities with a cost higher than this are deferred to background engines.
Deferred Processing:
• The engine has a deferred processing feature that allows long-‐running tasks to be handled by background engines instead of in real time. Deferring the execution of activity functions to background engines allows the Workflow Engine to move forward to process other activities that are currently active.
• The engine can be set up to operate anywhere on a continuum between processing all eligible work immediately, to processing nothing and marking all transitions as deferred.
• Each activity has a user-‐defined processing cost. You can set this cost to be small if the activity merely sets an item attribute, or you may set it to be very high if the activity performs a resource-‐intensive operation. If the result of a completed activity triggers the execution of a costly function, you might want to defer the execution of that costly function to a background engine.
• The Workflow Engine integrates with Oracle Advanced Queues to carry out deferred processing. If a function activity has a cost that exceeds the main threshold cost, the Workflow Engine marks that activity with a status of 'DEFERRED' in the workflow status tables and en-‐queues the deferred activity to a special queue for deferred activities. A special queue processor called the background engine checks and processes the activities in the 'deferred' queue. The order in which the deferred activities are processed are based on the first in, first out ordering of an activity's en-‐queue time.
Deferred Activity:
When an activity is deferred, the main Workflow Engine can then continue to the next available activity, which may occur on some other parallel branch of the process. If no other activity is available to be executed, the Workflow Engine returns control immediately to the calling application. The user remains unaware that processing is still taking place, rendering a faster execution time.
To defer an activity,
Activity Cost
>
Threshold CostThe threshold cost is a PL/SQL package variable with a default value of 50 hundredths of a second. Set a cost above this threshold for all activities that you don't want the user to wait for.
At runtime, the Workflow Engine defers any thread to the background as soon as it encounters an activity with a cost higher than the threshold. Then the background engine later identifies the process as deferred and continues its execution.
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'.
'seed data provider' -‐-‐> any organization that creates 'seed data' for other organizations ('seed data consumers') to use in defining and customizing a workflow process.
− Workflow objects definitions that can be customized.
− Workflow object definitions protected against customization.
Scenario:
There are 2 teams in my organization Global Team & Regional Team. Global Team does development across all regions where as regional team does development within their own region and not shared by other.
Consider my organization Global team using oracle std. item type in my workflow in a custom workflow process.
Now my organization wants to enable below protections,
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.
How this can be achieved?
By using Access Protection Feature in Oracle Workflow.
Access Protection Features:
1. Access Level
2. Customization Level 3. Protection 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 ranges 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
Access Level:
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.
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.
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.
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.
• 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.
Workflow Definition Loader (WFLOAD)
:We use the Workflow Definitions Loader to save or load process definitions from a database or flat file. We can also define as it is a utility that moves workflow data between a file and a database and it is also used to upgrade, upload and download the workflow data.
Usage:
• Normally when we upgrade our database, we use the Workflow Definitions Loader to preserve and back up our process definitions to a flat file. When the database upgrade is completed, we use the Loader program again to upload the definitions back into your database.
• We can also use the Loader program to upgrade our database with a newer version of a process definition or to transfer process definitions to other databases.
Modes:
The Workflow Definitions Loader automatically validates the process definition to ensure that it conforms to specific process design rules. There are four modes available with WFLOAD.These are as follows:
1) DOWNLOAD -‐ Download the WF definitions into Flat file.
2) UPGRADE – Honors both protection and customization levels of data
3) UPLOAD – Honors only protection level of data [No respect of Customization Level]
4) FORCE – Force upload regardless of protection or customization level
WFLOAD Username/password <access_level> Y <Mode> <File_name>.wft <Item_Type>
For Example,
WFLOAD apps/apps 0 Y DOWNLOAD poxwfrqa.wft POAPWF