Skip to Content
Author's profile photo Tobias Trapp

Don’t try to be smart. Be smart.

From FIELD-SYMBOLS and TYPE ANY parameters to RTTI

ABAP possesses very powerful generic typing using TYPE ANY parameters and FIELD-SYMBOLS. There are really useful if you want in generic programming approaches. But what does genericity mean? There are three different answers:

  • A mathematician considers genericity as a “natural” approach: He defines a structure using a set together with some operations – think of the axioms for vector addition and scalar multiplication for example. These operations are valid in in every vector space – think of three-dimensional space or the space of continuous functions.
  • A computer scientist will call genericity as polymorphism beyond isolated classes.
  • And a programmer will call a function module generic if it can deal with arbitrary data types like TYPE CLIKE or TYPE ANY.

Genericity means exactly this concept: We have a set of operations that are valid for a set of data types. Usually the implementation for operation for certain data types will differ but in some cases you can use exactly the same code for all implementations.

ABAP supports the latter feature with generic FIELD-SYMBOLS and TYPE ANY parameters. Using this command you solve a lot of tasks very easily using generic programming, think of exporting the content of an arbitrary transparent table as CSV file. And you can use Run Time Type Information (and even Run Time Type Creation) to solve more difficult problems.

This kind of programming is extremely useful for creating generic tools but I consider it dangerous if you use it as general programming model. The reason is obvious: In business programming we have to control the data flow between UI, application layer and database layer. The same holds for data replication between different applications of SAP Business Suite. The ABAP Dictionary and the possibility to determine use accesses is one of the most useful tools if you have to maintain applications. I consider genericity is dangerous if it makes the data flow in an business application or between to applications harder to understand.

Bad habits…

It seems to happen to nearly every experienced ABAP programmer the he or she gets tired of MOVE and MOVE-CORRESPONDING as he or she learns about the powerful generic features of ABAP: the MOVE command seems to be old fashioned, vulgar and only applicable by beginners.

Let me give an example. I had a discussion how to implement Enterprise Services. In most cases you have to call a BAPI within the service and therefore you have to map the parameters. A senior ABAP developer suggested to develop a framework which does an generic MOVE by doing customizing. This solution would never come my mind because of lots of reasons:

  • Sophisticated frameworks are hard to test and error prone.
  • We can’t do static type checks using extended syntax checks or ABAP Code Inspector.
  • It introduces unnecessary complexity: a simple MOVE does the same with less effort.
  • You have to deploy the customizing.
  • The framework will get more complicated if we have to introduce more complex transformations.

This complexity makes only sense if you want to enable the customer to change mappings without any modification. But this wasn’t a requirement so I favoured a simple solution without any sophisticated framework.

The power of type safety…

 Most interfaces (like BAPIs or Enterprise Services) have stable, type safe interfaces and even support extensibility concepts and are documented. Those interfaces are the backbone in integration scenarios – within SAP Business Suite, in composition scenarios and in eSOA. This comes from the fact that from those stable interfaces (sometimes with the help of metadata like WSDL) you can easily generate calls, mappings using code generation techniques. So calling a SOAP web service in ABAP is an easy task that can be done very efficiently. Another example are the graphical mapping tools in PI or the composition tools in SAP NetWeaver CE.

Typed interfaces contain a implicit documentation so they are easy to understand. Using metadata you can use code generation and model driven techniques that reduce development effort. In business programming you have to be careful with sophistication – often explicit and simple interfaces are much more useful. 

… and its ugly generic counterpart

Have you ever seen tables containing name/value pairs? Those ones have been one of the worst interface techniques I have discovered so far.

TYPES: BEGIN OF interface_structure,
                 NAME  TYPE STRING,
                 VALUE TYPE STRING,
              END OF interface_structure,
              interface_tab TYPE STANDARD TABLE of interface_structure.

 Let me give an example:

  • “LAST_NAME”, “Trapp”

When you define a function module using this interface you can transfer any data. Any data? Of course not! What happens if you want to transfer of a second business partner? Or even a set of business partner with different attributes? It’s easy to see that this generic interface is far from being general and extensible – so I can’t recommend it.

 Within AS ABAP there are some generic interface techniques like BDT Direct Input which rely on amorphous strings. BDT interfaces are ugly, you can’t use them in SOA context but despite that they have some advantages:

  • they have a defined extensibility concept,
  • it allows a dark processing of input screens and
  • allows to define the same checks in online as well a batch processing.

