Ten practices to make your ABAP developments optimized, informative, modern and quality robust
Evolution gives birth to new practices. Over a period of time with the evolution of SAP from 4.7 to ECC and then to S/4 HANA, several features have been changed so far. With the arrival of new frameworks, screens, and guidelines, several modern practices are developed and they are adopted in many modules, customization, and also in programming. And my focus in this blog is ‘ABAP Programming’ developments. My personal experience of ABAP development depicts that in general, there are three phases: Programming, Quality Check and Testing. And every phase requires a certain investment of proven practices in order to develop quality robust software.
I have tried to list down ten practices, worth adopting to transform ABAP developments into optimized, informative, modern, and quality robust. The practices explained below act as a check-list worth not ignoring while programming.
1. Declaration of Internal table: Be specific about the type of internal table declaration. The default is not always to declare the internal table as the standard type. In fact one must invest some time to decide which category the internal table is falling:
- Sorted internal table with Unique Key
- Sorted internal table with non-unique key components X Y
- Sorted internal table with non-unique sorted key components A B C
- Hashed Table with Unique Key
Two reasons why this practice is important. The first is, the processing of data from the performance point of view and the second is reading the data in a faster way.
2. Usage of Dynamic SQL: The second thing one should invest in building dynamic SQL query for the where clause. It helps to compress your development from being lengthy to just a few lines. You don’t require to write SQL queries multiple times. Instead, build a dynamic SQL query once and use it several times. Suggest to use this whenever required.
However making source table as dynamic is not encouraged. Hence Select (fieldname) from (source tab) where XYZ is not allowed.
3. Progress Indicator: Check if you have used the Progress Indicator while processing the data in a loop. It gives useful information about the number of records processed, displays on the screen while running. It is one of the practice to make the development informative.
4. Processing of data in packets: As highlighted above within a box is another practice to allow the loop to process the business logic only after a certain number of records. By doing so, the data packets are formed that become fast performing. It is a good practice for performance optimization.
For example, by applying a statement like ‘IF lv_tabix MOD 1500 =0’ inside a loop, the control will follow for further processing only after a packet of 1500 records is formed. Record by record processing takes longer compared to processing data in packets.
5. Using RTTS: The practice of using Runtime Type Services can save a lot of effort from developing the customized coding. By adopting this practice, the type definition of data objects at run time and making the data type generic can be made possible. RTTS is a dynamic approach for programming which is an optimization technique for handling several data objects having different data types efficiently at run time.
SAP has provided several standard classes and a few important ones are given as below:
- CL_ABAP_TYPEDESCR: Useful for creating type attributes at runtime
- CL_ABAP_DATADESCR: Useful for handling data types at run time
- CL_ABAP_STRUCTDESCR: Useful for creating and describing structure at run time
- CL_ABAP_TABLEDESCR: Useful for creating and describing table at run time
Sample Example for declaring and using:
6. Authority Check Object: Another habit is of using the authority check object. Not relying solely on the role assignment, the authority check object can secure your development from the execution by the user departments. Sample Example:
7. Using Data reference operator: Sometimes it becomes important to create the dynamic table and structure which has type defined only at run time. In that case, the practice of using the data reference can save a lot of your effort. With the help of the de-referencing concept and the field symbols, one can easily deal with dynamic data types. One such sample example is given below:
8. Dynamic Creation of Class Objects through Factory Classes: When you need to deal with several custom classes in a report or any ABAP development, it is better to adopt the practice of using the factory class. All the custom classes when maintained in some kind of framework as part of the customization, the developer should create one factory class to instantiate the objects dynamically at run time based on the requirement. The practice below shows the example of creating the instance of a class dynamically at run time.
9. Using New Syntax: Evolution from 4.7 to ECC has introduced the new syntax for development. With the introduction of new syntax, the readability and the ability to modular the programming has been enhanced. Especially for Object-Oriented programming new syntax has been a great help. As a modern developer one should adopt the practice of using the new syntax for ABAP development.
Here are a few references:
10. ABAP Test Cockpit(ATC):
This is a practice for quality check. After the development is finished, how robust it is can be determined by ATC. It provides to check the quality of ABAP development with respect to standard guidelines of performance, authorization and usage of variables declared as global and local.
From the option: Program->Check->ATC, you can execute the Cockpit
The remarks for improvement the quality are shown as below which should be worked upon.
Conclusion and Summary
As I mentioned in the beginning that every evolution gives birth to new practices. So ABAP programming is no different and in the time when ECC is moving to S/4 HANA; it is time to adopt new practices for the development of quality robust software. There are several articles and blogs available in SDN for a few of the topics in detail as I explained above. Hence it is worth investing some time to go through each topic and understand them in depth. Good practice makes things easy and brings quality and the same goes for the ABAP development.
Let me know if this was useful for you.
Greetings, dynamic SQL should not be encouraged. There is tooling in SAP to check and optimize SQL, and none of these features are now leveraged.
You are right but my example is only for the where clause and not to make the source table as dynamic.
Select (fieldnames) from (tabname) where xyz is not the good practice but select xyz from abc where (dynamic query) should be allowed. And that is what I tried to explain.
I agree. It's error prone. Unless you need it to be dynamic, it's more robust to just have the where clause explicit.
Thank you for sharing this Himanshu. These are all good tools and techniques that should be in the repertoire of an experienced ABAP developer. I would like to add some thoughts to some of these points...
Regarding "2. Usage of Dynamic SQL", I would advice against this practice. Yes, your code example is shorter, counting number of lines. But there are many downsides which I believe should weigh in more, including:
Avoid these whenever possible. Use only when needed. Make sure to check input, for instance with cl_abap_dyn_prg.
Regarding "3. Progress Indicator", we want to use ABAP OO so we should encourage use of the class cl_progress_indicator instead of this function module.
Regarding "5. Using RTTS", "7. Using Data reference operator" and "8. Dynamic Creation of Class Objects through Factory Classes". These are great techniques and you are also saying when to use them. I would just like to underline what you said to use these only when needed and intended. as it may otherwise make the code harder to read, having less static and extended checks available, and the Where-Used functionality harder to use. Design patterns are good and should be used in their right places.
Again, this are good 10 practices that a developer should be able to use. Thanks! Let's just make sure to keep it simple and use the right techniques and tools at the right time.
Thanks for your insight. Regarding dynamic SQL, I have emphasized only on WHERE clause, not for making source table as dynamic. And yes, right techniques at right time is the key. Thanks again.
No. Only use dynamic WHERE clause when needed. Not as a general guideline. For the reasons above. Regarding security: ABAP documentation on dynamic where, and did you read this?
Quite right. As a general principle, capturing errors through the syntax checker is much cheaper than doing it at run time.
Regardless of whether it's just the where clause or not. I'd judge point 2 as bad programming and recject it.
it is very good. I am ready to translate your passage with Chinese in my blog again.
Hello Harry, please proceed. Just mention the original link as done for my previous blog. Thank you.