the BPM freak !!

Home » BPM » Tweaking a Process Flow in Production!!

Tweaking a Process Flow in Production!!

Follow me on Twitter


Updating a Flow Rule for an Application already in Production is always a scary thing!!
Currently with the packaged products and approaches like BPM/BRM etc  it’s quite manageable, but with the rich Java J2EE based implementation involving loads of coding implementations is a Nightmare!!

Updating an existing Flow, is not that straight-forward, several other dependency and critical factors also needs to be taken into account. It’s just not about creating a “New Process Flow” and deploying the same, so that the business moves on  smoothly.

The “pain” part is handling the assignments and instances(existing work-objects) that were already created with the Old Process Flow. It has to be brought to a closure both logically and functionally. Otherwise it will give rise to Assignment Errors, Orphaned Instances, Problem Flows and many more…

So, whenever we create an updated Process Flow in the Development Environment, it just does not suffice to Test it by creating a new WorkObject and concluding from there on.
Care has to be taken, how the system or flow will react to the old work instances.

Some of the typical Flow modification scenarios can be :

  •  Removing an Assignment Shape or Routing
  •  Replacing the Assignment Shape or Routing with a new one.
  •  Removing or replacing the other wait points in the flow (Subflow, Split Join and many more)

In Pega BPM the Assignment Shapes that are created each time with Visio, or even a small replacement of the Assignment Shape with the same Title/Label – does not work out, as the VISIO creates a distinct Shape ID subject to any changes.

Pega BPM with its punchline of “Build for Change” has highlighted a set of Approaches and Guidelines to over come this Issue :
Approach 1: Using Circumstancing Feature

  • Circumstancing is an optional qualification available for all rules that allows the application to support multiple variants of a rule.
  • So, in the current Scenario we can have two variants of the Flow Rule, circumstanced based on a property flag or date.
  • The Old WokObjects can follow the Old-Flow as it is. But with the Circumstancing Flag enabled as identifier (eg: flag=”new”), the updated flow will be picked for any New Work instances that are created going forward.
  • Here we do not disturb the Existing setup, just that we tweak it and route the flow accordingly based on a flag setting.
  • Pros : Very Straight Forward and does not involve deeply nested subflows.
  • Cons : With multiple releases and enhancement in the future, the count of the multi-variant Rules will increase which might pose as a problem from the maintainance perspective. This approach should be avoided if multi level of deployments of the same flow is destined to take place in the future.

Approach 2: Adding placeholder Tickets

  • In this approach, the Old Assignment points are kept intact, while the outgoing connectors are mapped to some placeholder tickets to Move the Process Flow to a designated step and continue from there on.
  • The Ticket is more like a GoTo Statement we use in C, C++ – used to jump the pointer or control to any point within the flow.
  • Pros : The same Flow Name can be used.
  • Cons : Cluttered Vision Diagrams are produced. An moreover may not be a feasible solution depending upon the configuration changes

Approach 3: Bulk Processing Jobs.

  • Based on this Approach, all the Instances waiting at the Assignment for human intervention, are Grabbed (Open Workobject bu obtaining a Lock over it),next..the activities are designed to move the Tasks to a logical closure or next best step as a Batch Job.
  • Pros : The Flow is very Clean and is best performed as an overnight maintainance Job.
  • Cons : Quite impractical to implement from a business perspective. It’s not always possible to Grab a Lock, as other batch job instances might be working on the same work-object.

Approach 4: Freezing the Access to Rules and Versions

  • For Example:
    • There a two users “Mr.X” and “Mr.Y”.
    • Mr X is working on the Old Flow Rule while Mr Y is working on the new one.
    • Old Flow Rule is in 01-01-02 Version
    • New Flow Rule is in 01-01-03 Version
    • So, in this scenario the Access Group for the user Mr.X can be modified such that he has access only to “01-01-02” – i.e Old Flow
    • And, similarly Mr.Y has access to the Ruleset Version 01-01-03
    • This can actually solve the Issue, by freezing the Ruleset Version access for the users and reverting it back once the Flow have moved to the Next Step.
  • Pros : Easy and Quick Fix if the changes don’t go beyond the Flow Rule modifications.
  • Cons : Unintended consequences might pop up and it would be really tough to fix the same, as the higher Version of the Rule cannot be made available to the User.

Using one or an amalgamation of these approaches is a “best-fit” for updating flow rules that are already in production.

From my Personal Experience, have successfully implemented using Approach 1 – “Circumstancing”

So, here were my few thoughts, “thinking loud” from “Pega BPM” perspective.

It would be really nice to hear Stories from other BPM products like Lombardi, TIBCO, Oracle and many other…how they deal with this scenario!!

Image: David Castillo Dominici / (Scary People Image)

Happy Learning!! 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: