Configuring Workflows For New Product/Entity

Overview

Workflow is defined as a sequence of tasks that has to be performed on an application/entity to process it. The egov-workflow-v2 is a workflow engine which helps in performing this operations seamlessly using a predefined configuration. We will discuss how to create this configuration for a new product in this document.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met:

• egov-workflow-v2 service is up and running

• Role-Action mapping are added for businessService API’s

Key Functionalities

• Create and modify workflow configuration according to the product requirements.

• Configure state-level as well BusinessService-level SLA to efficiently track progress of the application.

• Control access to perform actions through configuration.

Attribute Name	Description
tenantId	The tenantId (ULB code) for which the workflow configuration is defined.
businessService	The name of the workflow.
business	The name of the module which uses this workflow configuration.
businessServiceSla	The overall SLA to process the application (in milliseconds).
state	Name of the state.
applicationStatus	The status of the application when in the given state.
docUploadRequired	Boolean flag representing if document is required to enter the state.
isStartState	Boolean flag representing if the state can be used as a starting state in the workflow.
isTerminateState	Boolean flag representing if the state is the leaf node or end state in the workflow configuration. (No actions can be taken on states with this flag as true).
isStateUpdatable	Boolean flag representing whether data can be updated in the application when taking action on the state.
currentState	The current state on which action can be performed.
nextState	The resultant state after an action is performed.
roles	A list containing the roles which can perform the actions.
auditDetails	Contains fields to audit edits on the data (createdTime, createdBy, lastModifiedTIme, lastModifiedby).

Deployment Details

1. Deploy latest version of egov-workflow-v2 service.

2. Add businessService persister yaml path in persister configuration.

3. Add Role-Action mapping for BusinessService API’s.

4. Overwrite the egov.wf.statelevel flag (true for state level and false for tenant level).

Configuration Details

1. The Workflow configuration has 3 level of hierarchy:

a. BusinessService

b. State

c. Action

The top level object is BusinessService. It contains fields describing the workflow and a list of states that are part of the workflow. The businessService can be defined at the tenant level like pb.amritsar or at the state level like pb. All objects maintain an audit sub-object which keeps track of who is creating and updating, and the time.

{
        "tenantId": "pb.amritsar",
        "businessService": "PGR",
        "business": "pgr-services",
        "businessServiceSla": 432000000,
        "states": [...]
    }

Each state object is a valid status for the application. The state object contains the information of the state and what actions can be performed.

{
        "sla": 36000000,
        "state": "PENDINGFORASSIGNMENT",
        "applicationStatus": "PENDINGFORASSIGNMENT",
        "docUploadRequired": false,
        "isStartState": false,
        "isTerminateState": false,
        "isStateUpdatable": false,
        "actions": [...]
    }

The action object is the last object in hierarchy. It defines the name of the action and the roles that can perform the action.

{
          "action": "ASSIGN",
          "roles": [
              "GRO",
              "DGRO"
          ],
          "nextState": "PENDINGATLME",
      }

2. The workflow should always start from null state as the service treats new applications as having null as the initial state. For example:

{
                    "sla": null,
                    "state": null,
                    "applicationStatus": null,
                    "docUploadRequired": false,
                    "isStartState": true,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "action": "APPLY",
                            "nextState": "APPLIED",
                            "roles": [
                                "CITIZEN",
                                "CSR"
                            ]
                        }
                    ]
                }

3. In action object, whatever nextState is defined, the application will be sent to that state. It can be to another forward state or even some backward state from where the application have already passed. (Generally such actions are named SENDBACK).

4. SENDBACKTOCITIZEN is a special keyword for the action name. This action sends back the application to a citizen’s inbox for him/her to take action. A new state should be created on which a citizen can take action and should be the nextState of this action. While calling this action from module, the assignes should be enriched by the module with the UUIDs of the owners of the application.

Integration

For integration related steps, refer to the document "Setting Up Workflows" in the reference docs.

Reference Docs

Title	Link
Workflow Service Documentation	Workflow Service
Setting Up Workflows	Setting Up Workflows

API List

Title	Link
_create	https://www.getpostman.com/collections/8552e3de40c819e34190
_update	https://www.getpostman.com/collections/8552e3de40c819e34190
_search	https://www.getpostman.com/collections/8552e3de40c819e34190

Note: All the API’s are in the same postman collection, and hence, the same link has been added in each row.