Deployability via container

Availability of an adapter or native interfacing support

Testing to be done

Fulfillment of MUST Key Digital Functionalities stated in the respective BB specifications

3 out of 4

Fulfillment of Service API requirements (using the provided test harness)

4 out of 5

Fulfillment of MUST cross-cutting and functional requirements stated in the respective BB specifications

16 out of 21

Fulfillment of SHOULD cross-cutting and functional requirements stated in the respective BB specifications

1 out of 3

Fulfillment of MUST cross-cutting requirement stated in the Architecture BB specifications

Fulfillment of SHOULD cross-cutting requirements stated in the Architecture BB specifications

Usage rights (proprietary or FOSS license) of the software are stated.

https://github.com/egovernments/DIGIT-OSS/blob/master/LICENSE

Documentation for deployment, integration and configuration (incl. examples) is provided.

https://core.digit.org/platform/core-services/workflow-service

Functionality

DIGIT compliance

Comments

Allow business users to define and create arbitrary workflow processes (1) that can be instantiated via API, via manual interaction, or via the passage of time

Partial

Can be instantiated via API only

Allow business users to define and create arbitrary workflow processes (2) that can perform calculations, make API requests (e.g HTTPS) make HTTP requests, and execute scripts

This is not satisfied by just Workflow alone but by a bundle of services along with Workflow.

Allow business users to monitor the status of process instances

Partial

Business users will be able to monitor the process instances at their business usage level by querying workflow status etc. But Workflow does not have a standalone UI as such.

Allow other applications to discover existing processes via API

We have decomissioned general search for workflows across modules as that leads to performance problems. If a module code is passed, then we will return all workflows configured for that module.

Requirement

DIGIT compliance

Comments

Privacy

Personal data MUST be kept private and never shared with any parties, except where specific authorization has been granted

Audit Logging

Logs MUST be kept in a database of all records that are created, updated, or deleted. Logs MUST include timestamps and identify the user and affiliation that performed the transaction

Source Code

Source code SHOULD be available and easily accessible

Performance/Scalability

The workflow BB application must support communication between multiple instances of the same application (e.g., when deployed in a high-availability environment such as a Kubernetes cluster with a load balancer) so that redundant copies of the workflow engine can guarantee to not duplicate individual activities in an instance or mistakenly create multiple instances of the same process when only one is requested. (I.E., The workflow engine must handle executing instances as “singletons” across a distributed computing environment.)

Requirement

DIGIT Compliance

Comment

MUST allow the design of business processes via UI, i.e. support creation of diagrams as it is depicted in the BPMN specification v.2.0 in the section 7.3 (“BPMN Diagram Types”) with subsequent possibility to generate from diagrams XML and/or JSON version of process definition

We do JSON config but it is not translated from any BPMN specification.

MUST be able to execute that BPMN process given a valid BPMN-compliant workflow specification

We are not BPMN compliant but we can specify and execute workflows

MUST allow users to define/execute processes using BPMN v.2.0 specification basic categories of elements such as Flow Objects, Data, Connecting Objects, Swimlanes and Artifacts

We are not BPMN compliant.

SHOULD allow users to define/execute processes using BPMN v.2.0 specification Extended Modeling Elements as it is depicted in the specification section 7.2.2

We are not BPMN compliant.

SHOULD allow 5 types of decision gateways: Exclusive Gateway, Event-Based Gateway, Inclusive Gateway, Parallel Gateway

Decision gateways in DIGIT are built in the business modules, not in workflow itself.

MUST allow the configuration and execution of an arbitrary block/script/program/component during a business process

This is handled in the business module level, not at workflow.

MUST facilitate the development of an arbitrary script (to be used for things like message translation)

Workflow along with localization will give us this functionality

MUST allow “embedded sub-processes” which depend completely on the parent process and are not reusable; however all process data used in the parent process is directly accessible by the embedded sub-process

Since business logic is not part of workflow itself, this can be handled at will by the module utilising the workflow service.

MUST allow “reusable sub-processes” which do not depend on the parent process; they are typically modeled or designed separately so that they may be used in multiple contexts; this type does not necessarily have access to the parent's data by default; explicit mapping of attributes is often required to achieve data sharing between parent and sub-process

Since business logic is not part of workflow itself, this can be handled at will by the module utilising the workflow service.

MUST allow the initiation of an asynchronous business process via API and respond with an appropriate HTTP response code, e.g., 202/Accepted

MUST allow the initial “state” (or beginning data) to be sent along with the request to initiate a process via API

MUST respond with a unique instance id when process instance is instantiated via API

MUST allow the initiation of a synchronous business process via API

This can be done at a business service level which can trigger a synchronous call to workflow etc..

MUST allow the definition of a cron/time-based workflow trigger via a user interface

A script can be written to trigger a workflow at a specific time via Cron or other means. But this is not a Workflow feature in itself.

MUST allow the execution of a workflow process based on cron/timer

A script can be written to trigger a workflow at a specific time via Cron or other means. But this is not a Workflow feature in itself. This can be part of the business module that integrates with Workflow

MUST allow the definition of a “flow-trigger” which can instantiate a process based on at least “successful completion” or “failure of/exception in” an earlier process

The linkages between various processes is handled at a business module level. Workflow doesn't have it built in. A consumer can be written to a WF topic and based on an event, some appropriate action can be taken.

MUST allow the execution of a workflow process based on a “flow-trigger”

To be handled by the business module

SHOULD allow integration with messaging channels

MUST support sending messages between different organizations

This is handled at a business module level

MUST support sending messages within one organization between different organizational units

What does this mean?

MUST provide a monitoring dashboard that allows an administrator user to view the existing processes and instances, the status of all instances, the health of the system generally, &c.

DIGIT has a dashboard service that can be setup/configured to show WF status etc..

MUST have an OpenIAM compatible API for user/privilege provisioning

Authorization is handled at a platform level, not at a workflow level. Therefore, workflow along with MDMS/Zuul can be considered a building block in DIGIT.

MUST allow an administrator to “enable” or “disable” specific processes which will then appear in the BB API spec: “/api/process” LIST for discovery

We can mark a WF as inactive and it won't show up in the list.

MUST allow an administrator to view and manage all workflow processes (both active and inactive) from their interface

We don't have a specific admin UI built-in but this can be written as an enhancement to Workflow

APIs

Description

DIGIT compliance

Comments

List processes. (GET) /processes

Retrieves the list of workflow process deployed on the workflow engine. Provides for each process the information: definition ID, version, status (active/suspended)

There is no global view of all workflows at a platform level because of performance and other considerations.

Get individual process definition. (GET) /processes/{processId}

Instantiate a process instance. (POST) /processes/{processId}/start

Instantiates a given process definition Id. Responds with instance UUID.Process variables (just a PAYLOAD object - process, should be able to extract from the payload JSON object attributes) may be supplied in the request body. If the start event has mandatory variables, the workflow engine will perform backend validation.

**List process instances. **(GET) /instances

Retrieves the list of running process instances for a given workflow process definition ID

**Get Instances workflow process by ID **(GET) /instances?processId=123

Get the status of an existing process instance by instance ID. (GET) /instances/{instanceId}. Retrieves the status of a single process instance given an instance ID