Tips & Tricks: Development


Are you losing out?
Upgrading SAP
SAP Truths
Good Ideas Dept.
Site Map
Contact / Resume

Tips & tricks toward 'better' developments:

     Seriously consider using ABAP Query

Of course there are some limitations with this functionality, but if you want to provide your users with a series of reports quickly with minimum maintenance requirements, then this functionality will serve you very well!

     If you do code, then code your reports using ALV (ABAP List Viewer)

Unbelievably good, cost-saving functionality by SAP!  Cut your report development time to an hour or two (literally), minimize your testing effort and still have the most advanced reporting capability and flexibility your users have ever seen!

Sounds just like a commercial, doesn't it? 

In the simplest scenario, you prepare the data to be displayed and pass it to SAP's standard ALV functions - that's it! 

    Use Data Dictionary (DDIC) structures to define report layouts

ALV essentially demands this approach, but you can use it in 'old-style' abap reports as well.  Instead of hard-coding what fields are output in a list, define them in a DDIC structure.  To expand the display, you can add a field to the DDIC structure without changing code.  This greatly simplifies both you and your users' lives.  It does mean that you have to make use of more general MOVE-CORRESPONDING statements when you read data from tables, but that is a small price to pay for the added flexibility and decreased maintenance effort that results.

    Read databases via their SAP-maintained indexes, not directly

Want lousy performance?  Read directly from a database table like VBAK, VBAP or VBEP - I'm ignoring the automatic index selection and reading that your database does at lower levels.  You can do one better than your databases optimizations!

Example:  Starting off with "SELECT * from VBAK..." is really inefficient.  Read the relevant entries by using VAKPA (Partner index) or VAPMA (material item index) first if possible.  It makes the world of difference to your run-times - especially when large data volumes are present.

    Old-style userexits: Use INCLUDE files

The 'old-style' userexits I'm referring to are those like MV45AFZZ, MV45AFZA, etc - empty forms where SAP allows you to enter your own code for specific purposes.  The fact that different developers can use the same code (MV45AFZZ) to extend the system can potentially cause maintenance nightmares.  Like all ABAP reports, this code is versioned, so multiple developers have to pay greater attention to the sequence of transports when moving the code via the Correction and Transport System (CTS) to the test environment. 

Avoid administrative and upgrade headaches by creating a series of include files that are referenced by each form.  Into each of these includes, create additional includes for each developer change.  Click here for an example.

    Use "CALL TRANSACTION" or use only SAP "approved for customer" function modules

SAP provides function modules that act as BAPIs to update transactions in SAP directly.  Be careful, however!  Officially, SAP may not support their use by customers as these function module are not "approved for customer use".  If you get inconsistent or erroneous results using them, there are likely no SAP-provided solutions to your problem!

Unless you're sure - or have it on good authority - stick with CALL TRANSACTION using BDC internal tables.