When implementing with ABAP, there are several aspects that have to be considered to accomplish a good design. Above all we have to remember that we are talking about a system having its roots several years ago, as one can partly track from the fact that ABAP is a COBOL offspring. Not a bad thing at all because COBOL was developed as a language specialized onto the implementation of business cases. SAP NetWeaver of course is more flexible within its architecture and a customer could upgrade the quality of his systems by upgrading to NetWeaver or introducing it additionally to combine with current systems. Here comes some food for thought for extending a SAP legacy system with ABAP.
Considerable Aspects
It follows a list of aspects to be considered during development. The list of course is not complete.
Dynpro persistence
When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help. The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
Memory Cache
It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this. Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
Interfaces
It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information. One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it. A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
Extending SAP logic
The message about modifications should be seen as a general rule not only associated with interface problems or problems using/calling an existing functionality. As I wrote in my weblog entry EXTENDING A SAP-SYSTEM: Experience Report, extending a SAP system is not always an easy task sometimes requiring experience. If you cannot use BAdI's, customer exists, screen modifications or something similar, you would need to modify the original code which could not be safe on updates. When thinking about modifying original system code one should try to inject as few instructions as possible. IMO, it would be "cleaner" or "safer" to do a modification by adding a call to a newly-to-create function module which in turn gets and sets parameters instead of doing all the stuff in the original code. With that one could easily change his logic afterwards without needing to modify original code again.
Conclusion
For some development tasks regarding the extension of current logic experience is a good consultant. If not sure it would sometimes be best to consult someone available capable of evalating the situation. In many companies it is good custom to only modify original code after having written down the problem and having someone review it. Concerning workarounds or tips & tricks in general, a cookbook or guide could be created evolving over the time allowing to add new experiences and knowledge later on. Customer reports fulfilling special tasks could help in taking the load from the developer for some tasks.
