Workflow

The Workflow BB and Registries platform are developed using the BPMN 2.0 specification, which provides a standardized graphical notation for representing business processes.

The Registries Platform does not have any implementation for personal data management and protection requirements.

The Registries Platform only supports timer triggers for business processes through the scheduler embedded within the business process. External components or applications are not available for scheduling business process executions through timer triggers.

The Registries Platform does not offer batch queue management capabilities. As a result, batch processing tasks that involve executing large volumes of data in batches may not be efficiently managed by the platform.

The Workflow Building Block (WFbb) helps to drive efficiency within GovStack by providing automation and orchestration capabilities for specified business processes within and across BBs. The Workflow BB provides design-time mapping & modeling of business processes based on mature open standards like BPMN and facilitates the run-time execution of deployed workflows in order to orchestrate process flows from initiation to completion.

Implemented

The Registries Platform provides business process modelling and execution capabilities based on BPMN standards and is powered by proved Camunda open-source software.

The WFbb helps automate and control the flow of information and activities within and across various services based on predefined protocols. Workflow “processes” involve “steps” (things to be done), “gateways” (conditional logic), and “events” (things that happen). These processes may guide software systems to automate data exchange based on certain events or conditions. In addition to accelerating and automating information flow, it can be used as a mechanism to encourage or enforce best practices such as adherence to data standards, clinical guidelines and policy.

Implemented

The Registries Platform provides extensive BPMN elements coverage, adding a set of connectors for diverse integration scenarios and commonly used activities through element templates, catalogue concepts, etc.

It is important to note that from the perspective of the WFbb, any process may be defined and may make use of APIs across several applications and ministries (so long as it has access to those APIs via the IM).

Implemented

The Registries Platform supports a variety of inter-communication scenarios including data exchange, process execution etc. for registries running on the same or different Platform instances and 3rd-party systems through REST and SOAP API protocols.

From the high-level view, we should recognize that some instances of a WFbb may be deployed, for example, in the Ministry of Health (MoH) and only access services in the MoH, but another may be deployed in the MoH and access services provided by the Ministry of Insurance (MoI). So long as MoH’s WFbb is authorized to access the service at MoI (via the Information Mediator) then it will work just fine.

Implemented

Which services would be accessed from BP steps is a responsibility of registry regulation management configuration. The Registry Platform could be deployed isolated from the internet access perimeter and operate standalone manner. At the same time, any registry instance could communicate with any other registry instance via RestAPI if such connectivity is in place.

The WFbb block is generic, flexible and un-opinionated. These aspects are crucial, as they enable many different kinds of automated processes to be designed and executed. Fundamentally, every activity in a process may itself be another process—which includes multiple activities, and so on ad infinitum.

Implemented

The Registry Platform supports calling one BP from another BP or includes one BP inside another BP.

Process
A business process is defined as a set of one or more linked activities which collectively realize a business objective. A single process may have branching logic based around “gateways” which automate decisions. Alternatively, whichever actor initiates a process may decide to initiate different (related) processes depending on different conditions or inputs.

Implemented

Complex BP could be treated as a Process. This process is also visible as a "service" in citizen or officer portals so could be used by actors (citizen or officer)

Asynchronous Process
An asynchronous process is the default process type for the WFbb, and once instantiated will return a 202/Accepted but then continue to execute the instance. Note that many asynchronous processes may include requests back to the initially requesting application, but these are new requests, not responses to the initial request.

Implemented

BP could be triggered via RestAPI in synchronous or asynchronous mode. So each BP definition could be synchronous or asynchronous at the same time. This terminology is more about BP instance execution but not about the definition of BP.

Synchronous Process
A synchronous process is a process that, once instantiated, will complete before returning a response to the request. The process instance is blocking and should be used sparingly.

Implemented

BP could be triggered via RestAPI in synchronous or asynchronous mode. So each BP definition could be synchronous or asynchronous at the same time. This terminology is more about BP instance execution but not about the definition of BP.

Activity
An “activity” is an atomic task or step in a process. An activity is created when the task cannot be broken down to a finer level of detail. Generally an application (or person) will perform the activity when executed. There may be many different types of activities.
For example, note that an activity may be another “Process” in its entirety. (N.B., in Camunda this is an “activity”, in OpenFn this is an “operation”, elsewhere it is a “step” in a process.)

Implemented

The Registries Platform supports both atomic and non-atomic activities following BPMN terminology.

User-driven activity type
A “user-driven activity” is an activity that represents the completion of some unit of offline work, done by a human being. If a user-driven activity is used in a process, the _next _activity in the process will not be initiated until the activity is marked as completed, potentially with some output data captured to be used in subsequent activities.

