Skip to Content
Technical Articles
Author's profile photo Sander van Willigen

Transformation Class Approach – Part 2: Implementation

Over time quite some ABAP coding is written in the context of Transformations. On one hand it is an enabler for implementing the most sophisticated requirements. On the other hand it can easily become a chaos without proper standards and guidelines. It can even become dangerous, uncontrolled and cumbersome to support having so much coding all over the place.

The “best practice” concept of Transformation Classes can help to better encapsulate, organize and maintain the source code. ABAP-OO (Object Oriented) programming principles are used – in accordance with official and de facto development standards as published by SAP SE.

In my previous blog Transformation Class Approach – Part 1: Introduction I introduced the concept of the Transformation Class approach. The purpose of this blog is to give step-by-step guidelines in creating Transformation Classes and embedding them in Transformations.

Reusable ABAP Objects

The Transformation Class approach comes along with few reusable ABAP objects. These objects should be created before you can start any Transformation Class implementation. This is a one-time action.

You can either use the respective transaction in the back-end system or use the ABAP Development Tools (ADT) in Eclipse. This is not further explained in detail.

The following Classes should be created (using t/code SE24 in the back-end system):

  • ZCL_TRFN_TEMPLATE_1
  • ZCL_TRFN_TEMPLATE_2

The following Include Programs should be created (using t/code SE38 in the back-end system):

  • ZI_TRFN_CLASS_START
  • ZI_TRFN_CLASS_END
  • ZI_TRFN_CLASS_EXPERT

Please have a look here to download the files with source code of the Classes and Include Programs. Copy and Paste the source code in the respective Class or Include Program.

Step-by-Step Guide for Regular Transformation

For the regular use case, the following steps are applicable:

  1. Create new Transformation Class
  • Copy template class ZCL_TRFN_TEMPLATE_1
  1. Change the newly created Transformation Class
  • Update Class-relevant Local Definitions
  • Implement logic in Method START_ROUTINE (if applicable)
  • Implement logic in Method END_ROUTINE (if applicable)
  • Add additional Methods (if required)
  • Activate Transformation Class
  1. Change Transformation
  • Maintain Global Data Declaration
  • Maintain Start Routine (if applicable)
  • Maintain End Routine (if applicable)
  • Activate Transformation

Step-by-Step Guide for Expert Routine Transformation

For the special use case of an Expert Routine Transformation, the following steps are applicable:

  1. Create new Transformation Class
  • Copy template class ZCL_TRFN_TEMPLATE_2
  1. Change the newly created Transformation Class
  • Update Class-relevant Local Definitions
  • Implement logic in Method EXPERT_ROUTINE
  • Add additional Methods (if required)
  • Activate Transformation Class
  1. Change Transformation
  • Maintain Global Data Declaration
  • Maintain Expert Routine
  • Activate Transformation

Naming Convention

Let’s define a naming convention to uniquely identify each Transformation Class. Keep in mind that the Class technical name cannot exceed 30 characters.

I propose to use the following naming convention: ZCL_TRFN_<target_iprov>_<seq_no>

The components of the naming convention are as follows:

  • Each Class has a fixed prefix: ZCL_TRFN_
  • <target_iprov> stands for target InfoProvider (e.g. Advanced DSO)
  • <seq_no> stands for a two-digit sequential number (e.g. 01)

Create New Transformation Class

You can either use the Class Builder (t/code SE24) in the back-end system or use the ABAP Development Tools (ADT) in Eclipse. The screenshots are showing the Class Builder.

Short instruction:

  • Enter an appropriate template Transformation Class (e.g. ZCL_TRFN_TEMPLATE_1)
  • Push button Copy
  • Compose a new Transformation Class name
  • Naming convention (suggestion): ZCL_TRFN_<target_iprov>_<seq_no>

Figure 1: Copy an appropriate template Transformation Class

Change Transformation Class

You can either use the Class Builder (t/code SE24) in the back-end system or use the ABAP Development Tools (ADT) in Eclipse. The screenshots are showing the Class Builder.

Short instruction:

  • Properties tab: change the description in line with the Transformation
  • Class-relevant Local Definitions: maintain the Source Package and Result Package structures

Figure 2: Class-relevant local definitions (1)

Define in the Class-relevant Local Definitions the structure of Source Package and Result Package. Refer to the data declaration of the generated program and copy and paste the structures in the same way.

Figure 3: Class-relevant local definitions (2)

Display the generated program, copy the structures identified by _ty_s_sc_1 (Source Package) and _ty_s_tg_1 (Result Package) and paste the respective structure in the Class-relevant Local Definitions.