I think this is a compensation for dealing with messy strings, line delimiters and so on.  

Can genericity be useful?

Yes, I’m conviced there are useful applications for generic techniques. Do you know the code list provider framework in AS ABAP? Code lists are global data type in SOA context like country and currency codes. If those codes are defined using customzing the code list provider framework allows to link a data type within Enterprise Service Repository to the set of values defined within customizing. There is also a generic Enterprise Service that returns the values (together with texts in different languages) – so we have a kind of F4-value help in SOA context. This is possible using the Code List Provider framework.

Let me explain it using an example. The ESR data type CountryCode has an ABAP proxy FKK_CWLI_COUNTRY_CODE. Country codes are defined in transparent table T002. To link the data type to a transparent table or ABAP domain we use the  CL_CENG_GEN_CODE_LIST_PROVIDER class in the following proxy definition:

 Then we can link the code to an transparent table resp text table: 

Then we can use the Enterprise Service QueryCodeList to get a list of country codes:

The code list provider framework is a very generic framework using generic programming techniques. But it helps us to achieve transparency and type safety because it helps us to link ESR data types to ABAP data types.


Generic concepts are helpful in frameworks. In business programming I prefer simple and typed interfaces because they will make integration much easier and is a benefit to code quality.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tammy Powlas
      Tammy Powlas
      I wish I would have read your blog when I was ABAP programming a few years ago -  those who do ABAP code peer reviews would do well to follow your guidelines.  Great job in explaining this.
      Author's profile photo Tobias Trapp
      Tobias Trapp
      Blog Post Author
      Hi Tammy,

      I wish I would have read this blog, too, when I was an ABAP starter. My first programs have been completely generic and therefore too academic and too abstract.


      Author's profile photo Former Member
      Former Member
      Definitely agree with you Tobias! Although generic programming is fun to do (it's a great challenge for the mind sometimes) it is often incomprehensible and changes are nearly impossible to implement. Code quality is determined by its robustness not by using shiny techniques.
      Author's profile photo Tobias Trapp
      Tobias Trapp
      Blog Post Author
      I think many developers believe that genericity is a kind of silver bullet: it is so powerful that it can reduce complexity - even from a complex business process. But this is not true - complexity is still there but hidden. And you are absolutly right: designing generic frameworks is very difficult. Sometimes they are general and therefore painful to use or they are too limited and therefore hard to extend.


      Author's profile photo Former Member
      Former Member
      Great blog for Abappers !!

      Want to see a Really Generic Framework which is brainchild of some really SMART ABAP Guys.
      The check the code of Duet Enterprise / Gateway's framework.

      I have used and Debugged it and yes (it also utilized the Codelist Framework )

      Author's profile photo Tobias Trapp
      Tobias Trapp
      Blog Post Author
      Hi Ravi,

      thanks for mentioning gateway framework. I will definitly do if I find the time. Can you tell me a an ABAP package name where to find it?

      Best Regards

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      What a great hidden gem and still so true in 2015! 🙂 There have been quite a few times when I struggled myself to maintain good balance between keeping things generic without going too far just for the sake of the "art".

      Author's profile photo Otto Gold
      Otto Gold

      Hello Tobias,

      100% agree. Just my 2 cents:

      a) Being too generic can be a very very bad idea for security. If you can call almost anything based on some funny customizing or generic parameters (name-value pairs in the interfaces of the RFC enabled function modules etc.), that is very very bad for security, QA and even for the maintenance of the code in the future. I have met people in the years of my career that were very very good at these things. Very generic and abstract (and powerful) frameworks have been built - but to authorize them, move them from the hands of the gifted author to the hands of the support people after the project, ensuring the knowledge, skill and big picture is kept where it needs to be, that is the challenge.

      Example: Thing about people using RFC_READ_TABLE or the SQL interface to do VERY generic things to your system and data. Ugly!

      b) You already said that - big generic things tend to be error-prone. Exactly my point. What if you built something really really cool, something that the others cannot ignore (and you don't want to see your "baby" being ignored), it is too beneficial and just cool... and it is quickly used all over the place. Then someone does maintenance on the code or you just forgot a little bug there. Then everyone and everything is affected. That is terrible. I hate the risk of the side effects and the risk that people may start bending generic things to support one specific application's flavour very painful. I personally prefer making things reusable and more generic as we need things being reused in our team, rather than starting a huge framework first.

      But anyway we are in 100% agreement on the topic. Keep up the good stuff coming.

      cheers Otto