Implemented

The Registry Platform uses "User Task" terminology for the same thing.

Service-driven activity type
A “service-driven activity” is an activity that is completed by a machine.

Implemented

The Registries Platform supports activity through BPMN standard implementation.

Instance
An instance, or “process instance” is the unique thread of execution of a process. It has input data, a start time, end time, log, exit code, and other attributes. There may be N number of instances for a given process.

Implemented

Input data acquiring is part of BP logic, so not available via API.
Id, startTime, and status fields are available via RestAPI for a moment.

Gateway
Decision gateways are flow-control elements, which are used to control how activities interact as they converge and diverge within a process. Entered (or “triggered”) by activities, a gateway acts as a function that decides which (outgoing) path to follow based on the result of the evaluation of the given set of conditions.

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

Exclusive Gateway
An exclusive gateway is a diversion point of a business process flow. For a given instance of the process, only one of the paths can be taken.

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

Inclusive Gateway
Unlike the exclusive gateway, an inclusive gateway may trigger the execution of more than one out-going flows. Since an inclusive gateway may trigger more than one out-going flows, the condition checking process is a bit different from the exclusive gateway. Under an inclusive gateway, all the out-going conditions will be evaluated.

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

Event-based gateway
The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway).

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

Parallel Gateway
A parallel gateway is used to visualize the concurrent execution of activities and is used in pairs.

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

State
State is a JSON object which contains the required data (or input values) for a process to begin execution. When a process is instantiated (we create a new “instance”) in many cases, the initial “state” will be provided to the instance. State should be a JSON object, and activities in the process should be able to make use of this initial state—i.e, to work with “variables” that may change across each instance for the process.

Implemented

The Registries Platform supports acquiring and processing data in JSON-format during process execution providing a set of extensions and scripting functions for modelling ease.

Event
An event is something that “happens” during the course of a process. Events affect the flow of the process and usually have a cause or an impact and in general require or allow for a reaction. The term “event” is generally enough to cover many things in a process. The start of an activity, the end of an activity, the change of state of a document, a Message that arrives, etc., all could be considered Events.
Types:

• Start event

• Intermediate events

• End event

Implemented

The Registries Platform supports those concept through BPMN standard implementation.

Allow business users to define and create arbitrary workflow processes

• that can be instantiated via API, via manual interaction, or via the passage of time

• that can perform calculations, make API requests (e.g HTTPS) make HTTP requests, and execute scripts

Implemented

The Registries Platform provides administrative web interface covering data model, business process & UI forms modelling, role management, etc.

Allow business users to monitor the status of process instances

Implemented

The Registries Platform provides administrative web interface for business process execution monitoring.

Allow other applications to discover existing processes via API

Implemented

There's an access control in place, therefore none of processes will become available for execution by 3-rd party bypassing explicit permission from registry administrator. There's no public API for 3rd parties in place to discover processes deployed to particular registry instance.

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

Could be implemented

Planned to be implemented

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

Implemented

The Registries Platform provides audit capabilities keeping track over all the changes around registry data, operation context, user signing those change, etc.

Source code SHOULD be available and easily accessible

Implemented

The Registries Platform is open-source software having all components licensed under Apache 2.0 and available on GitHub official public repo.

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.)

Implemented

The Registries Platform uses "clustered" deployment model for the Workflow Engine (Multiple engine nodes + Shared Database) keeping guarantee s over process instance duplication, etc.

Scope

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

Implemented

The Registries Platform provides an administrative web interface for business process visual modelling powered by Camunda http://bpmn.io tooling.

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

Implemented

The Registries Platform supports running processes based on BPMN standard.

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

Implemented

The Registries Platform supports running processes based on BPMN standard.

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

Implemented

The Registries Platform supports running processes based on BPMN standard.

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

Implemented

The Registries Platform supports running processes based on BPMN standard.

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

Implemented

The Registries Platform supports Groovy scripting language for business logic coding with an option to enable javascript if needed

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

Implemented

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

Implemented

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

Implemented

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

Implemented

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

Implemented

The Registries Platform provides both REST and SOAP API for passing data during initial process instance execution.

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

Implemented

MUST allow the initiation of a synchronous business process via API

Implemented

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

Implemented

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

Implemented

The Registries Platform supports those concept through BPMN standard Camunda Workflow Engine implementation.

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

Implemented

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

Implemented

SHOULD allow integration with messaging channels

Implemented

Done by a basic HTTP adapter or calling RestAPI

MUST support sending messages between different organizations

Implemented

System intercommunication is supported through integration connectors usage on business process level.

MUST support sending messages within one organization between different organizational units

Implemented

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.

