MVC Design Pattern + Clean ABAP

The Appetizer

I’ve been going through different phases as a software developer or programmer. I’m sure many of you too. At the beginning, it was the phase of “Eureka”. The phase when you finally made the program compiled successfully and Hello World appeared. Then it was the phase of frustration when sometimes the problem you were trying to solve was beyond you. You may crawled into the internet web to find answers and once you found it, you copy and paste the solution to your work and Voila! your program up and running properly again.

This phase can take a toll on you because it might affect the way you code. You may think that it doesn’t matter how you code, as long as it works and the output met the expectations, that’s the only important thing. Your code maybe full of different patches of codes you copy and paste from the internet and eventually might look like this:

Source: https://www.instructables.com/How-To-Patch-Your-Clothes/

The point is, to be a better software developer or programmer you should look beyond working code and take it steps further. You should also consider how to make the code runs better performance-wise and also write codes efficiently, effectively and cleanly. The reason behind that because you might not the only one dealing with the code in the future. Someone else might come to your code and it might be difficult for them to understand it. Sometimes it’s just not about skill, sometimes it’s just too complicated to understand and everything just could have been simpler.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Now I’m at the transitional phase and still trying my best to write a better code. In SAP ABAP, there’s a concept or guide or principle called Clean ABAP. In this article I’ll share my experience building an SAP Report with the Clean ABAP principle. I might not applied it all or even applied it correctly, so any input regarding my code is welcome.

The Main Course

SAP ABAP can both be done in procedural and Object Oriented. I used to code in procedural quite a lot until I discovered that OO can bring a lot more into the table. It segmented better and can be refactored and tested more easily than procedural code.

The transition is not easy eventhough I already learnt the basic of Object Oriented back in College. I guess this is also because old habit die hard.

Since in procedural I used to group code block like this.

That’s why to make the transition smoother I adopt one of the design pattern called MVC. This design pattern similar in a way it separates the code block into 3 parts. Instead of divided by Subroutine and INCLUDE, the design pattern divide it by 3 Classes, the controller, the model, and the view. However in my code below I chose to design it with 2 Classes while the view is inside the REPORT Program itself. The program creates Sales Document Report using ALV by combining 2 database table sources.

The Controller Class Definition

Here are the Clean ABAP principles I followed:

1. Use nouns for Classes and verbs for Methods
   The Class name is zcl_controller (noun) while the Method name is get_object (verb)
2. Avoid encodings especially hungarian notation and prefixes
   I usually used prefix for variable such as gt_ (global tables), im_ (import), ex_ (export), etc. Instead from the code above I only use name as the importing variable name with no longer using prefix.

The Controller Class Implementation

Here are the Clean ABAP principles I followed:

1. Avoid encodings especially hungarian notation and prefixes
   Variable name without prefix as explained above
2. Use class-based exceptions
   I used some standard exception classes to mitigate error when creating object and casting.
3. Use |{ }| to assemble text
   I used to concatenate strings but this approach is simpler and tidier. The implementation of this principle can be seen in how I assemble text for the message error in the exception handling.

The Model Class Definition

Here are the Clean ABAP principles I followed:

1. Use nouns for Classes and verbs for Methods
   The Class name is zcl_model (noun) while the Method name is get_sales_docs (verb)
2. Avoid encodings especially hungarian notation and prefixes
   I usually used prefix for variable such as gt_ (global tables), im_ (import), ex_ (export), etc. Instead, from the code above I only use doc_date as the importing variable name with no longer using prefix.

The Model Class Implementation

Here are the Clean ABAP principles I followed:

1. Avoid encodings especially hungarian notation and prefixes
   Variable name without prefix as explained above.
2. Use plural
   I use this principle to differentiate more between singular line of data (work area) or plural (internal table). Hence for itabs I chose the name sales_doc_headers, sales_doc_items, and sales_docs (plural) while the work areas are sales_doc_header, sales_doc_item, and sales doc (singular)
3. Prefer insert into table to append to
   On the line 28, INSERT INTO TABLE is used instead of APPEND for adding data from Work Area to the Internal Table
