Overview
Workflows can be customized by modifying the business process definition as well as the java code that the process definition is referencing. The overall process flow is handled by the business process definition whereas execution of platform actions is done within the java code.
Outlined below are various requirements that should be considered when implementing workflows. What can be implemented via workflows is very open ended. Therefore these requirements serve as a general guideline and a place to start when drafting together an initial list of workflow requirements.
Business Process Definition Requirements
The overall workflow process is determined by the business process. The business process definition is where we define what logical steps are going to occur within the workflow. The custom java components are referenced within the business process definition and will represent each of the logical steps.
Out of box we have three different workflow business processes available:
- Data Change Request
- Potential Match Review
- Recommend for Delete
All three workflow business processes follow the same flow in that there are two main steps:
- Task Creation/Assignment
- Task Resolution
The first step in these workflows is the creation step. In this step a workflow task is created and assigned an owner from a pool of candidates. When a task is assigned to a candidate that user will see the task within their inbox.
The second step is resolution. In this step the user will provide a response to the task which is either an approval or rejection of the proposed task. The resolution translates to a platform action which is facilitated by the java code. The java class used by this action is defined within the business process definition. The action within the java code is an API call to the Reltio platform and by executing this API call the task is resolved/closed.
The task creation and assignment is defined and represented as a ‘User Task’ within the workflow process definition modeler UI. The ‘User Task’ has parameters to control what users or roles will be the candidates for the task, what possible actions exist on the task (approve/reject/merge/unmerge, etc), the java class to be used to facilitate the task assignment, and several other options.
Task resolution is defined as a ‘Service Task’ within the workflow process definition modeler UI. Within the service task the java class facilitating this action is defined. No additional parameters are defined. The entire implementation for service tasks are handled within the java code.
Below is a list of possible requirements to consider when implementing workflows.
|
Requirement
|
Description
|
|
Candidate Group
|
Determine what user or security role is a candidate for the task.
|
|
Decision Types
|
What decisions should be available to task assignees? These represent the various actions (approve/reject/merge/unmerge).
|
|
Access Types
|
What access types are necessary for the roles or users acting on the workflow tasks?
|
|
Validators
|
Define any custom validation java classes. These classes will contain logic for validation.
|
|
Notifications
|
Send notifications on assignment and/or completion?
|
|
Assign to Owner
|
Decide if owners of the task should be excluded from assignment.
|
|
User Tasks
|
Are there any API calls or activities that should be considered at time of task creation?
|
|
Service Tasks
|
Are there any additional API calls or activities outside of the default OOTB code that should be considered when the service task is executed?
|
Java Class Implementation Requirements
Any platform action that the workflow process performs will be executed within the workflow java project.
Task creation is handled by the ‘TaskStartEventListener’ class and assignment is within the ‘TaskAssignmentEventListener’ class. As implied these classes are listeners, so think of them as hooks into the task creation phase of the workflow process.
Discussed below are the various actions that each of the workflows implement.
1. Data Change Request - A data change request can either be accepted or rejected. Each of these actions are applied by calling a Reltio API end-point.
ChangeRequestApply - This java class contains the API call to accept a data change request
ChangeRequestReject - This java class contains the API call to reject a data change request
2. Potential Match Review - Potential match reviews will either result in a ‘Merge’ or ‘Not a Match’. Each of these scenarios are represented by a Reltio API end-point.
Merge- This java class contains the API call to merge the entities within the match review pair.
NotAMatch- This java class contains the API call to set the match review pair as ‘Not A Match’, preventing the two entities from merging.
3. Recommend For Delete - The recommend for delete workflow is configured with two decisions, ‘delete’ or ‘cancel’, but only the ‘Delete’ has an action behind it.
Delete - This java class contains the API call to delete the entity within the workflow process instance.
|
Requirement
|
Description
|
|
Data Change Request - Accept
|
What API calls or activities should be executed when users accept data change requests?
|
|
Data Change Request - Reject
|
What API calls or activities should be executed when users reject data change requests?
|
|
Potential Match Review - Merge
|
What API calls or activities should be executed when users decide to merge records?
|
|
Potential Match Review - NotAMatch
|
What API calls or activities should be executed when users decide to not merge records?
|
|
Recommend for Delete - Delete
|
What API calls or activities should be executed when users decide to delete records?
|
|
Recommend for Delete - Cancel
|
What API calls or activities should be executed when users decide to cancel out of a deletion workflow process?
|
Related Content-
Reltio Master Data Management Match Rules - FAQ's Part 1-
Reltio Master Data Management Match Rules - FAQ's Part 2
- Step by Step Guide on Adding A New Source To Reltio
#Matching#API#implementation#Featured
#workflow#Blog