I received an e-mail last week notifying me of openings for IT managers in an SAP R/3 4.6c installation on the East Coast. Not surprisingly, there was a list of desired skills appended to the job listing. At the top of that list was SAP’s Advanced Business Application Programming language, version 4 (ABAP/4). This is just one small indication of the increasing importance of this language. If you are not on board yet, it might be time to make your move.

Of course, before using ABAP/4 on the job, prudent managers should have a strong sense of when its use is appropriate and a solid conceptual grasp of how it handles data. Once you’re there, you’ll find ABAP/4 to be one of the easiest-to-use fourth-generation languages (4GL) you’ve ever encountered. Here are some ABAP/4 tricks that can make your work more powerful and elegant.

Third in a series

This is the third installment in a series on ABAP/4 and SAP. The first article on this topic argued that ABAP/4 is likely the best choice for SAP applications. The second article dealt with ABAP/4 fundamentals for SAP application development.

ABAP/4 basics
ABAP/4 takes the “English-like” coding concept to new levels. It is easily mastered syntactically because its natural language features make it simple to learn. There are the usual reserved keywords, and these generally come at the beginning of a statement, followed by parameters and data objects. Statements end with a period. A group of statements beginning with the same keyword can be grouped together with a single occurrence of that keyword, followed by a colon.

Here are a couple of examples:
types string_name(20) type c.
 
data text_name type new_name.
 
write ‘this is text’.
 
data: a type i,
       b type i.
 
perform write_data changing first_item.

As you can see from the examples above, ABAP/4 is easily learned and applied. ABAP/4’s convenient syntax and rules make source code understandable even to nontechnical IT managers. ABAP/4 programs are consequently easily maintained and extended.

The integrated dictionary
ABAP/4’s integrated dictionary is a wonderful feature that not only facilitates rapid and clean construction of applications, but aids in the creation of groups of compatible applications, very important in an environment where application integration and distribution is a central goal. The integrated dictionary ties together all of ABAP/4’s data-handling utilities. It works like this:

  • At the local application level, you use the elementary data types (integer, character, and so on) to build more complex types (as in the creation of documents).
  • You construct actual objects using the two basic construction mechanisms: the record (a structure with a fixed number of objects) and the internal table (with a variable number of records).
  • You store the definitions of the complex types and aggregate data structures in the internal dictionary, taking them beyond your local application and making them shared components of the system.

The dictionary is simple and familiar, yet elegantly applied in the ABAP/4 development environment. It is actually difficult to write a program badly if your design is thought out well and your data types are clearly understood and implemented.

Internal tables
Internal tables are the data-handling workhorses of ABAP/4. You’ll use internal tables with the database once you’ve finished working with business objects. If you’ve defined your types well and built sound records, you can generate tables almost effortlessly. For example:
data: begin of ordering,
        UPC(14) type c,
        prod_name(25) type c,
        prod_qty type I,
end of ordering.
 
data ordering_table like ordering occurs 120.

In the above example, the first statement defines a record. The second generates an internal table. You can fill an internal table with inbound data from other applications, loaded into records. You can fill an internal table directly from a database with an APPEND statement. You can move an entire table of data from one internal table to another with a MOVE-CORRESPONDING statement. Also, you can passively summarize data objects moving out of a table with a COLLECT statement. Put simply, ABAP/4’s internal table facilities make the manipulation of data objects in database-appropriate aggregates incredibly convenient.

Function modules
In the integrated environment of SAP, the integration of data objects and applications into one huge, extended system is the whole point of enterprise databases. So your ABAP/4 programs, in the midst of local processing, will often divert to some external process or need to pull in objects from other databases. This activity begins with functions and continues with Remote Function Calls (RFC).

The strength of functions, subroutines, and RFCs in an environment like SAP is that they are about more than consolidation of code and processing efficiency. They are the lifeblood of continuity in data object handling when data objects and the rules for processing them are shared not only across applications, but across business units as well. As with any application software, you can manually create a function in ABAP/4 with ease. Here’s an example:
call function ‘ONE_LINE_FUNCTION’.
 
function ‘ONE_LINE_FUNCTION’.
      write ‘This is a one-line function.’.
endfunction.

The ABAP/4 workbench makes it even easier to create and store functions into groups. You can combine functions for object processing in logical aggregations for later use in other applications and easily modify these groups, maintaining consistency with little effort.

You can generate a single function by clicking the Function Group Objects button on the Object Browser screen. On the screen that follows, give your function a name and click the Create button. You’ll be prompted for your function’s attributes and then you will choose a Function Group.

This is where your function facility gets a dose of real SAP power. Function groups are bound together by the fact that they share data structures (forms) defining your business objects and documents. You are basically creating and maintaining (with a single mouse click) document-specific data definitions and toolkits applicable across applications, across business units, and across databases. SAP keeps track of it all for you. As an organizational feature, this is formidable, but consider the convenience to you as an IT manager. When you are creating something new, you have at your fingertips all the predeveloped structures and procedures used by similar applications. You don’t even have to look them up—they’re all in one place and instantly listed. When you are maintaining an existing app, the same applies. One click and you’re there.

Only the beginning
SAP’s in-house programming language is 4GL, object-oriented, and packed with strong data-handling features for a complex database interface wrapped in a versatile and easy-to-use development suite. What I’ve shown you so far are the building blocks of local applications, which by their nature extend into the greater SAP terrain.