Notifications

2471 views

Workflow Engine Overview

 

Goal
Understand Workflow within a Glide Record.

 

The Workflow Engine in ServiceNow

The Workflow Engine runs part of the Glide Engine. To design applications or extend existing applications with Workflow Processes it is important to understand where the Workflow Engine is as part of the Glide record transaction.

This lab introduces the Glide Transaction and highlights the place and role of the Workflow Engine within that Transaction.

The Workflow Engine will always guarantee updates to the current record at the end of each process point.

The Glide Engine is data drive and so reacts to events that signal a change in the state of some data.

Glide events are insert, update, delete or cancel. These events are fired into the engine in various ways. Some examples are:

  • UI Actions:
    • A user clicks a Submit button -> an insert event fires into the Glide Engine.
    • A user clicks an Update button -> an update event fires into the Glide Engine.
    • A user clicks a Delete button -> a delete event fires into the Glide Engine.
    • A user clicks the Cancel Transaction icon  -> a cancel event fires into the Glide Engine.
  • Within Scripts:
    • A script that initializes a GlideRecord -> an insert event fires into the Glide Engine.

      GlideRecord gr = new GlideRecord (‘incident’);

      gr.initialize();

      gr.insert();

    • A Business Rule that deletes a current  -> a delete event fires into the Glide Engine.

      GlideRecord gr = new GlideRecord (‘incident’);

      gr.get(‘specify_sys_id’);

      gr.delete();

For each of these events fires into the Glide Engine a series of transformations and processes begins. One event = One Glide Transaction. As each of these events fires into the Glide Engine a series of transformations and processes begins.

 

Workflow is part of both the Data Transformation layer as a Default Workflow and part of Post Processing as a Deferred Workflow. In either case the Workflow Engine, along with other engines such as Field Normalizaiton and Data Policy, are sandwiched between two sets of business rules.

The Order value of Business Rules determine their order of execution around the sandwiched engines. Business Rules that are ordered less than 1000 will run before the other engines, including Workflow. Business Rules that are order greater than or equal to 1000 will run after other engines, including Workflow.

Both Business Rules and Workflows can be configured to run before data is stored (transformation) or after data is stored (post processors).

To configure a Business Rule to run before data is stored, check the Before check box on the form.

By default, Workflows will run before data is stored.

To configure a Business Rule to run after data is stored, check the After check box on the form.

To configure a Workflow to run after data is stored, check the Run After Business Rules box on the Workflow Properties form.

NOTE: We will be looking at each of this specifically in just a bit.

If we were to add more detail to the graphic of a transaction, it would look like this.

 

As a Workflow Designer it is important to understand the timing of each participant in the Glide Transaction.

A Deferred Workflow, that is one that runs after the database operation, will still ensure the preservation of changes to the current record, that preservation is not part of the same database transaction. Remember: One event = One Glide Transaction. Since the data is already stored when a Deferred Workflow is called, the Workflow Engine forces a second update event. However, this update event will begin an independent and nested transaction, which will complete before the After Business Rules ordered greater than or equal to 1000 of the original event fire.

 

 

NOTE: Because the Default Workflow runs as part of a database event and because a Deferred Workflow performs its own nested update of current, it is never necessary to call current.update(); anywhere within a Workflow Activity Script field.

Keep in mind that every call to update() creates an independent update event. As an independent event it will cause an unnecessary nested update that will affect the performance of your application.

One event = One Glide Transaction

It is important as a Workflow Designer within an application to be aware of what Business Rules and Engines are also in the Application and what effect each may have on the data that drives the process.

A Workflow Designer needs to be able to predict when and how data is being transformed and by which process player. It is equally important, depending on the complexity of the application, to know when other nodes or threads will have access to that data.

 

NOTE: Most business processes work very well with Default Workflow. If you choose to configure a Workflow to be a Deferred Workflow, beware of the timing of the two updates on the current record.

If there is not a Deferred Workflow assigned to a Glide Record in the Post Processing phase of the Glide Transition, there will be no updateto the current record by default. The best use of the Post Processing phase of the Glide Transaction is to react to the data change not continue to change it.

Article Information

Last Updated:2016-05-13 11:58:00
Published:2014-05-16