Figure 4: Example of generated program

Now you can go ahead with writing the required source code in Method START_ROUTINE and/or END_ROUTINE of your newly created Transformation Class.

Figure 5: Method START_ROUTINE

Figure 6: Method END_ROUTINE

Transformation – Global Data Declaration

Only one line of coding is required to declare the global data object. Note: always use Global and not 2nd part Global. The object name is always the same: G_R_TRFN. The reference is the newly created Transformation Class.

Figure 7: Global data declaration

Transformation – Start Routine

Optional, i.e. only to be used if a Start Routine is applicable. One line of coding is required to call the Transformation Class. All required coding is taken care of by the Include Program ZI_TRFN_CLASS_START.

Figure 8: Start Routine

Transformation – End Routine

Optional, i.e. only to be used if an End Routine is applicable. One line of coding is required to call the Transformation Class. All required coding is taken care of by the Include Program ZI_TRFN_CLASS_END.

Figure 9: End Routine

Conclusion

In this blog I focussed on the implementation of Transformation Classes. First, I explained that few reusable ABAP objects are required to get started. This is a one-time action. Afterwards, I discussed step-by-step guidelines in creating Transformation Classes and embedding them in Transformations. Feel free to enhance your Transformation Class with additional Methods to better organize or modularize complex coding.

Last but not least, remember that in the context of Transformation Routines certain design rules exist. Please refer to the following SAP Notes for more information:

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sudhanshu Surma
      Sudhanshu Surma

      Very useful article there Sander, Thank you!

      Author's profile photo Michael Schwarz
      Michael Schwarz

      We had a similar system in use in BW 3.x Update Rules – but with external performs.

      When switching to BW 7.X TRFN data flow, we tried the same. It was still possible – the OO class stuff is not really needed.

      It has the advantage that all code of a single TRFN is collected in one class – but this could also be archived with a single SE38 program Z_TRFN<data-target_index> containing the FORMS “START_ROUTINE”, “END_ROUTINE” and “RULE_<target-infoobject>”.

       

      The BIGGEST problem was this one:

      “Display the generated program, copy the structures identified by _ty_s_sc_1 (Source Package) and _ty_s_tg_1 (Result Package) and paste the respective structure in the Class-relevant Local Definitions.”

       

      In BW 3.X, SAP BW generated a DDIC structure which contained all fields of a source or target package. This structure could have been used in own external programs. It was automatically adjusted, if a source / target object was activated in TA RSA1.

      In BW 7.X, this structure is missing. Now, every time you change your source / target objects, you have to remind to adjust the definitions in your own external code, too.

      We speeded this up a bit by having an INCLUDE Z_TRFN<data-target_index>_STRUCT with the types declarations from the TRFN n our external form routines program. With this, copying was a bit easier, as you have not to touch the normal external ABAP routine.

       

      We addressed this problem to SAP – either on a SAP partner day or in the former OSS system.

      Reply from SAP:

      Hm…yes…. we know….. the DDIC structures are not generated any more …. because we don’t use them ourself in the generated TRFN ABAP code ….

      …. we switched this, because in BW 3.x, it sometimes was tricky to keep the DDIC structures updated … (maybe it had to do something with impact handling…)

      …. but: we will see, if we can deliver an additional DDIC structure generation for customer coding needs with a future patch or revision of BW 7.X .

      (it was one of the first 7.x versions we tested; maybe a ramp up version …)

       

      Unfortunately, SAP never did this …. ?

       

      Author's profile photo David .
      David .

      Hi Sander, great blog post!

      I've been using a similar approach in my projects in the past. Let me describe how I did it:

      1. Set up a global class for all transformations (start-, end-, expert)
      2. In BW transformations create an instance of this class and call the corresponding method (e.g. mytransfclass->endr_source_target( changing result_package ).
      3. In my method I'd assign the type of my active table's target aDSO to an internal table. So for aDSO MYDSO it would be /BIC/AMYDSO2. Then use move-corresponding of the parameter that takes of result_packe to this internal table.
      4. Work on internal table as needed (e.g. via field-symbols)
      5. clean the parameter and write-back from internal table to parameter

       

      For expert routines, it's almost the same apart from the source_package and result_package parameter handover.

       

      So now I'm asking myself: Are there severe disadvantages over my solution compared to yours? I really want to understand why I should for example hand over the request and monitor parameters from the calling routines and always need to create another class for every transformation.

       

      Thanks in advance for your opinion on this!