In the previous post, we dealt with how workflow functionality could synergistically combine with service orchestration to provide a more agile and richer experience to the adopting business.
It was evident that
- having a mechanism to map the entities (people and resources) involved in the process to the various tasks defined as part of the workflow definition, would be handy.
- A mechanism to impose/provide timelines by which a task in the process is expected to start and be completed
- If there is a method by which some inputs of a technical nature are required to be passed on to a subsequent task downstream in the process, that would be helpful in avoiding confusion between teams that are responsible for different tasks in that process.
The CORESTACK solution addresses all of the above. In fact it goes a step further by providing a mechanism which can be leveraged to automatically pass execution output of one task to any subsequent task without any manual intervention. This functionality helps in automation by reducing manual inputs/error.
In the cloud, let us take a scenario where a private cloud needs to be setup. At the very minimum, this would involve the below steps
- setup the network (networking team would do this via their own scripts/ templates)
- create the VM and configure the network for the VMs (virtualization team with their own script/template)
The networking and virtualization teams could have clear cut non-intersecting responsibilities and they collaborate with each other (via email, phone, in-person discussion to share their inputs/outputs with each other) to set up the private cloud.
If the workflow process can define a task that can associate it with a particular script/template, then each team would readily know which script/template they have to execute to fulfil and complete the task. It would be advantageous if the output from a particular task could be passed seamlessly as input to the subsequent task in the workflow process.
The above is achieved within CORESTACK-Workflow by using Activiti, a workflow engine. To achieve the mapping discussed above, BPMN2.0 provides for a particular task type called ‘User task’. This is the key task type that is of interest, as it marries the task definition to the user as well as to the template/script. How exactly this is achieved is proprietary stuff. For passing data from one task to another, Activiti provides APIs which CORESTACK-Workflow leverages to share runtime state data across tasks seamlessly. CORESTACK-Workflow adds its secret sauce on top of Activiti APIs to automagically pass output values from a template execution as input values for any subsequent task in its user interface! Get in touch with us to know more.
Template-based orchestration and workflows
The basic premise behind template-based orchestration solutions is, templates are more readable and intuitive than scripts. The YAML-based templates that build on the JSON data format are easier for the human-brain to comprehend than a bunch of scripts.
The DSLs that the template-based solutions invent simplify the automation scripting to a great extent, thereby reducing the need for expensive-to-hire scripting skills. Needless to add, re-usability is often a sought-after characteristic.
With the above evolution to template-based orchestration, it is logical to achieve re-usability via small templates that do specific tasks. Complex functionality is then achieved by a composition of templates that have finer-grained orchestration logic built in them. So there can be master template, which acts as a composer that calls out to other templates to achieve the overall orchestration.
Let us take the workflow model definition that was given as a sample in part-1.
- The Customer Service Representative gathers the details like application, db servers that are required to manage a distributed application in the cloud.
- The inputs then go for approval to an engagement manager, who approves or rejects it based on his team’s current capacity and capability.
- On approval, it would go to the DevOps team to deploy the necessary components on to the DB and application servers.
- The next step would be to configure the security aspects of the system like SSL, etc.
- Prior to ‘go’ the deployment architecture is checked against the requirements.
- Once the system is deployed, it then goes to the monitoring team if monitoring has been requested by the client. The monitoring agents are configured by this team
- If periodic backups have been requested, then the back-up team will come in and configure the system accordingly
- Then the usage summary is arrived at
- There will be final check against the set of requirements to ensure that all the requested services have been configured properly
In the above workflow, there are DevOps, Monitoring, Backup, Customer-facing, Engagement-Manager teams involved. The DevOps, Monitoring, Backup guys could all be having their own specialized scripts or templates for their regular work. There probably would be different administrators for each of the teams/tools and so each owner/team would have their respective specialized templates(s) or scripts to perform their specific task.
This is where we can use CORESTACK’s workflow functionality to tie the workflow task to the orchestration-related templates/scripts. When some tasks in a workflow process is attached with a corresponding template, then the workflow task’s assignee would readily know looking at the task, the particular template/script(s) that need to be executed in-order to complete the task. He/she can then feed-in the relevant values for the template and execute it. Any output values from the template execution that need to be passed on to downstream tasks can be captured and made available to the subsequent tasks automatically. CORESTACK-workflow provides the glue to achieve this value passing between tasks in a seamless manner. Indeed, all the power of the BPMN2.0 compliant Activiti workflow engine in handling conditional branching or concurrent processing can be leveraged while defining the workflow process models.
Working with CORESTACK Workflow
1. Create the process model in any BPMN2.0 workflow modelling tool. Ensure that the tasks are linked to the template via the task’s form
2. Upload the process model to CORESTACK Workflow
3. Start an instance of the deployed workflow process model in CORESTACK Workflow
4. Once the process instance is started, the tasks get created as per the process definition and is assigned to either a group or a user. If the task is assigned to a group, then a group task is created within CORESTACK workflow, otherwise an Inbox task is generated.
5. If it is a group task, the user could assign it to himself, by claiming the task. Once that is done, it becomes an Inbox task for that user.
6. The user needs to execute the CORESTACK template, if any is associated with that task and complete the task, to generate the next task in the process definition. If there are multiple templates associated with the task, then all the templates need to be executed, before the task can be completed