When faced with complex tasks, procedural programming comes up against limits. In the SAP R/3 component for Sales and Distribution (SD), for example, if several SD documents, rather than just a single one, are to be stored in the working memory, an ABAP programmer will have a lot of work to do. He or she has to change the function module interface, store the data in new internal tables, and must modify and test all the programs that use this function module. This is complicated, takes a great deal of time, and is susceptible to errors. In addition, the program becomes larger, which adversely affects response times.
Data and functions combined
The object-oriented approach is different. Here, any number of new objects can be generated easily. In object-oriented programming, data and the related operations, functions, and procedures are no longer separated from each other, as they are in procedural programming, but are instead encapsulated together in objects. Processes can be implemented that accurately reflect reality. However, the encapsulated information core of an object remains protected against unwanted intervention from outside. Each object is responsible for its own data, so to speak. In addition, this encapsulation provides better structuring possibilities, as well as continuity in the software development process. In contrast to the function group, which can exist just once in the main memory, objects can therefore exist any number of times in the main memory. As a result, there is no programming effort involved if – going back to the previous example – several SD documents are required, rather than just one.
The design aims pursued by SAP with ABAP Objects were simplicity and the use of object-oriented concepts, which have proved successful. The development effort involved in writing ABAP and ABAP Objects programs is about the same. In general, main programs created in ABAP Objects are less extensive because of their object structure, and as a result, they are above all easier to maintain. In the most extreme case, the main program itself contains practically only the addresses of the objects, known as pointers. The actual program is programmed via the objects. It should be noted that not all of SAP R/3 is programmed in ABAP Objects. For example, screen templates can only be programmed procedurally, but within the templates, commands in ABAP Objects can be used. ABAP Objects, as a genuine, compatible enhancement of ABAP, uses classical ABAP statements, just as Objects statements can also be used in procedural programs.
The example of the SD document
One particular property of object-oriented programming languages is the principle of inheritance. Subclasses can inherit methods and attributes (functions and data), but their specific characteristics can then be changed. The class forms the “lowest common denominator” so to speak, while the subclasses contain the differences to the rules. To go back to the example: SD documents such as “quotation,” “order,” or “delivery note” have a great deal in common. They can be created, changed, deleted, and printed. Therefore it makes sense to use a general class, “SD document,” for these tasks. “Order,” “quotation,” and “delivery note” inherit all attributes and methods from this class, and can be used without further programming. But now we come to the differences: It is only possible to delivery goods with the delivery note, for example. The method – that is, the function – “deliver” must be added for “delivery note.” As the class “SD document” is not familiar with the method “deliver,” the quotation and order are not familiar with this method either. Therefore only the things that differ from the class need to be programmed (“programming by difference). This considerably reduces the work involved and also meets the demand for easily extensible program components for software development.
In addition, “quotation,” “order,” and “delivery note” have different output when they are printed, so different coding is required for “quotation” and “delivery note” for the method “print.” ABAP Objects provides support for the programmer here, too. Class-specific processing is specified by redefining methods. In addition, because the coding is “attached” to the object, the programmer does not need to worry about whether the correct coding is used when the method “print” is called for any object in the class “SD document” or its heirs. This property is known in the industry as polymorphy (existence in many forms).
BAdIs replace user exits
SAP R/3 is a standard software. However, SAP products can be tailored to customers’ specific requirements. What if a customer wants to see the current stock of a particular article in the order, for example? The most impracticable solution would be to modify the standard solution. However, in this case, each new support package from SAP would mean more work for the customer’s system administrator, who each time would need to ensure that the customer modifications were included in the new program.
To avoid this problem, SAP provided user exits, which are fixed points in the program, with a defined interface. They are only there to enable the user to call separate functions – such as the current stock level – at particular points in the program. The space available in a user exit is restricted, however. If it already contains one function, others can only be appended at a subordinate position. This is particularly problematic for add-ons and country modifications. They take up space that was really intended for customer modifications. Recently, business add-ins (BAdIs) have provided support in this area. Business add-ins are created using ABAP Objects and enable the same point to be used several times (that is, country modification, IBU, add-on and customer), without these modifications obstructing each other. Partner solutions for the mySAP Business Suite primarily contain BAdIs.
The proven procedural language ABAP still has its place, but ABAP Objects is its logical extension, because the systematic use of the object-oriented approach ensures that programs can be maintained and extended more easily, subcomponents can be reused more simply, and the individual tasks in large programming projects can be defined more effectively. The main principle of object orientation is to take an overall view of the data and functions for the real-world objects that need to be mapped to the system.