Overview
In the previous post, we talked about how we can provide Meta-Data Consistency through applying the Two-Level Domain Concept, or defining Global Structures and Table Types.
As you could see, ABAP Dictionary can really help you to build databases that are flexible for the future changes, consistent in order to provide high-quality data, and centralized to decrease the implementation and maintenance costs.
Today, we are going to focus on the consistency again, but within that the data consistency.
Today lesson
How to provide data consistency with the help ABAP Dictionary
Input Helps within Domains
First of all, to provide high-quality data, we need to provide a few crutches to our end-users. Crutches can be a simple list of values within our domains, value ranges or value tables. Furthermore, we can attach user-defined search helps to our fields.
Whatever you choose, - as a result - your end-users won't think about what values they can type into the given, they will use the attached input helps. With these input helps, you can eliminate the different typos and mistakes, and also reduce the stress on your users.
To understand how input helps can help us to provide high-quality data, let's consider the following example below.
Let's imagine that we have three different tables, one for the Customers, one for the Vendors, and at last, one for the Employees. The point is, that both of them contain very similar fields: Customer Rating, Vendor Rating, and Employee Rating. Both three rating fields has a hard coded integer type, and the rule is, that all of them can only contain values from one up to five!
Using simple and hard-coded types, like the integer, we don't have any chance, than we need to enforce our users to type only these values into these fields. The question is, how we can enforce this rule?
The simplest solution is, that we hard code this business logic into our program, that managing the given database table. It works! But, what if, we have another ABAP program, that dealing with this table? Yes, you are right! Copy-and-Paste, and that’s it!
What if, we have one more ABAP program?
Or what if, we have many other ABAP programs that deal with these database tables? I think, it’s obvious to you, that it’s not going to work! It’s a kind of nightmare! But, what we should do instead?
My answer is very simple, apply the Two-Level Domain Concept! We create a single domain, a general Rating domain with a specific value range. Then using this domain, we inherit three different data elements, with three different semantic meanings, a Customer Rating, a Vendor Rating, and an Employee Rating. But the point is, that they all use the same value range, that we defined in our Rating domain. And at last, we use these data elements, and define our fields in the tables.
That’s it!
From now on, we are able to enforce our business logic, from a single, and centralized place, in the core of our domain.
How does it work?
Well, let’s avoid built-in types in your code, and instead use your data elements that has a specific value range, thanks to Two-Level Domain Concept. In this way, we are able to force the users to choose a value, from a specific value range, avoiding typos, and mistakes.
Input Checks through Foreign Key Relationships
In the case of the Input Checks, the system checks whether the specified check table contains a record with the key that user typed into the given field. If there is such a record, the entry is valid. Otherwise the system rejects the entry.
What does it mean for you?
It means that you can enforce your users to type only valid values into the given field, and in this way, you are able to provide high-quality data.
One way to achieve auto input checks is to set foreign key relationships between your tables. In our example, we set a foreign key relationship between the tables, ZORDER and ZCUSTOMER through the field CUSTOMERID. In this case, we call the table, ZORDER as foreign key table and ZCUSTOMER as check table.
How does the Screen Check work?
Let’s consider the following example! We would like to place an Order for the given Customer with an invalid Customer ID. After pressing an Enter, the system the reads the check table, ZCUSTOMER and looks for the entry with the following Customer ID.
Since, there isn’t any entry in the table with the given ID, the system rejects the entry, and marks it as invalid! This check was performed via a Screen Check, with the help of the Foreign Key Relationships.
Summary
All in all: attach input helps to your screen fields and your users will be grateful to you! In addition, via input helps, you can achieve a higher data consistency in your database as well.
Furthermore, applying different input checks, you can keep your database consistent.