4. Prefer is not to not is
   On the line 12, IS NOT INITIAL is used instead of NOT IS INITIAL.
5. Avoid obsolete language elements
   On the line 8 and 14, the @-escaped "host" variables make a little clearer what's a program variable and what's a column in the database

The Controller ( Report Driver Program)

Here are the Clean ABAP principle I followed:

1. Use constants instead of magic numbers
   model_name and report_name are created as constants instead of assign it as string directly for Model Name and Report Name. This actually still can be improved by maintaining the hardcode values in TVARVC Table. More on this here: https://blogs.sap.com/2021/05/26/avoid-hardcoding-in-sap-by-tvarvc-or-setleaf/
2. Use class-based exceptions
   I used some standard exception classes to mitigate error when creating object and calling method.
3. Use |{ }| to assemble text
   I used to concatenate strings but this approach is simpler and tidier. The implementation of this principle can be seen in how I assemble text for the message error in the exception handling.
4. Do not chain up front declarations
   As the Clean ABAP suggests : “The Chaining suggests the defined variables are related on a logical level. To consistently use it, you would have to ensure that all chained variables belong together, and introduce additional chain groups to add variables. While this is possible, it is usually not worth the effort. Chaining also needlessly complicates reformatting and refactoring because each line looks different and changing them requires meddling with colons, dots, and commas, that are not worth the effort.” Hence the way the Constants initialized on the line 3 and 4.
5. Prefer inline to up front declarations
   On line 13, this is the preferred way to initiate variable and assign the value to it with one command. If you follow these guidelines, your methods will become so short (3–5 statements) that declaring variables inline at first occurrence will look more natural.

The Model ( Report Driver Program)

Here are the Clean ABAP principles I followed:

1. Avoid encodings especially hungarian notation and prefixes
   I usually used prefix for variable such as gt_ (global tables), im_ (import), ex_ (export), etc. Instead, from the code above I only use doc_date as the exporting variable name with no longer using prefix.
2. Use class-based exceptions
   I used some standard exception classes to mitigate error when calling method.
3. Use |{ }| to assemble text
   I used to concatenate strings but this approach is simpler and tidier. The implementation of this principle can be seen in how I assemble text for the message error in the exception handling.

The View ( Report Driver Program)

Here are the Clean ABAP principles I followed:

1. Don’t call static methods through instance variables
   Displaying ALV Report using the static Class CL_SALV_TABLE. Hence to use it, creating the instance of the class in unnecessary. A static method is attached to the class itself, and calling it through an instance variable is a potential source of confusion.
2. Prefer inline to up front declarations
   On line 8, 15 and 19, are the preferred way to initiate variable and assign the value to it with one command. If you follow these guidelines, your methods will become so short (3–5 statements) that declaring variables inline at first occurrence will look more natural.
3. Use class-based exceptions
   I used some standard exception classes to mitigate error when there is an ALVrelated error.
4. Use |{ }| to assemble text
   I used to concatenate strings but this approach is simpler and tidier. The implementation of this principle can be seen in how I assemble text for the message error in the exception handling.
5. Prefer functional to procedural calls
   On line 16, 17, 20 and 22 are the preffered way to call method instead of the needlessly longer CALL METHOD command.

Here are the Clean ABAP principles I followed Overall:

1. Use descriptive names
2. Use same abbreviations everywhere
   People will search for keywords to find relevant code. Support this by using the same abbreviation for the same thing. For example, always abbreviate “detection object type” to “dobjt” instead of mixing “dot”, “dotype”, “detobjtype” and so on.
3. Avoid noise words such as data info object
4. Keep methods small

So there it is a simple REPORT program with MVC that applies Clean ABAP. I am sure I miss some stuff here and there. If any of the principle not mentioned maybe it’s because I already regularly apply it or maybe even because I don’t know how to apply it properly. Any input regarding this is very much welcome. It will be really helpful for me to improve.

More about the Clean ABAP here: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md

Visit my Github Repo for the complete version of the code here: https://github.com/aufaraditya/ABAP-MVC-Design-Pattern-Template

I hope this article is useful in any way.