Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform.
The Workflow Building Block enables the creation and automatic execution of business processes. Any application used to implement the Workflow Building Block specification must provide the following Key Digital Functionalities.
Workflow Building Block candidates must allow business users to create arbitrary workflow processes. These processes must be able to perform calculations, make API requests (e.g. Hypertext Transfer Protocol Secure, HTTPS) make HTTP requests, and execute scripts.
Workflow Building Block candidates (to differentiate themselves from mere business-process modelling tools) must be able to execute workflow processes:
via web API,
via manual interaction (click to run),
or via the passage of time.
Workflow Building Block candidates must allow business users to monitor the status of process instances.
Workflow Building Block candidates must provide an API which allows another application or developer to find a list of all available workflow processes for a given project or workspace.
This section provides context for this Building Block.
The Workflow Building Block helps to drive efficiency within GovStack by providing automation and orchestration capabilities for specified business processes within and across Building Blocks. The Workflow Building Block provides design-time mapping & modeling of business processes based on mature open standards like Business Process Model and Notation (BPMN) and facilitates the run-time execution of deployed workflows in order to orchestrate process flows from initiation to completion.
The Workflow Building Block 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.
It is important to note that from the perspective of the Workflow Building Block, 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 Information Mediator).
From the high-level view, we should recognize that some instances of a Workflow Building Block 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 Workflow Building Block is authorized to access the service at MoI (via the Information Mediator) then it will work just fine.
It should be noted that candidate applications playing the role of the Workflow Building Block are not always responsible for controlling the logical flow of data or automation of business processes.
There are many cases where a Building Block application will make a request to another GovStack service (via the Information Mediator) or to an external service (via an API gateway, for example) which does not involve workflow at all.
There are also plenty of cases where some slightly more complex automation will be a natural, already existing, in-built feature of some other application that's playing the role of, e.g. the Messaging specification. Let's consider an example.
The messaging spec might require that candidates be able to send SMS messages.
The Messaging Building Block might not require that all candidates be able to send a message, wait for a reply, and then send a canned response based on the reply.
But the logic defined in point 2 is so common in the messaging world, it would not be surprising to find that many Messaging Building Block candidates provide this type of business logic automation "out-of-the-box".
In this case, we'd expect an implementer to use that out-of-the-box functionality rather than also deploying a workflow engine candidate alongside the messaging candidate.
However, and this is the important part, if that feature (automating the logic in step 2) was not already part of an existing digital public good, we would recommend that a GovStack implementer should deliver that business process automation using a workflow engine, rather than making costly extensions to the candidate application itself. I.e., don't code new business logic if you don't have to and there's not high re-use value. Use a workflow engine. That's what it's there for.
The only caveat to point 4 is that certain "built-in" business logic automation provided by other applications might be avoided if you're opting for a GovStack implementation style in which a very large portion of interactions are catalogued in the audit trails generated by independent security servers. Then, even though the "built-in" logic is more convenient and affordable, you'd opt to activate a workflow process stored in a workflow engine candidate to generate a more robust audit trail.
The “Process Visit & Request Child Counselor” process is implemented using a Workflow Building Block installed at the Ministry of Health.
Receive webhook event from clinic system with a new patient visit.
Make GET request to another Ministry of Health API to retrieve full patient data.
Find patient date_of_birth in the response to the above request, calculate age from date of birth.
Make a POST request to the Ministry of Insurance with patient_id and age to register the visit.
Make a POST request to a Messaging Building Block to send an SMS to the patient.
If the patient’s age is less than 18, make a POST request to a Messaging Building Block to send an email to staff members at the clinic requesting a child counselor to be assigned to this patient.
Make a POST request to the original clinic system, notifying them that the workflow process has been completed.
This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block.
The cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the architecture specification document.
Personal data must be kept private and never shared with any parties, except where specific authorization has been granted.
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 should be available and easily accessible.
The Workflow Building Block 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 not to 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).
Terminology used within this specification.
The Workflow Building 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.
Bearing this in mind, it is still useful to have shorthand terminology to refer to a collection of activities, or a single activity relative to some linguistic scope that’s being applied in conversation.
To achieve infinite “nestability” and enable conversational coherence for human beings, we have settled on two terms to refer to:
activity: a step, relative to some multi-step workflow.
process: a multi-step workflow itself, or a collection of steps.
A business process is defined as a set of one or more linked activities that 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.
An asynchronous process is the default process type for the Workflow Building Block, 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.
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.
Activity 1: jump in water
Activity 2: swim 1 mile east
Activity 3: get out of water
Activity 4: add 3 + 2
Activity 5:
if (state.hasElectronicRegistration)
then: execute “Process C”
else: execute “Process D”
Activity 1: turn off light
Activity 2: execute “Process A”
Activity 3: multiply 7 * 5
Activity 4: Run arbitrary NodeJs script “myScript.js” with input X
Activity 5: make HTTP post request to server Y
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).
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.
A “service-driven activity” is an activity that is completed by a machine.
An instance, or “process instance” is the unique thread of execution of a process. It has input data, a start time, an end time, a log, an exit code, and other attributes. There may be N number of instances for a given process.
Consider a “Register Newborn Child” process and consider that 50 babies are born today. We may see 50 instances of this 1 “Register Newborn Child” process (some instances may still be running, some may have been completed, some may have failed).
Process: “Registration Process”
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. A gateway enables the implementation of branching, forking, merging, and joining of paths in a business process diagram.
There are different types of Gateways. The most used is the “exclusive gateway”, which is used for creating alternative paths within a process flow. For example, exclusive decisions, or sequence flow looping.
Another type is the “inclusive gateway” where all condition expressions are evaluated. Since each alternative path is independent, any combination of the outgoing paths may be taken.
The Gateways do not represent work that is done and they are not expected to have any effect on the operational measures of the process to be executed (costs, time, etc.).
An exclusive gateway is a point of diversion for a business process flow. For a given instance of the process, only one of the paths can be taken. An exclusive gateway may be used to achieve “looping” or “iteration” because if a condition is not met, the “next step” in the process may be another part of the process that provides a “way back” to the gateway in question after other activities are completed.
Unlike the exclusive gateway, an inclusive gateway may trigger the execution of more than one out-going flow. Since an inclusive gateway may trigger more than one out-going flow, the condition-checking process is a bit different from the exclusive gateway. Under an inclusive gateway, all the out-going conditions will be evaluated.
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).
A specific Event, usually the receipt of a Message, determines the path that will be taken. Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway.
A parallel gateway is used to visualize the concurrent execution of activities and is used in pairs. When the process arrives at the “parallel gateway node”, all the outgoing flows exhibited from the gateway will be executed simultaneously. The flow will be merged at the “joining parallel gateway”.
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.
Consider a process that contains an activity to “send an SMS to a patient”. The process definition may dictate “send SMS to state.patient.ssid” and when the process is instantiated with the initial state from patient A’s clinical visit, the recipient of that SMS will be different from when the same process is instantiated with the initial state from patient B’s clinic visit (i.e., one process with two instances and SMSs sent to two different people).
Below, the same process (Process 1) sends an SMS to two different people depending on the initial state it receives from in the triggering webhook event.
E.g.: Start the beneficiary scoring for beneficiary X:
Make POST to /API/workflow/beneficiary-scoring-process with the following body:
The process should be built with knowledge (in so far as it’s needed) of the initial state that will be provided when it is called/a new instance is created.
The final activity in this process might be:
MAKE A POST to `${state.callbackUrl}/${state.id} with BODY { “score”: state.finalScore }
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.
At multiple points in this document we refer to BPMN and many elements of the terminology section are terms borrowed directly from BPMN. See a list of all standards we use in the “Standards” section, and view the BPMN 2.022.0 spec.
These terms may be defined in later versions of the specification. Proposals are welcome.
A sequence flow is used to connect flow objects in a process or choreography to show the flow. A sequence flow is used to connect flow elements. It is shown in a solid line with an arrowhead. It shows the order of flow elements.
Message flow is used to show the flow of messages between separate pools/lanes. You cannot use message flow to connect flow objects within the same participant.
A process model, often depicted using Business Process Mapping Notation (BPMN) is a design output that depicts the steps of a business process from end to end.
A token is an abstract concept in BPMN. A token, formally referred to as a process token, refers to the current activity being executed within a process instance. A business process can have multiple tokens that indicate that the process is running in multiple paths. For example, gateways are often used to split the path of a process. Splitting a process path creates multiple process tokens.
Note that a single token will have at least three attributes: id, processInstanceId, and activityId. If a gateway is used to “split” a process, there may exist multiple tokens per process instance.
A pool in Business Process Model & Notation (BPMN) represents a participant in business collaboration. In a BPMN model (or diagram) a pool can represent an entity like a company, a role (e.g a buyer, seller, or customer), or even a system (e.g., OpenMRS API).
A BPMN Lane is a sub-partition within a Pool (see above) which extends the entire length of the Pool, either horizontally or vertically. Lanes are used to organize and categorize Activities within a Pool. In practice, lanes are commonly used for allocating activities to roles, systems, or the organization’s departments.
This section provides a reference for APIs that should be implemented by this Building Block.
This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.
The GovStack non-functional requirements document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here.
All APIs will be defined using the OpenAPI (Swagger) standard. The API definitions will be hosted outside of this document. This section may provide a brief description of the required APIs. This section will primarily contain links to the GitHub repository for OpenAPI definition (YAML) files as well as to a website hosted by GovStack that provides a live API documentation portal.
This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.
The tests for the Workflow Building Block can be found in this GitHub repository.
List processes.
Retrieves the list of workflow processes deployed on the workflow engine.
Provides for each process the information: definition ID, version, status (active/suspended).
Get individual process definition.
Instantiate a process instance.
Instantiates a given process definition Id. Responds with instance Universal Unique Identifier.
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.
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.
Retrieves the status of a single process instance given an instance ID.
This section lists the technical capabilities of this Building Block.
The following Functional Requirements are grouped by the Key Digital Functionality that they support.
Must allow the design of business processes via User Interface, i.e. support creation of diagrams as it is depicted in the Business Process Model and Notation (BPMN) specification v.2.0 in section 7.3 (“BPMN Diagram Types”) with the subsequent possibility to generate from diagrams XML and/or JSON version of process definition (REQUIRED)
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 (REQUIRED)
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 (RECOMMENDED)
Should allow 5 types of decision gateways: Exclusive Gateway, Event-Based Gateway, Inclusive Gateway, and Parallel Gateway (RECOMMENDED)
Must allow the configuration and execution of an arbitrary block/script/program/component during a business process (REQUIRED)
Must allow facilitating the development of an arbitrary script (to be used for things like message translation) (REQUIRED)
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 (REQUIRED)
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 (REQUIRED)
Must be able to execute a business process (REQUIRED)
Should be able to execute a process when given a valid BPMN-compliant workflow specification (RECOMMENDED)
Must allow the initiation of an asynchronous business process via API and respond with an appropriate HTTP response code, e.g., 202/Accepted (REQUIRED)
Must allow the initial “state” (or beginning data) to be sent along with the request to initiate a process via API (REQUIRED)
Must respond with a unique instance id when a process instance is instantiated via API (REQUIRED)
Must allow the initiation of a synchronous business process via API (REQUIRED)
Must allow the definition of a cron/time-based workflow trigger via a user interface (REQUIRED)
Must allow the execution of a workflow process based on cron/timer (REQUIRED)
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 (REQUIRED)
Must allow the execution of a workflow process based on a “flow trigger” (REQUIRED)
Should allow integration with messaging channels (RECOMMENDED)
Must support sending messages between different organizations (REQUIRED)
Must support sending messages within one organization between different organizational units (REQUIRED)
Must allow an administrator to view and manage all workflow processes (both active and inactive) from their interface (REQUIRED)
Must provide a monitoring dashboard that allows an administrator user to view the existing processes and instances, the status of all instances, and the health of the system generally (REQUIRED)
Must allow an administrator to “enable” or “disable” specific processes which will then appear in the BB API spec: “/api/process” LIST for discovery (REQUIRED)
Must have an OpenIAM-compatible API for user/privilege provisioning (REQUIRED)
The following are the internal key functionalities/capabilities that orchestrate the functionality of the implementation of the Workflow Building Block:
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 Business Process Model and Notation. The repository is a general term that refers to the storage place of flow-related components of a flow definition including tasks, processes, decision gateways, etc.
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.
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, a timer, etc.
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.
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 the set maximum execution time.
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 able to facilitate common CRUD-like functionality which includes: creating new workflows, listing saved workflows, updating existing workflows, and deletion of workflows. The designer may also facilitate imports of workflows from external sources, supporting open formats like Business Process Model and Notation.
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.
Batch Queue Manager is responsible for the queuing and batch processing of workflows. It is assumed that at 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-time yet providing the required execution isolation to ensure the integrity of each workflow.
The version history table describes the major changes to the specifications between published versions.
| Version | Authors | Comment |
|---|---|---|
This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful.
Example user interfaces provide illustrative context for common functionalities.
Building a process
Adding arbitrary scripts to a process
Adding new activities to existing processes
Adding credentials for use in a process
Configuring an HTTP request as an activity in a process
Adding a conditional gateway to a process
These user interface examples are meant to aid reviewers and developers in understanding the high-level requirements of the Workflow Building Block, not to specify certain design elements or guidelines.
Link to architecture requirements document (and specific sections within that document, such as cross-functional requirements, and general recommendations).
Link to use cases document – this document may be a valuable resource while developing workflows to ensure that a variety of different use cases are covered by the Building Block definition.
Link to the Building Block criteria and maturity metrics document created by Tanvir.
Link to Low Resource Settings document.
Link to GitHub repository and OpenAPI documentation site for the Building Blocks.
This section provides information on the core data structures/data models that are used by this Building Block.
The full resource model is described in detail in the , but the following is a high-level diagram of the key entities.
The data elements listed below provide detail for the resource model defined by the swagger specification. This section lists the required fields for each resource. The data elements listed are extensible in order to respond to specific use cases, however, the data elements listed below are a minimum requirement.
Description: Represents a process that has been successfully created in a Workflow engine. This object contains important reference details like the generated process UUID (universally unique identifier), which is required to perform further operations on the process.
Description: Reference to a blueprint of a process. Contains all the fields required to create a new process for a workflow engine.
Description: Used to list a single or list of process instances that are in various states like active, suspended or stopped, in a Workflow engine.
Description: 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.
The following standards are applicable to data structures in the Workflow Building Block:
REST APIs
JSON
YAML
Note that we are not using XML.
.
.
.
The WFbb is present in multiple use cases. Use cases can be found in the and a subset of those that we focus on below can be found . These user journeys and use cases have been referenced by the authors of the specification to ensure that the functional requirements for the spec suit the needs of the proposed implementations.
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| User journey | Use-case | Capabilities | Functional requirements |
|---|
| Name | Type | Description | Notes |
|---|
| Name | Type | Description | Notes |
|---|
| Name | Type | Description | Notes |
|---|
| Name | Type | Description | Notes |
|---|
| Name | Type | Description | Notes |
|---|
0.9.2
Khaled Ben Driss, Farai Mutero, Comfort Mankga, Dr. P. S. Ramkumar, Aare Lapõnin, and Taylor Downs
Technical Reviewers: Tony Shannon, Saša Kovačević, Riham Moawad, Riham Fahmi, Aare Laponin, Manish Srivastava, Palab Saha, Surendra Singh Sucharia, Arvind Gupta, Gayatri. P., Shivank Singh Chauhan, Gavin Lyons
Initial draft for the Technical Advisory Committee review
0.9.3
Khaled Ben Driss, Farai Mutero, Comfort Mankga, Dr. P. S. Ramkumar, Aare Lapõnin, Aleksa Krolls, and Taylor Downs
Reviewer: Amy Darling
Feedback incorporated from the Technical Advisory Committee's review
1.0
Reviewers: Wesley Brown, Steve Conrad, Valeria Tafoya
Final edits to align content to specification template for GovStack 1.0 release
PPIC | Promotion | CHW uses a Education Materials Database(Content Management System/Registration) | GET resource from external system |
PPIC | Promotion | CHW selects some materials | n/a |
PPIC | Promotion | CHW Chooses a Demographic Group (contact list) from a Demographic Registry(Registration/Registry) | GET resource from external system |
PPIC | Promotion | Materials are sent to list of contacts from Demographic Group | Initiate process of sending out mails to uploaded list of contacts |
PPIC | Case Management | 1. Validate client identifier (biometrics) | If validation requires checking with multiple other applications, this might require workflow. (Must be able to start a workflow process via API. Support submission of data payload through variables) in the same API call) |
PPIC | Case Management | 3. Submit new client encounter details to case management system | If a multi-step process is required for submitting encounter details this might be handled by workflow. (Must be able to start a workflow process via API. Support submission of data payload through variables) in the same API call) |
USCT | 002: Payment (non-electronic/cash payments) | Receive trigger from Scheduling Building Block that due date has been reached | Allow the initiation of an async business process via POST to API. |
USCT | 002: Payment (non-electronic/cash payments) | Load SRIS (Social Registry Information System) workload (i.e. a list of eligible beneficiaries that are due for payment) | Make HTTP GET request |
USCT | 002: Payment (non-electronic/cash payments) | Request beneficiary payment details (from Social Registry) | Make HTTP GET request |
USCT | 002: Payment (non-electronic/cash payments) | Compute payment amount for beneficiary | Perform calculation |
USCT | 002: Payment (non-electronic/cash payments) | Generate TransactionID for payment due | Generate rand (execute script) |
USCT | 002: Payment (non-electronic/cash payments) | Request payment voucher (Payment Building Block) | Make HTTP request |
USCT | 002: Payment (non-electronic/cash payments) | Make voucher as paid (Payment Building Block) | Make HTTP request |
USCT | 002: Payment (non-electronic/cash payments) | Mark beneficiary as paid (Social Registry) | Make HTTP request |
id | integer | generated by a system surrogate primary key | Required: false. Restrictions: none. |
processRef | integer | reference to the process definition | Required: false. Restrictions: none. |
initTime | string | Initiation Timestamp | Required: false. Restrictions: none. |
state | string | see BPMN specification v.2.0 section 13.2.2 | Required: false. Restrictions: none. |
lastChangeTime | string | last change Timestamp | Required: false. Restrictions: none. |
code | string | none | Required: false. Restrictions: none. |
value | string | none | Required: false. Restrictions: none. |
PPIC | (Voucher Request) Validate the mother has completed all steps (visited a pediatrician, procured medicine and nutrition supplies, and visited the therapy center) by connecting to MCTS registry | Must be able to start a workflow process via API. Support submission of data payload through variables) in the same API call |
PPIC | (Voucher Request) Verify mother has no pending incentive voucher for this milestone? (from the MCTS registry) | Perform calculation |
PPIC | (Voucher Request) Determine payment amounts for HC worker and mother | Perform calculation |
PPIC | (Voucher Request) Generate cash payment voucher (Voucher number, QR Code, the voucher serial number and its expiry date. At this point the voucher will be flagged Pre-Activated) | Make HTTP request |
PPIC | (Payment Initiation) Submit Payments csv file for approval and budgets (From Ministry of Health to Treasury Deparment) | n/a |
PPIC | (Payment Initiation) (Iterate for reach record in CSV file) Verify payment details (ID Drectory Service) | Read from file, loop |
PPIC | (Payment Initiation) Process Payments csv approval / rejected by Treasury | Perform caculation |
PPIC | (Payment Disbursement) Submit Payment Instruction (from Disbursement Organization - Payer) to Payment Gateway (Payments Building Block supported by Workflow Building Block in the back-end) | Make HTTP request |
PPIC | (Payment Disbursement) Payment Gateway query to ID Directory Service (requesting Mobile Money provider details for mother) | n/a |
USCT | Send beneficiary data from Registration Building Block to Workflow Building Block | Must be able to start a workflow process via API. Support submission of data payload through variables) in the same API call |
USCT | Check if the beneficiary is above the age of 18 from National ID Registry | Must be able to perform an external task or similar which calls remote service (REST API). Response from Remote service should contain requested data and/or response code |
USCT | Check if the beneficiary is employed from Employment Registry | Must be able to perform an external task or similar which calls remote service (REST API). Response from Remote service should contain requested data and/or response code |
USCT | Check if the beneficiary is receiving any income from Taxk Registry | Must be able to perform an external task or similar which calls remote service (REST API). Response from Remote service should contain requested data and/or response code |
USCT | Receive trigger from Scheduling Building Block that due date has been reached | Initiate worfklow via webhook |
USCT | Load SRIS (Social Registry Information System) workload (i.e a list of eligible beneficiaries that are due for payment) | Make HTTP GET request |
USCT | Iterate through each beneficiary and compute payment amounts due to beneficiary | Perform calculation, loop |
USCT | Request payment for beneficiary (Payment Building Block) | Make HTTP POST request |
USCT | Set TransactionID for successful payment and mark beneficiary as paid (Social Registry) | Make HTTP POST request |
id | integer | generated by a system surrogate primary key | Required: false. Restrictions: none. |
processDefinition | none | Required: false. Restrictions: none. |
name | string | name of a process | Required: true. Restrictions: none. |
type | string | none | Required: true. Restrictions: none. |
version | string | none | Required: true. Restrictions: none. |
isExecutable | boolean | Specifies whether the Process is executable | Required: false. Restrictions: none. |
isClosed | boolean | whether Messages and Events, not modeled in Process, can occur when the Process is executed or performed | Required: false. Restrictions: none. |
description | string | none | Required: false. Restrictions: none. |
processBody | none | Required: false. Restrictions: none. |
processStartedBy | string | none | Required: true. Restrictions: none. |
instanceValues | none | Required: false. Restrictions: none. |
This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
There are no required internal workflows for candidate applications that implement the Workflow Building Block specification. Below is an example of how an internal workflow might run when responding to an API request.
To satisfy the initial 6.2 functional requirements a candidate application may implement the following internal workflow.
Pass in the ID of the process and it will return all information about that process
The id for a defined process in the workflow engine.
"bf20fe53-5548-11ed-9dd4-0242ac150002"process found and representation returned
generated by a system surrogate primary key
name of a process
Specifies whether the Process is executable
whether Messages and Events, not modeled in Process, can occur when the Process is executed or performed
By passing in the process instance ID, get full details on its execution, including server logs emitted.
Numeric ID of a process instance
"95aef406-3a7a-11e5-85b6-dafa20524153"A detailed process instance status object
generated by a system surrogate primary key
"020229ae-9fd5-11ed-94af-0242ac150002"reference to the process definition
"ReviewInvoice:1:bf20fe53-5548-11ed-9dd4-0242ac150002"Initiation Timestamp
"2023-11-08T17:23:00"see BPMN specification v.2.0 section 13.2.2
"running"last change Timestamp
"2023-11-08T17:23:00"Optionally include a processId in the query params to filter by that process
The id for a defined process in the workflow engine.
"bf20fe53-5548-11ed-9dd4-0242ac150002"An array of process instances
generated by a system surrogate primary key
"020229ae-9fd5-11ed-94af-0242ac150002"reference to the process definition
"ReviewInvoice:1:bf20fe53-5548-11ed-9dd4-0242ac150002"Initiation Timestamp
"2023-11-08T17:23:00"see BPMN specification v.2.0 section 13.2.2
"running"last change Timestamp
"2023-11-08T17:23:00"Listing of all processes with basic information
list of processes
generated by a system surrogate primary key
name of a process
Specifies whether the Process is executable
whether Messages and Events, not modeled in Process, can occur when the Process is executed or performed
Create a process instance and register it with the execution engine
The id for a defined process in the workflow engine.
"bf20fe53-5548-11ed-9dd4-0242ac150002"Process instance initiation payload (initial 'state' for the process)
Process started; registered for execution with unique process instance ID.
The unique process instance ID.
"95aef406-3a7a-11e5-85b6-dafa20524153"The process definition ID.
"invoice:1:15e97a1c-312d-11e5-aca3-a0e120524153"States if process instance is suspended
falseStates if process instance has ended
falseProvides the execution state of the process instance
"running"Developed by Khaled Ben Driss (Wevioo), Farai Mutero (HISP South Africa), Comfort Mankga (HISP South Africa), Dr. P. S. Ramkumar (ITU), Aare Lapõnin (Independent), and Taylor Downs (OpenFn)
