Every Service integrated with egov-workflow-v2 service needs to first define the workflow configuration which describes the states in the workflow, the action that can be taken on this states, who all can perform those action, SLA etc. This configuration is created using API’s and is stored in DB. The configuration can be created either state level or tenant level based on the requirements.
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 is added for the BusinessService API’s
Create and modify workflow configuration
Configure State level as well BusinessService level SLA
Control access to workflow actions from the configuration
Validates if the flow defined in the configuration is complete during the creation
Deploy the latest version of egov-workflow-v2 service
Add Role-Action mapping for BusinessService API’s (preferably add _create and update only for SUPERUSER. search can be added for CITIZEN and required employee roles like TL__CEMP etc. )
Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)
Add businessService persister yaml path in persister configuration
Create the businessService JSON based on product requirement. Following is a sample json of a simple 2 step workflow where an application can be applied by citizen or counter employee and then can be either rejected or approved by the approver.
Once the businessService json is created add it in the request body of _create API of workflow and call the API to create the workflow.
To update the workflow first search the workflow object using _search API and then make changes in the businessService object and then call _update using the modified search result. (States cannot be removed using _update API as it will leave applications in that state in an invalid state. In such cases first, all the applications in that state should be moved forward or backward state and then the state should be disabled through DB directly)
The workflow configuration can be used by any module which performs a sequence of operations on an application/Entity. It can be used to simulate and track processes in organisations to make it more efficient and increase accountability.
Integrating with workflow service provides a way to have a dynamic workflow configuration which can be easily modified according to the changing requirements. The modules don’t have to deal with any validations regarding workflow such as authorisation of the user to take an action if documents are required to be uploaded at certain stage etc. as they will be automatically handled by egov-workflow-v2 service based on the configuration defined. It also automatically keeps updating SLA for all applications which provide a way to track the time taken by an application to get processed.
To integrate, host of egov-workflow-v2 should be overwritten in helm chart
/egov-workflow-v2/egov-wf/businessservice/_search should be added as the endpoint for searching workflow configuration. (Other endpoints are not required once workflow configuration is created)
The configuration can be fetched by calling _search API
Title
Link
Workflow Service Documentation
Link
_create
_update
_search
(Note: All the API’s are in the same postman collection therefore the same link is added in each row)
__
This section provides a step by step guide to setting up workflows and configuring the workflows for DIGIT entities.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
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 these operations seamlessly using a predefined configuration. We will discuss how to create this configuration for a new product in this document.
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 business Service API’s
Create and modify workflow configuration according to the product requirements
Configure State level as well BusinessService level SLA to efficiently track the progress of the application
Control access to perform actions through configuration
Deploy the latest version of egov-workflow-v2 service
Add businessService persister yaml path in persister configuration
Add Role-Action mapping for BusinessService API’s
Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)
The Workflow configuration has 3 levels of hierarchy: a. BusinessService b. State c. Action The top-level object is BusinessService, it contains fields describing the workflow and list of States that are part of the workflow. The businessService can be defined at 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 of it.
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 on it.
The action object is the last object in the hierarchy, it defines the name of the action and the roles that can perform the action.
The workflow should always start from the null state as the service treats new applications as having null as the initial state. eg:
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 has already passed (generally, such actions are named SENDBACK)
SENDBACKTOCITIZEN is a special keyword for action name. This action sends back the application to the citizen’s inbox for him to take action. A new State should be created on which Citizen can take action and should be the nextState of this action. While calling this action from module assignees should be enriched by the module with the uuids of the owners of the application
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
For integration-related steps please refer to the document .
All content on this page by is licensed under a .
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
Status of the application when in the given state
docUploadRequired
Boolean flag representing if document are required to enter the state
isStartState
Boolean flag representing if the state can be used as starting state in 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 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)
Title
Link
Workflow Service Documentation
Setting Up Workflows
Link
_create
_update
_search
The objective of this functionality is to provide a mechanism to trigger action on applications that satisfy certain predefined criteria. Looking at sample use cases provided by the product team, the majority of use cases can be summarised as performing action ‘X’ on applications in state ‘Y’ and have exceeded the state SLA by ‘Z’ days. We can write one query builder which takes this state ‘Y’ and SLA exceeded by ‘Z’ as search params and then we can perform action X on the search response. This has been achieved by defining an MDMS config like below:
In the above configuration, we define the condition for triggering the escalation of applications. The above configuration triggers escalation for applications in RESOLVED state which have exceeded stateSLA by more than 1.0 day and it will trigger the escalation by performing CLOSERESOLVEDCOMPLAIN on the applications. Once the applications are escalated the processInstances are pushed on the pgr-auto-escalation topic. We have done a sample implementation for pgr-services, where we have updated persister configuration to listen on this topic and update the complaint status accordingly.
The auto-escalation for businessService PGR will be triggered when the following API is called:
Note that the businessService is a path param. (For example, if the escalation has to be done for tl-services NewTL workflow the URL will be 'http://egov-workflow-v2.egov:8080/egov-workflow-v2/egov-wf/auto/NewTL/_escalate').
These APIs have to be configured in cron job config so that they can be triggered periodically according to the requirements. Only users with role AUTO_ESCALATE can trigger auto-escalation so first create users with statelevel AUTO_ESCALATE roles first and then add that user in the userInfo of the requestInfo. This step has to be done because cron job does internal API calls and zuul won’t enrich the userInfo.
For setting up autoescalation trigger the workflow also needs to be updated. For example to add auto escalate trigger on RESOLVED state with action CLOSERESOLVEDCOMPLAIN in PGR businessService, we will have to search the businessService add the following action in actions array of RESOLVED state and call update API
Suppose an application gets auto-escalated from state ‘X' to state 'Y’, employees can look at these escalated applications through the escalate search API. The following sample cURL can be used to search auto-escalated applications of PGR module belonging to Amritsar tenant -