Implemented

The Registries Platform provides an administrative web interface for business process execution monitoring, their life-cycle, etc.

MUST have an OpenIAM compatible API for user/privilege provisioning

Implemented

The Registries Platform uses Keycloak IAM supporting variety of integration options with other IdPs

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

Implemented

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

Implemented

Internal Function Blocks

Flow Repository is the place where flow definitions are stored. This repository can be linked to related components like that validate / parse flow definitions comply with open standards like BPMN. The repository is general term that refers to the storage place of flow related component of a flow definition including tasks, processes and decision gateways e.t.c

Implemented

The Registries Platform uses Git for storing process model versions to keep track of changes and authors. Process model deployments are stored in the Workflow Engine Runtime database.

Metadata Store refers to the storage of data that an Execution Engine needs to associate with a defined workflow to facilitate successful execution. This data includes but is not limited to : input variables, constants, mathematical and/or logical functions, data objects or any important data that gives context to a given workflow.

Implemented

The Registries Platform is powered by Camunda Workflow Engine, therefore all king of runtime data is stored in process execution Runtime database.

Trigger Manager facilitates the bootstrapping or initiates the instantiation of a workflow for execution by the Execution Engine. This component should be aware of different ways that a workflow can be triggered e.g through an API call or a timer e.t.c

Could be implemented

BP triggered via Rest API of user-process-management

Execution Engine is responsible for running / executing a workflow and providing the results of the run. This component may at the very minimum execute valid atomic logical expressions defined in each workflow task or in an advanced scenario may be linked to intelligent machine learning related capabilities that may provide recommendations or suggestions for improving workflow design.

Implemented

BPMN component is responsible for running business processes, built on top of Camunda

Timer is responsible for the scheduling and initiation of time-based workflows. This component may also be responsible for the monitoring of execution time of given workflows and handling of time-out scenarios for workflows that may exceed set maximum execution time.

Not the same approach

Schedule or periodical triggering of BP could be done within BP definition itself

Workflow Designer is a graphical user interface or editor that may be used by Process Designers to build workflows and have them saved in the** Flow Repository**. This interface must be intuitive, easy to use and be able to facilitate common CRUD like functionality which include : creating new workflows, listing saved workflows, updating existing workflow and deletion of workflows.The designer may also facilitate imports of workflows from external sources, supporting open formats like BPMN.

Implemented

The Registries Platform provides an administrative web interface for business process visual modelling powered by Camunda http://bpmn.io tooling and an extensive suite of typical activities and integration connectors available for use.

Batch Queue Manager is responsible for the queuing and batch processing of workflows. It is assumed that any given time, multiple workflows may be active and may be in execution mode. Hence a queue manager that may have multi-threading capabilities may support the execution of a large number of workflow processes or tasks in real-times yet providing the required execution isolation to ensure the integrity of each workflow.

Not the same approach

We are not required to queue process instances. Usually, we queue or order user tasks to be done by an officer for example

Web API is an important component that should be designed to manage all interoperability requirements for the Workflow Building Block. This API layer should facilitate the remote initiation of workflow processes from external systems and also the exposure of workflow related data (design-time and execution time) to facilitate reporting by external systems when needed

Implemented

The Registries Platform provides API for 3rd-party integrations for data exchange and remote process execution.

Resource Model

Process

Implemented

Process Instance

Implemented

Activity

Implemented

Token

Implemented

Standards

BPMN v2.0.2 - Business Process Model and Notation (https://www.omg.org/spec/BPMN/ )

Implemented

OpenAPI ( )

Implemented

REST APIs

• JSON

• YAML

• (Note that we’re saying “no” to XML!)

Implemented

Data Elements

Process Definition

Reference to a blueprint of a process. Contains all the fields required to create a new process to a workflow engine

Implemented

Process and Process Вefinition are the same thing in Registry Platform

Process

Represents a process that has been successfully created in a Workflow engine. This object contains important reference details like the generated process uuid, which is required to perform further operations on the process

Implemented

Process and Process Вefinition are the same thing in Registry Platform

Process Instance Payload

Initiates a process execution or creates a process instance. Contains the ability to capture input values that may be required to start a new process instance

Implemented

Process Instance

Used to list a single or list of process instances that are in various states like active, suspended or stopped, in a Workflow engine

Implemented

GET /processes

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

Implemented

GET /processes/{processId}

Get individual process definition.

Implemented

POST /processes/{processId}/start

Instantiate a process instance.

• 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.

Implemented

GET /instances/

List process 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

Implemented

GET /instances/{instanceId}

Get the status of an existing process instance by instance ID.

• Retrieves the status of a single process instance given an instance ID

Implemented