Additional Blogs by Members
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
0 Kudos

After I introduced the SAP LT product in my last weblog entry and named challenges in transformation projects I’ll discuss the most basic operation: changing the value of an ABAP domain. Why is this important? Usually all conversions and merges consist of transformation of domain values. In ABAP simple data types are called domains. These domains are used in fields that are part of complex (=composite) structures like transparent tables, workflow containers, BW InfoObjects, BOR references…

During harmonization and merge of systems (or clients) you will have to change many of domain values of application data, master data and customizing. You will renumber the domain values using SAP LT technology before merging the content of databases.

If you are using SAP standard domains LT will recognize them and will find all tables that have to be changed. If you are using a mix of standard domains and custom domains you have to spend effort to tell LT what to change. Let’s go into detail:

  • If you extend  data structures from SAP standard (this of the central Business Partner application) you should use SAP domains like BU_PARTNER:

  • If you create your own business objects you should create your own domains.

  • Never ever misuse domains from SAP standard. Creation of a domain is very simple and you can avoid serious trouble in transformation projects.

But even if you take the domain concept seriously this doesn’t mean that your SAP system is merger ready. In the following lines I’m discussing risks that can cause trouble. All those risks have one thing in common: You should check them as early as possible within system analysis. And if you find a problem you have to find a strategy, for example:

  • harmonization before the merge (cleaning data manually or with reports)

  • harmonization after the merge (cleaning data manually or with reports,

  • harmonization during the merge (mappings, special rules…).

In the following I discuss some risks & challenges you should analyze very seriously.

Challenge No 1: Referential Integrity

In ABAP there is no concept of rerential integrity. This means that you database table can contain nearly any values. Values that would violate referential integrity constraints can be inconsistencies -think of values that don’t correspond to SAP customizing and so on. Inconsistent data can lead to problems:

  • You’ll have to define special mapping rules.

  • If you detect inconsistencies too late - after a test - it will take you time to find out whether those inconsistencies are the result of a merge or not.

My recommendation to ABAP programmers: develop consistency checks that validate your data. You can use those tools to check consistency and to hunt bugs.

Challenge No 2: Semantical Correctness

Missing referential integrity constraints can be one reason for inconsistent semantics of your data. But there can be other reasons - let’s have a look at primary keys of database tables: in ABAP applications primary keys of transparent tables are usually defined using GUIDs or number ranges so you won’t have any problems. In a good programming style business logic coded in queries, reports, within the business object, workflows and only depends on attributes of business objects but not the value of the primary key.

This is a real simple and fundamental rule but in migration processes can be violated. Let me give you an example: if you migrate data from a legacy system into your SAP system in an implementation project customers may claim that those initial data have to be treated differently in programs: They have a special semantic and so programs have to treat them differently. My recommendation to ABAP programmer: don’t code assumptions on values of surrogate keys like number ranges in your programs! Otherwise your programs won’t work after renumbering the primary keys.

Challenge No 3: Genericity

In my blog entry “Don't try to be smart. Be smart.“ I discussed the problems of generic programming. Of course this applies to generic data structures, too. Data clusters and XML containers are really useful (think of workflow containers) but this flexibility doesn’t come for free:

  • generic data containers are hard to select and to analyze and

  • complex data models require complex processing algorithms – think of BW extractors for example.

So my advice to ABAP programmers: generic  programming is fun. But in business programming we need simple data models that are easy to understand and to analyze. If a data model gets too complex this will come back to haunt you in data transformation and merging projects. Here LT tooling will support you but analysis and checks done by you will take much more time because you can’t use standard tools like SE16. If you work efficiently you’ll have to develop tools like SE16 for generic data structures.

Challenge No 4: False Economy

There are many ABAP domains which are simply too short. Domains consisting of one or two digits can’t hold all necessary values in merged SAP system. This will even get worse because of naming and numbering conventions.

My advice to ABAP developers: Never forget that your application should work in a global SAP system. Don’t be afraid of using GUIDs as primary key for application data.

Challenge No 5: Implementation Guidelines

As an ABAP architect you should know the risks that can occur when merging domain values of your application. Those risks can be reduced if you create naming conventions for your customers so that the domain values will be disjoint. This can help you to reduce the effort of a merging project significantly.

Challenge No 6: Testability

Before the final merge you’ll do many test merges and perform tests. Every eCATT test cases can help you to reduce manual test effort.

Is your ABAP application merger ready?

I proposed some simple rules for ABAP programmers if they want to ensure that an ABAP application is merger ready. I think those rules are compliant with good programming style.

If you know that merging will likely happen then try to foresee the consequences and check whether your application fulfills above mentioned quality criteria.

These rules are necessary but not sufficient for merger readiness. In following installments of this weblog series I’ll go into detail and discuss special aspects like customizing.


In this installment I discussed aspects and pitfalls of the most basic of a landscape transformation project: renumbering the values of a single ABAP domain. I proposed some strategies to ensure quality and to reduce effort of a transformation project.

Of course Landscape Transformation projects don’t deal just with changing values of ABAP domains – usually they include processes, data and integration scenarios of the whole enterprise architecture which will be topic of further weblog entries.