The Workflow Engine Model

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The workflow process is a series of tasks or actions, the order in which they must be performed, permissions defining who can perform them, and script that is executed for each action. The workflow engine is a component in the Access Workflow Designer infrastructure that makes workflow possible.

The workflow engine is used to enforce the workflow definition and execute workflow actions. When a user table is enabled for workflow, workflow insert, update, and delete triggers are created for that table. Any change made to an item in the table will execute the corresponding workflow trigger that in turn calls a stored procedure, which invokes the workflow engine.

The Workflow Engine Functions

The workflow engine has three functions. First, it verifies whether the change is valid for the current workflow state. For example, if there is no Delete action defined for the current state, the engine does not make it possible for users to delete an item in that state.

Second, it checks if the current user has permissions to execute the workflow action. For example, if the action is a transition from Active to Resolved, the engine checks if the current user is permitted to execute this particular action.

Third, if the action is valid and the user has execute permissions, then the workflow engine evaluates the Condition script. If the condition is True, it executes the action procedure. If the action completes successfully, the engine invocation returns success, and the trigger commits the change. If an error occurs while executing the Condition or Action scripts, the engine reports the error to the trigger. The trigger raises a SQL Server error and rolls back the change.

Access Workflow Designer provides three table-level options that control the way the workflow engine works. The options can be set on the General tab of the Workflow Process pane and are stored in the modObjects table.

• ****Enable workflow processing   ****Controls whether workflow is enforced for a given table. If selected (default), the engine is called for each data change. Clearing this option disables workflow processing on the associated base table, which makes it possible for database updates to be made that do not conform to the workflow rules. Use this setting if you want to suspend workflow processing while you make corrections to data in the table.

• ****Make deleted rows available to script   ****Controls whether original values (stored in the DELETED table inside the trigger) are made available at run time. If selected, the data values in a row prior to a user update, delete, or insert are available to workflow script using the Session object. Then, your script can compare values in the updated row with their original values to perform validation or other processing. Disable this option if you do not require deleted rows in your script to improve performance.

• Run workflow in a separate process   Controls whether the workflow engine is run in the same Windows NT process as SQL Server. Running in a separate process isolates the workflow code from the server and yields more robust team solutions. Running the workflow engine in the same process as SQL Server provides better performance, but errors in your workflow script could potentially interfere with SQL Server.

  It is recommended you run the workflow engine in a separate process until you have fully debugged and tested your workflow process. The default is to run in a separate process. This choice may be made on a table-by-table basis.

  ****Note   ****All workflow code runs under the context of the user account you configure for the workflow engine. The permissions granted to this account on the server depend on the team solution’s requirements and the sensitivity of other data on this computer.

Schema Requirements for Workflow

Every workflow-enabled table is required to have a status column that holds the workflow state and moves each item through the workflow process. This status column must be an integer data type and must have a foreign-key constraint with a keyword lookup table that stores the names of the workflow states. For details on data types, see Database Schema Design Guidelines.

The status column can be pre-existing or created by the Workflow Process wizard. If you are using a pre-existing column, be sure it meets the data type restrictions mentioned earlier and you have created the lookup table containing the StatusID and Status Description columns (your column names may be different).

When using the Workflow Process wizard to create a column, you enter the state names and set the order. The wizard creates the associated lookup table and assigns the values to the created states based on the order you indicated.

To enable initialization of the workflow state for existing items, the workflow engine makes it possible for transitions from Null into any valid workflow state.

For details about adding workflow, see Adding a Workflow Process to your Solution.