Overview
In the last few months, I have been working on my new Pluralsight course, called Understanding ABAP Dictionary that is about introducing you the basic concepts of the ABAP Dictionary in a very simple way, using illustrative examples.
Today, I decided to share you a few thoughts from this course that can be helpful in your ABAP Developments. As an ABAP Developer, if we are responsible for the database layer, then the goal is to create flexible, consistent, and centralized databases that serves data for many application. Our databases have to be 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, and within that the meta-data consistency.
Today lesson
How to provide meta-data consistency with the help ABAP Dictionary
ABAP Dictionary
Before we deep dive into the concepts, let me introduce you the ABAP Dictionary in few sentences, for the case, if you have no experiences in it.
Using ABAP Dictionary, you get a nice, and user-friendly UI for maintaining your database objects, instead of, for example going to the SQL Server Management Studio and creating the tables with your own hand, that can make your development much slower.
In the person of the ABAP Dictionary, you get a central meta-data repository, to manage your data definitions globally, to keep them consistent, and share them for further reuse, thereby saving time.
In this meta-data repository, you can easily define different validation rules for ensuring the data integrity and consistency among the different entities, and improving the quality of your data as well. You are able to define these validations as type restrictions, or setting value ranges for fields, and so on. Thereby you can save more time, because you define these validations only once and reuse them, instead of defining them in individual ABAP programs several times.
Using the features of the ABAP Dictionary, you are able to decrease the implementation and maintenance costs via reusing existing definitions, and the centralized maintenance. Imagine, that you have five different tables, and all of them has the field Book Title with the type CHAR and the length 60. What if the length changes to 100?
Without ABAP Dictionary, you would need to modify the definitions in five different places.
At last, the ABAP Dictionary is fully integrated with most of the ABAP Workbench tools like ABAP Editor, Function Builder, or Class Builder. That means, in the ABAP Editor for example, when you click on the name of an ABAP Dictionary object, it brings you directly into the ABAP Dictionary. This feature gives you an easy navigation between the different tools, that results a faster development.
Two-Level Domain Concept
To have a better understanding of this concept, let's consider the following example: we have a few structures and database tables (let's say 5-5) that all contain different fields about email addresses, like Work Email or Personal Email that we defined with simple, hard-coded built-in types. What happens, if need to perform some changes (changing the length from 50 to 60)?
Yes, we all know it! We need to perform the changes at least fifteen times. But, besides the costs of the changes, we can face with another problem.
Let’s imagine, that I start performing the changes, and modify some of them correctly. What if, I mess up, and make a typo? Or, forget to perform the changes on some of the objects?
Yes, it can happen, and in this case, our ABAP Dictionary becomes inconsistent. That’s a big problem, it can cause errors in our ABAP programs. It doesn’t seem to be a good solution!
What can we do?
Well, we can apply our proven approach, the Two-Level Domain Concept that means: you define the value range of several fields in a single domain (ZEMAIL); then describe the meaning of the fields using some data elements (ZWORKEMAIL, ZPERSEMAIL); and at last, you can attach these definitions to many-many fields, ensuring a high reusability, centralization, and consistency.
As a result, you need to maintain your meta-data in a centralized place, in the core of the domains.
Structure
One way to create a structure, is to define it locally and individually at the begining of our ABAP programs. It can be an applicable and good solution in simple cases, but when it turns to complex like this, then it can cause you some sleepless nights.
Why?
Let’s imagine, that you want to modify the type of some components, then probably you need to update it up to seven different places, or what if, you want to extend your structures with a new component, then the same story again.
As you can see, it’s not the best solution ever,… it is a solution…, and it can be a good solution some cases, …but let’s face it honestly, should be a better solution somewhere!
and there is!
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:
- you get thinner source code, since you need to write fewer lines of code,
- no need to copy and paste structure definitions in your ABAP programs, you can easily reuse your global structures,
- you need to maintain only one structure, against with seven,
- and much easier to keep your structure definitions consistent in the ABAP Dictionary, than your ABAP programs.
Table Type
Now, I’m curious about only one thing, namely where should we define our table types: locally or globally? Well, the answer is very simple again: it depends! If you are doing prototypes, demos or something like these, defining your 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 table types directly in the ABAP Dictionary! The arguments are the same as in the case of the other data types:
- you need to write fewer lines of code,
- easy to reuse them in other ABAP programs,
- easy to keep them consistent, since you centralized the maintenance,
- and at last, the costs are lower, since you need to maintain them only in a single place.
Summary
As a summary, all I can say is that:
- define your Structures, Table Types, and Database Tables using Data Elements (with applying the Two-Level Domain concept), instead of using simple hard-coded built-in types.
- if you are doing prototypes, demos or something like these, defining your data types (structures, table types) locally in your ABAP programs is absolutely enough!
- but when it turns to complex or you are doing productive projects, I highly recommend to define them as global data types directly in the ABAP Dictionary!
Believe me, later on when you have to modify or reuse your data structures, then the cost of the centralized maintenance pays off.