How can I map custom input parameter for Validation component in Ataccama One Web UI?
Solved
Custom input for validation component
- Data Voyager
- 1 reply
Best answer by joyce
Hi
For example, if there is a single DQ rule reused for several range checks. The Monitoring Project Report tab, will have several DQ checks with the same name but varying rule logic or ranges. It would be difficult to differentiate between the rules.
Additionally, the Post-Processing Plan writes the DQ rule names per invalid record. If the same DQ rule is reused, the DQ rule name would not be very helpful in identifying why a record is invalid. Having separate DQ range checks, allows users to easily identify why a record is invalid based on the DQ Rule Name applied. See example below:
Reuse of a single DQ range check invalid records export:
| DQ Rule Name | Record Value | Record ID | Invalid DQ Rule Explanation |
| DQ Range Check | 10 | 1 | Invalid |
| DQ Range Check | 20 | 2 | Invalid |
| DQ Range Check | 30 | 3 | Invalid |
Using separate DQ range checks invalid records export:
| DQ Rule Name | Record Value | Record ID | Invalid DQ Rule Explanation |
| Value Less Than 5 | 10 | 1 | Greater_than_5 |
| Value Less Than 10 | 20 | 2 | Greater_than_10 |
| Value Less Than 15 | 30 | 3 | Greater_than_15 |
Hope this helps!
- Ataccamer
- 17 replies
Hi
- Data Voyager
- 1 reply
I am trying to create a DQ evaluation rule where we can use custom input from users in our rules for some special DQ rules like domain of values check where user will provide the domain values during assigning the rule in monitoring project and based on that the evaluation should run and provide the DQ result.
That’s why I was trying to create a validation component which can accept custom values as parameter and itegrate it with the DQ evaluation rule.
Hope this helps.
1 person likes this
- Ataccamer
- 17 replies
- Answer
Hi
For example, if there is a single DQ rule reused for several range checks. The Monitoring Project Report tab, will have several DQ checks with the same name but varying rule logic or ranges. It would be difficult to differentiate between the rules.
Additionally, the Post-Processing Plan writes the DQ rule names per invalid record. If the same DQ rule is reused, the DQ rule name would not be very helpful in identifying why a record is invalid. Having separate DQ range checks, allows users to easily identify why a record is invalid based on the DQ Rule Name applied. See example below:
Reuse of a single DQ range check invalid records export:
| DQ Rule Name | Record Value | Record ID | Invalid DQ Rule Explanation |
| DQ Range Check | 10 | 1 | Invalid |
| DQ Range Check | 20 | 2 | Invalid |
| DQ Range Check | 30 | 3 | Invalid |
Using separate DQ range checks invalid records export:
| DQ Rule Name | Record Value | Record ID | Invalid DQ Rule Explanation |
| Value Less Than 5 | 10 | 1 | Greater_than_5 |
| Value Less Than 10 | 20 | 2 | Greater_than_10 |
| Value Less Than 15 | 30 | 3 | Greater_than_15 |
Hope this helps!
Reply
Most Liked this week
Login to the Ataccama Community
No account yet? Create an account
For Ataccama Customers and Partners
or
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.