aaron.labiosa@nintex.com

Defensive Workflow Design Part 5 - Batching

Blog Post created by aaron.labiosa@nintex.com Champion on Mar 6, 2017

Planning Ahead

When designing a workflow it is often assumed that the actions will be processed in the exact order they are shown in the designer. While true most of the time, if your workflow is utilizing any batched actions (see below), the actions do not always execute synchronously.

 

What is a batched action?

A batched action is any action that makes a change to a SharePoint environment. These actions are added to a batch and processed together.

 

How are batched actions handled?

SharePoint Workflow Infrastructure processes activities synchronously until it reaches a point where the workflow is blocked (Task, Pause, etc). Only at this point will SharePoint commit batched actions. Processing changes to SharePoint in batches has several advantages:

  • Processing changes in a single SQL transaction is less resource intensive than processing every change as it occurs in a workflow.

  • When SharePoint encounters an exception while executing a workflow action, it will roll all changes back to the last commit (Native SharePoint Workflow Actions only). This makes the infrastructure more durable.

Performance

While adding a commit action after every batched action will ensure things are processed in the intended order, it is not optimal. It is advised to commit the batch after a group of actions without dependencies on one another are processed.

 

Example: Several field update actions that do not rely on one another for the values that are being updated.

If a series of batched actions have dependencies on one another, a commit should be added. This will ensure that each batched action is processed before actions that depend on the values are processed.

 

Example: A field update is processed that affects a filter parameter used for a list query.

Design Considerations

  • Batched actions have the tendency to behave asynchronously in that SharePoint does not wait for them to process completely before moving on to the next action in the workflow (unless committed).

  • Commit batched actions if the values they affect are used later in the workflow. Not committing batched actions can lead to null reference exceptions in a workflow or other unexpected errors.

  • If a batched action does not have any dependencies, it can be allowed to process without a pause or commit.

Additional Reading

 

More Information

 

Defensive Workflow Design Part 1 - Workflow History Lists

Defensive Workflow Design Part 2 - SharePoint Topology

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 4 - Slow Down and Speed Up

Outcomes