Pitfalls when Coding Transformations Using ABAP

by The Tip Doctor

August 25, 2011

The following tip is taken from the BI Expert article “Improve and Simplify Your Transformations by Using ABAP Objects” by George Campbell-Kelly, published June 2011.

ABAP Objects has many purposes within SAP NetWeaver BW, but most frequently it is used to create code when a transformation maps a DataStore object (DSO) into an InfoCube. A transformation can be a simple, direct mapping of a field into a field, or it can be something far more complicated.

To map a transformation, a developer has the option of either using a graphical interface or writing code. The graphical interface is quick and easy for simple mapping but becomes impractical as the mappings grow in number.

If the developer is coding, he or she has two further options — to write the code directly into the transformation or instead to use a standard five lines of code in the transformation that calls the ABAP Object. If doing this, the developer needs to write code into the ABAP Object, which then performs the logic. In my opinion, this second option is often overlooked, because the ABAP Object program is not widely understood.

Because of this, most developers write their code directly into the transformation, which can be quick and easy as long as the code is simple . However, this code can quickly become complex and hard to maintain, particularly if there’s a lot of it. Other likely problems you might encounter include:

•    Poor syntax checking. When syntax checking, the transformation’s ABAP code editor won’t necessarily take you to the line of code with the problem. It might take you to an unrelated correct line of code or just not tell you the reason the line is incorrect. Even if the code editor syntax checks correctly for 90 percent of the code (and in my experience, its accuracy can be much lower than this), finding the remaining lines of incorrect code can be a wild goose chase.

•    Incorrect checking of type assignments. A type assignment problem only surfaces when the transformation crashes, generating a shortdump. The shortdump won’t tell you what’s gone wrong, or even that the problem is a due to a type mismatch. (I have spent hours tracing these problems, only to eventually find a single type mismatch in my code!)

•    Tricky transportation of transformations. For you to see the effect of your transformation, you need to reload your data in the data target, which updates your InfoCube. This requires reactivating all of your data transfer processes (DTPs), transporting them into your chosen system (e.g., QA), then reloading your data. The need to go through this process is often a cause of error and rework.

•    Time-consuming unit testing and code debugging. Testing and debugging code placed directly within the transformation can be time consuming. This is due to the lack of test functionality and the difficulties associated with generating test cases.

•    Difficulty tracing issues in QA and Production. To debug the code contained in a transformation, you must identify data and schedule a load. This can be difficult if you don’t have suitable data or are concerned about affecting the data already loaded.

•    Effort and coordination needed to reuse code in multiple transformations. Failure to reuse code in different transformations can lead to inconsistent data and excessive maintenance requirements. In a system, you should make sure that every business rule is defined in only one place. Doing this ensures that the SAP NetWeaver BW system produces 100 percent consistent results.

•    Difficulty tracing assignments managed in transformations. Transformations between large structures can become very complex. The process of tracing each of the lines connecting the Source and Target fields, in the Transformation screen, is tiresome, error prone, and time consuming.

•    Mapping between source and target InfoProviders is not automatic. If you have the same fields in your source and target InfoProviders you must still configure the mappings between them within a transformation. When changing the InfoProviders, this step consumes time and is potentially the source of errors.

A complete step-by-step guide to writing code into an ABAP object – avoiding many of these issues – can be found in George’s full article on BI Expert.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!