Overview
Right now, I'm pretty close to finish my first Pluralsight course, called Understanding ABAP Dictionary. As I mentioned the title of the blog post series, I want to share you 3 Things You Should Know About ABAP Dictionary, and we have already talked about two: Meta-Data Consistency and Data Consistency.
Today, it's the time to talk about the third one, named Reusability. If you think about the reusability a bit, then you recognize that it carries both the Meta-Data and the Data consistency itself by default. This is because, if we reuse our Domains, Data Elements, Structures, Table Types and so on, then probably it's much-much easier provide Meta-Data and Data consistency, since we reuse the different objects, so we need to maintain less objects, and we probably make fewer mistakes and typos also.
There is one more benefit of reusing our building blocks in the ABAP Dictionary: you can save both time and money!
Today lesson
Reuse your building blocks in your ABAP Dictionary
Two-Level Domain Concept
The first level of the reusability is the level of Domains and Data Elements. What about if you define the fields in your structures and database tables with the help of hard-coded built-in types? Then, you have to define all the fields individually with the well-known trio: Data Type, Length ( + sometimes Decimals ), and Description. It can sound silly, but it's really a time-consuming process, especially if you have to define many-many fields. This is only the implementation cost, and I don't even mentioned the maintenance cost.
Let's image you have many tables, like Vendor, Customer, Employee, Sales Representative and so on that all contains different fields about email addresses, like Work Email, Personal Email, or Contact Email.
If you define your fields with hard-coded built-in types, then you have to define all of the email address fields one by one, individually like this: the field WORKEMAIL in the table, Vendor is a 60 long, character-based field with the description, Work Email. Then the next one: the field WORKEMAIL in the table, Employee is a 60 long, character-based field with the description, Work Email.
What can offer you the Two-Level Domain Concept? Well, transparent, flexible, and reusable building blocks that can greatly accelerate your development - it has only an initial implementation cost, but later you will thank to yourself these efforts.
Applying the Two-Level Domain Concept the process above sounds like this:
- First, we define an Email domain, with CHAR data type, and length 60. This domain will tell us, what kind of values, we are able to put in our fields. Now, in this case, we can place CHAR-based values with up to 60 length.
- As we have an Email domain, we are able to reuse it, and define more meaningful data elements, like Work Email and Personal Email. The data elements will inherit their technical properties, from the base domain.
- At last, we are able to reuse the existing data elements, and define many-many structure and table fields with almost zero development costs.
Structure
We have the same problem with the structures: local definitions are not reusable (like in the case of the database tables, if we locally hard-code their field definitions - using built-in types - then we cannot reuse these definitions).
If you need the structure, Author in another new ABAP program, then in this case you need to copy & paste your definition, you cannot reuse it!
Instead, we can define our structures globally in our ABAP Dictionary as well. I know, it sounds a bit more complex than simply typing structures locally in our ABAP programs, but worth it.
From now on, if you need the structure, Author in another new ABAP program, then in this case you only need to refer to this global structure, and that's it!
Table Type
The same problem with the table types also: if we define our table types locally in our ABAP programs, then we immediately lose our ability to reuse - we have to copy & paste our definitions from ABAP program to ABAP program.
The solution is to define our objects globally again, in order to reuse them!
Summary
Now you can ask me about where to place our definitions locally (field definitions within the database tables or structures; structures or table types within ABAP programs) or globally in our ABAP Dictionary?
Well, the answer is very simple: it depends!
If you are doing prototypes, demos or something like these, defining your field definitions locally within the database tables or structures, or your structures or table types locally in your ABAP program is absolutely enough!
But when it turns to complex or you are doing productive projects, I highly recommend to define them as global directly in the ABAP Dictionary!
Stay tuned, keep reading! If you want to get notification about the newest posts, follow me or subscribe to our newsletter!
If you liked it, please share it! Thanks!