Maker Checker
“Maker-checker (or Maker and Checker, or 4-Eyes) is one of the central principles of authorization in the information systems of financial organizations.The principle of maker and checker means that for each transaction, there must be at least two individuals necessary for its completion. While one individual may create a transaction, the other individual should be involved in confirmation/authorization of the same. Here the segregation of duties plays an important role. In this way, strict control is kept over system software and data, keeping in mind functional division of labor between all classes of employees.” Source Wikipedia
Maker Checker functionality in oeWorkflow is achieved via a common ChangeWorkflowRequest
model where unverified changes are stored. All intermediate amendments are done on this change-request data. Once the changes are finalized and approved the changes are reflected in the main model.
Enabling maker checker on a Model
Define the workflow
The first step is to define a maker-checker process flow through the modeler. In its simplest form, the BPMN should have one authorizer user task having task category as Checker-Autofinalize.
The task category Checker-AutoFinalize makes the changes to be applied on main model when changes are approved. In case changes are rejected, the change request data is simply discarded.
Create workflow model mapping
Next, the linkage between application model and workflow process is should be defined in (WorkflowMapping
) model.
To define a Maker Checker Workflow Mapping call following API.
Url | Verb | Payload |
---|---|---|
/api/WorkflowManagers/workflow | POST | As explained below |
{
"modelName" : "...",
"version":"v2",
"operation": "...",
"workflowBody" : {
"workflowDefinitionName" : "...",
"processVariables": {
...
}
},
"remote": {
"path": "/myremote",
"method": "myRemoteMethod",
"verb": "POST"
}
}
Property | Required? | Description |
---|---|---|
modelName | Yes | Application model name. Workflow engine will enable additional maker-checker endpoints on this model. |
version | Yes | Should be v2 to enable maker-checker functionality on the model. |
operation | Yes | create : enable maker-checker for record creation, update : enable maker-checker for record update, save : enable maker-checker for record creation or update, delete : enable maker-checker for record deletion, custom : enable maker-checker for custom remote. Additional remote details are required in this case (see below). |
workflowBody.workflowDefinitionName | Yes | BPMN process name to trigger |
workflowBody.processVariables | No | Initial process variables to inject. |
makersRecall | No | Whether a change request can only be recalled by one of the user making changes to it |
mappingName | if operation: 'custom' |
associate a friendly name to the below specified remote. This name is used as part of URL path while invoking maker-checker enabled endpoint |
remote.path | if operation: 'custom' |
Custom remote API path to match when operation is custom. |
remote.method | if operation: 'custom' |
Custom remote method name to match when operation is custom. |
remote.verb | if operation: 'custom' |
Http verb to match when operation is custom |
Maker Checker API endpoints
Once a maker-checker workflow is attached to the model, following additional APIs are made available:
Verb | Url | Description |
---|---|---|
POST | /api/Model/maker-checker | Create a new record via maker-checker flow |
PUT | /api/Model/maker-checker/{id} | Update a record via maker-checker flow |
DELETE | /api/Model/maker-checker/{id}/{version} | Delete a record via maker-checker flow |
GET | /api/Model/maker-checker/{id} | Fetch record for given id. Returns a instance from Change-Request if found otherwise selects from main Model |
GET | /api/Model/maker-checker/ | Fetch all change requests |
GET | /api/Model/maker-checker/{id}/workflow | Fetch running WorkflowInstance for specified record |
GET | /api/Model/maker-checker/{id}/tasks | Fetch pending Tasks for given record |
DELETE | /api/Model/maker-checker/{id}/recall | Recall change request for specified record |
Note that the normal API end-points remain operational and can be
- either disabled (making sure that every change flows through approval cycle)
- or access-controlled (admins can make amends without need for approval) as per the application requirement.
Maker Checker lifecycle
- A change is initiated by Maker via above APIs, (let’s call it a Change Request).
- Instead of saving the changes (create/update) to main
Product
model, the instance is redirected toChangeWorkflowRequest
model which holds the data temporarily till the maker checker workflow is completed. The instance is validated before the change is accepted by system. - The workflow is triggered and Approval task is available for approval/rejection.
- At this point, maker can make further amends or recall the changes back. If changes are recalled the flow is interrupted and change request is discarded.
- If maker makes further changes, the flow is interrupted and retriggered with updates.
- Change requests can be monitored at any point by using GET api mentioned above.
- Once the Checker Auto-Finalize task is completed, depending on completion payload the changes are prepared to be either pushed to main
Product
Model or discarded completely. This finalize utility only understands two status :- approved - Changes are applied to main
Product
model. - rejected - Changes are discarded.
- approved - Changes are applied to main
- Only the maker interacts via
/api/Model/maker-checker
API. All other interaction is viaTask/{id}/complete
api.
Understanding Workflow Design Process
A maker checker process may involve multiple makers and checkers. To ease workflow design creation, a task category is introduced for User Tasks.
- Basic Task
- Choose task category as Basic Task if the created user task is not for maker-checker operations
- User Task has to be completed by providing processVariables and message
with
Task/{id}/complete
api.
- Multi Maker
- If the created user task node is for subsequent enrichment of data (additional makers), then specify the task category as Multi Maker
- User Task has to be completed by providing additional instance updates/changes as payload to
Task/{id}/complete
api. - Payload can contain additional process variables and message under
pv
andmsg
properties respectively while completing the task.
- Checker
- If the business flow involves additional intermediate verification by another user choose the task categroy as Checker.
- The approval/rejection at a Checker node simply moves the flow forward and does not apply the changes to main model.
- User Task has to be completed by providing the __action__ field
on
Task/{id}/complete
api. - By default, __action__ accepts two values approved and rejected
- Additional actions like rework etc. can be specified by defining step variable with name __action__ and type as array.
- Payload can contain additional process variables and message under
pv
andmsg
properties respectively while completing the task.
- Checker Auto Finalize
- This task is similar to Checker, the difference being it is meant for the final approver and data will be pushed to the Main Model once approver approves the data.
- Payload can contain additional process variables and message under
pv
andmsg
properties respectively while completing the task. - Any property (other than __action__, pv and msg) in payload is applied on model data. This can be used when final approver intends to make some changes while approving.
Various Scenarios
Single-Maker & Single-Checker
- Workflow
- Just one Checker Auto Finalize UserTask node. Start & End nodes are implicit for any workflow.
- Steps
- Maker initiates the change request via POST
/api/Model/maker-checker/
or PUT/api/Model/maker-checker/{id}
, for create and update respectively. - Checker will have a task in his inbox, who verifies the data posted by the maker and completes the task by providing
{"__action__":"approved"}
or{"__action__":"rejected"}
as payload. - Checker can also post additional changes as part of payload. These changes are applied on the data before being pushed on the main model. If any of these changes cause instance to go invalid, the task is not completed and appropriate error is reported.
- Maker initiates the change request via POST
Multi-Makers(2) & Single-Checker
- Workflow
- One Multi Maker and one Checker Auto Finalize UserTask node.
- Steps
- Maker initiates the change request via POST
/api/Model/maker-checker/
or PUT/api/Model/maker-checker/{id}
, for create and update respectively. - Maker2 complete the task by providing the additional updates to Task complete api.
- Checker verifies the data posted by the both makers and completes the task by providing
{"__action__":"approved"}
or{"__action__":"rejected"}
as appropriate. - Final approver can also post additional changes as part of payload. These changes are applied on the data before being pushed on the main model. If any of these changes cause instance to go invalid, the task is not completed and appropriate error is reported.
- Maker initiates the change request via POST
Multi-Makers(2) & Multi-Checker(2)
- Workflow
- One Multi Maker, one Checker and one Checker Auto Finalize UserTask node.
- Steps
- Maker initiates the change request via POST
/api/Model/maker-checker/
or PUT/api/Model/maker-checker/{id}
, for create and update respectively. - Maker2 complete the task by providing the additional updates to Task complete api.
- Checker1 verifies the data posted by the both makers and completes the task by providing
{"__action__":"approved"}
or{"__action__":"rejected"}
as appropriate. - An exclusive gateway redirects the flow to Checker-2 (approved) or Finalize Transaction service node (reject).
- Checker-2 verifies the data posted by the both makers and completes the task by providing
{"__action__":"approved"}
or{"__action__":"rejected"}
as appropriate. - Checker-2 can also post additional changes as part of payload. These changes are applied on the data before being pushed on the main model. If any of these changes cause instance to go invalid, the task is not completed and appropriate error is reported.
- Maker initiates the change request via POST
Maker Checker with Rework
While approved and rejected are two actions implicitly understood by the maker-checker flow (Checker and Checker Auto Finalize tasks), some times additional actions may be required like rework.
To handle these scenario,
- Specify additional actions as Step Variables on the checker task.
- Use
Exclusive Gateway
to redirect the flow appropriately
In above flow, the first level checker can approve, reject or send back for rework.
- when approved, the flow moves forward to final approver.
- when rejected, a finalize transaction connector handles the modification cleanup.
- on rework we redirect the flow to Maker 2
Maker Checker on custom remote methods
Refer this guide for details.