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.
