The concept of re-using code is well known. But have you considered the scale on how this ever so powerful concept is applied ? Coding should be composed with re-use as a focus point. But tools which are available in standard SAP's suite of funtionality should also be in the developers visor. They too should be part of custom solutions.
Abap allows anything to be developed, but not everything should be developed. If SAP delivers a message log tool which gathers, reports and stored messages on any subject, it should be considered when e.g. a custom interface is developed. For this example I'm referring to the Business Application Log or BAL, which is itself used by inbound Idoc processing, and can quite easily be used to gather processing messages and error messages for your custom interface.
Even if the tool is not a perfect match to what is needed, using it should be considered. Building a similar setup from scratch, which will yield a perfect match to the requirements may be an option, but it's good to realize that it is not likely a good option. Don't rebuild SAP functionality. Other than the simple fact that you would be burning away time (= money), your new functionality is not going to be as accurate and complete as the SAP standard version. And it will need to be tested thoroughly, before it can be used, more time lost. And it won't enjoy future upgrades that SAP will do on their components, another nice effect. You would be implementing a new-born Dodo.
So which re-useable SAP components should be considered. And how?
Let's say we build an interface for HR data. First of all we consider using the PU12 interface toolbox which is delivered by SAP. This article is about considering re-use options and we've considered PU12 but we disregard it for now. An interface needs process logging and error logging, for which BAL (as described above) is used. A nice little extra is that we can save the processing log, making it available under transaction SLG1. Only a few lines of additional coding for that!
The interface selection is done through a logical database PNPCE, which again is making good use of available resources, in this example quite specific to HR.
For some of the settings the example interface will use settings that will be stored in custom tables. Table maintenance is generated through DDIC and thus made available in transaction SM31. All fine, but there is a small gap to bridge here: for each custom table, simply add a button on the selection screen of the interface. This way the all standard SM31 generated functionality is linked to your interface.
As outbound interfacing does not involve updates, the report can be quite simple. You could consider composing an email with process details, or even interface result files, for which email bapi functionality is available. The body of this email could be derived from a standard long text (SO10).
A (never complete) listing of useful SAP components your application could lean on
- Business application log
- Logical databases
- Table maintenance (generated)
- Change documents
- Idocs
- Long texts
- BDC session recordings
- 10.000 bapis