Flowable: Deploying workflow model in Multi tenant environment

I have seen various scenarios where workflows engines are used. In some places, people use it for coordinating their multiple micro-services, while others use it orchestrating long-running processes.

Whatever might be the case, in a general IT environment, you cannot directly model your workflows and hand them over to workflow engines like Flowable to execute them.

The process/case models are nothing but a declarative code that tells the engine what to do next on the occurrence of specific pre-conditions. Hence you must be as vigilant as you are with other softwares. You need to test it and ensure that it works in all possible scenarios. So before putting the workflows in action, they must go through the following software development environments -

1. dev (developers model their workflows and test)
2. sit, QA, etc (testers verify and validate the workflow against multiple scenarios)
3. uat (business checks the developed workflows)
4. prod (the ultimate zenith)

In my current organization, we use Flowable in a quite interesting way. We call it a SaaS offering of workflow execution within the organization. Basically, we provide workflow execution environment to the teams who want to integrate workflow engines with their existing product. This allows them to reduce time to go live by cutting all ops-related stuff and all other compliance requirements. As a SaaS platform, we provide each team with —

1. An isolated modelling environments
2. An isolated deployment for their workflows
3. Authentication and authorization mechanism as per organization standard.
4. Regulatory compliance.
5. and many more.

To provide teams with an isolated execution platform, Flowable has a feature called multi-tenancy. That solves most of the problems for us. But the second is a bit trickier. As a platform, we need to ensure that, each team can model their workflows and they can follow their release cycle. We didn’t want to force them to a single release cycle. So we started exploring ways to achieve it.

We did a quiet brainstorming between my colleagues and engineers from Flowable on how to tackle this particular challenge. Flowable allows you to deploy models using the following methods -

Various app deployment methods in Flowable

As you see, method 2 is more suitable in dev environments, and it’s integrated with modeling tools. Method 3, we use it to deploy models to higher environments. We use a combination of both.

App deployment pipeline

At a first glance, the app deployment pipelines look too complicated. But believe me, this is not. The whole pipeline is divided into 3 separate phases -

Development Phase

Steps 1–8, Participants — Modeler, Reviewer

This phase is quite an iterative phase. The modeler creates the workflows using all available standards supported by Flowable. At this time, the modeler uses the publish button available in the design to deploy models on Flowable work and test it. Once the models are ready, the reviewer validates against our own set of the quality matrix, suggests improvements. The quality matrix checks some generic rules such as whether an exclusive gateway has one default outgoing flow, and other use case specific implementations.

Once review comments are incorporated, models are then pushed to any version control system such as git. The 2 separate versions of the models are saved. zip version for design and bar (business archive) version to deploy on Flowable workflow engines.

Release Preparation Phase

Steps 9–11, Participants — Release Manager

Once models are ready to be published to higher environments, we create a release artifact from VCS, and push it to JFrog artifactory. Each artifact has a unique release number.

App promotion phase

Steps 12–21, Participants — Deployment Manager

We use a tool called the transporter, which allows you to trigger some scripts. You can use any alternatives, e.g. Jenkins. The deployment manager specifies the artifact version to be pushed and on which environment. The transporter reads those params, downloads artifacts, and deploys model.zip to design and model.bar to work to the specified environment.

The above method allows —

• Multiple teams to develop their models using a single instance of Design.
• Each team maintains its artifacts.
• Each team can release artifacts to higher environments without affecting another team.
• We have configured each team’s technical user to deploy on their respective tenant only. Hence no one can deploy to other tenants.
• We can use the same pipeline to handle default tenants. It is a special tenant, which hosts reusable models that can be shared with other tenants.

Going ahead we are planning to improve the existing architecture by

• Automating rules validations from the quality matrix by integrating them into the pipeline.
• Adding inspect test cases as a part of app promotion, as shown in the demo by Valentine from Flowable.

If you have any questions or suggestions, leave them in the comments sections. I would be happy to address them.

If you liked reading the current post, you should definitely read previous blog posts in this series —
Business Process Automation Solution — Then and now.
BPMN, CMMN, and DMN — Triple Crown of Process Improvement Standards.
Exception handling in workflows using Flowable.