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:
- “BUSINESSPARTNER_NUMBER” ,”4000284”
- “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.
Summary
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.
8 Comments
