While working in a live project, there might be a requirement to close or change the status of existing issues in the MDM Administrator (MDA) interface in bulk or on ad-hoc basis automatically whenever certain criteria are met.
Some example scenarios when MDA issues require closure could be:
- Close a split proposal whenever matching attributes of instance records become the same
- Close all issues with specific data quality criteria that is no longer relevant for client. Example – Company Established Date data quality checks are not required, and client wants to close issues raised for Company Established Date.
- Close all resolved issues
To implement a solution to close issues, certain information is required:
- The database and tables where issue information is stored:
Key Issues details visible in MDA UI are stored in “dqit_issue” table in “it_db” default databases for MDA.
Note: Details of configured database can be found in the runtimeConfig file.
- Key fields in the dqit_issue database:
| Column Name | Description |
| a_id | Primary Key of dqit_issue table |
| a_status | Stores the status of issue |
| a_assignee_name | Stores the steward info to whom task has been assigned |
| a_system | Stores system name issue record belongs to |
| a_entity | Stores entity name issue record belongs to |
| a_instance_id | Key which identifies issue record, populated while generating issue |
| a_label | Stores label of issue |
| a_problem | Description of issues |
Snapshot of dqit_issue table from it_db database:
Snapshot of issues from MDA screen:
Below is the list of MDA issue status and their corresponding value stored in a_status:
| Issue status in MDA | a_status value |
| For Resolution i.e., New / Open | 1 |
| Resolved | 2 |
| Closed | 3 |
- The component responsible for closing tasks, and the parameters passed in component:
Close_mda_general.comp is supplied with CDI example and is widely used in closing issues. The same component can be used to close issues on an ad-hoc basis.
Close_mda_general component accepts parameters as below:
While closing issues explicitly, values for: issue_entity, issue_system, issue_instance_id, issue_assignee can be retrieved from the dqit_issue table and other values can be assigned as generic values.
Example Implemention
To close issues, a plan or component needs to be created. This will contain logic to list issues to be closed, the close_mda_general component, and the steps to assign values to parameters for this component.
In this example, issues with problem type ‘Issue with Established Date’ from ‘crm’ system will be closed. First, open issues with this problem description can be selected from dqit_issue table:
---SQL in “SQL Select DQIT” step
select
a_entity, a_system, a_instance_id, a_assignee_name
from dqit_issue where a_problem='Issue with Established Date' and a_status <> 3;
---
Note: issue_entity, issue_system, issue_instance_id, issue_assignee parameters values were retrieved in this step. As per requirement, issue selection criteria can be altered.
They were then joined with Party instance table records, retrieved from MDM Reader Step:
MDM Reader step configuration:
Join step configuration: Please notice the Left Key expression
Note: Left Key is following same logic using which a_instance_id was populated while generating issue. Join has been implemented between left key and issue_instance_id which has same value as a_instance_id. For optimal performance, implement search in MDM Read step to retrieve only applicable records.
In Column Assigner step, values for other parameters for were assigned
The result is then passed to the component to close the issues.
This plan can be wrapped in a workflow that is scheduled to run at a specific interval.
Notes: Issue Reader step is not supported for MDA issues. For more detail see: https://support.ataccama.com/home/docs/aip/latest/user-guides/mdm-web-application-user-guide/working-with-data-issues
A similar solution can be implemented for DQIT issues well
