Technical Articles
Why you should not add business logic to SAPscript, SMARTforms or Adobe forms
About this blog
In my opinion, it’s simple: there should be no ABAP code in SAPscript text elements or SMARTforms global initialization or form routines. Or rather, no ABAP code that executes business logic. This means: no calling of BAPI’s or other functions or methods to fetch data, no SQL-statements, no calculations (except perhaps summing amounts or quantities or things like that), etc etc. A print program should trigger the business logic functions and classes and, once the data is fetched from the database tables and all calculations have been executed, the responsibility of the form is formatting this data and presenting it.
Below, you can read some of the arguments behind my stand on this issue, but I’m pretty sure that there are more. So please feel free to add your two cents.
Maintenance – analyzing and reusing stuff
Using a clear separation of business logic code in your print program (and the methods and functions it calls) and form logic in sapscript and smartforms forms makes it a lot easier to:
A find the correct place where to change the business logic;
B analyze issues related to business logic;
C Reuse logic in other contexts, using other UI’s etc;
D execute Impact Analyses when you have to change custom functions, classes, DDIC-definitions;
E prevent duplicate code;
F No version management of code inside forms;
ad A+B)
If your business logic can be found in both print program and logic within the form, it’s more difficult to find the location(s) where you have to change your code or find the exact spot where it all goes wrong.
A worst case scenario is a dynamically called external subroutine from within a SAPscript text element: calling a subroutine where the name of the program and subroutine are populated at runtime by the print program.
ad C)
If your print program contains all of the logic, switching from sapscript to smartforms to adobe forms becomes a lot easier, because you only have to focus on the changed form and its interface.
Code that is inside your SMARTform or SAPscript text element can not be reused in other contexts.
ad D)
Code that is inside a generated SMARTform function will not be found using WHERE USED functions. So you won’t know that the function you are going to change is also called from within such a generated SMARTform function.
ad E)
As said above, you can’t reuse code that is programmed in SMARTform or SAPscript forms. And besides that, I have seen lots of SAP systems with forms that are almost identical in format and in abap code.
In SAPscript it is even worse; for every language version of a form, you have to maintain the text elements. If they contain (pseudo) abap code, you have to maintain this for every language.
ad F)
Both SAPscript and SMARTforms don’t support version management. Comparing versions or restoring old versions of the code is not possible.
Performance – doing it again and again and again
Every time a generated SMARTform function or a SAPscript form is called, the business logic functions/statements within these forms are executed again. If the print program contains all of the business logic and just passes the data/results to the forms that only takes care of formatting the data, the same data can be reused for multiple forms that are called from the same program. If the smartform function contains the business logic, it is executed every time the form is called, event if you just want to process for example two copies of the same form.
Quality control – Code Inspector
A generated SMARTform function cannot be checked using the Code Inspector (at least, in my reference system I get a message “This is a SAP object that cannot be checked”. ). This means that, without a little tweaking of the Code Inspector tools (or writing your own version), it’s not possible to check your SQL statements or internal table handling for possible performance issues or any other issue that the Code Inspector is able to find.
And if you have manipulated the code inspector, for example by using the replace option in debugging mode, you get messages related to the generated function module code and you have to filter them on the parts of the function that contain your code.
Summary
Simple: keep the business logic out of your forms. Let your custom program gather all the data and execute all of the needed calculations by calling and using the proper methods and functions. Then pass the resulting data to the form and let the form only take care of formatting this data.
Hello Ben,
Great reading all your blogs on SCN last couple of months!
I completely share your opinion, and to add: in Adobe Forms the interface 'code editor' is just horrible.
On a sidenote:
My personal preference at the moment is to create 1 static class for each form, with all the method calls in which do the business logic and build/get the final tables.
Although I'm a fan of static classes, the disadvantage is that we cannot subclass it anymore, so it might be best to always create an instance class ( but somehow I keep doing static classes .. ).
Example of how SAP does it: CL_PURCHASE_DOC_OUTPUT superclass with CL_PURCHASE_*_OUTPUT subclasses.
Their flow is as follows:
1. Create instance with some initial parameters ( NAST ) which are set in attributes
2. Call classmethod READ which calls some other read/collect methods
3. Print program accesses the public instance attributes with all the tables
To be honest, I'm thinking of adapting this design as a template for my next form developments.
Regards,
Wouter
Hello Wouter,
Thank you. Actually, the code editor in both SAPscript and SMARTforms are also horrible or even worse than that.
Ben
Hi,
I would like to compare above blog in relation with factory class of alv generation.
we just need to design(layout) smartform rest of all depends on passing parameters(that is data to be shown)....
Avirat