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.

{
  "modelName" : "...",
  "version":"v2",
  "operation": "...",
  "workflowBody" : {
    "workflowDefinitionName" : "...",
    "processVariables": {
      ...
    }
  },
  "remote": {
    "path": "/myremote",
    "method": "myRemoteMethod",
    "verb": "POST"
  }
}

Maker Checker API endpoints

Once a maker-checker workflow is attached to the model, following additional APIs are made available:

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 to ChangeWorkflowRequest 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.
• Only the maker interacts via /api/Model/maker-checker API. All other interaction is via Task/{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 and msg 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 and msg 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 and msg 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.

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.

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