Object Classification

The link between objects and their object identifiers is kept in table TADIR, which is better known as the “Object Directory.” This “Object Directory” is used by the Transport Workbench to prepare objects for transportation between SAP systems.

SAP has grouped their object identifiers in two main groups: “Whole-” and

“Sub-”object identifiers. “Whole” object identifiers are referring to one or more objects that can be transported to another SAP system as a single identity. For example, we can take the “Whole” object “R3TR PROG” object identifier that consists of several sub-objects.

LIMU REPS - ABAP Report Source Code Text LIMU REPT - ABAP Report Description LIMU VARI - ABAP Report Variant

We can transport these individual sub-objects separately, however, if we want to transport them together, we just include R3TR PROG into the transport.

There are two “Whole-” object identifiers: R3TR, which refer to transportable objects and R3OB, which are application objects. All “sub-” object identifiers start with LIMU. The combination of the PGMID, object type, and object name is unique in the system and stored in table TADIR. For example, ABAP program RSPFPAR is stored in its own unique row in TADIR as “R3TR PROG RSPFPAR.”

A complete list of supported object identifiers in SAP R/3 can be found in Appendix A, however, SAP BW does have additional object identifiers that are unknown to R/3.

TIP In table TADIR, you will find a PGMID that is called “HEAD” and object type

“SYST” and object name “<your database SID.” When you have to reinitialize the Transport Organizer with SE06 or STMS after a database refresh using one of SAP’s system copy guides, this particular row in table TADIR is adjusted.

4.1.2 ABAP

ABAP is a programming language that is shipped with all SAP software products based on the SAP NetWeaver ABAP AS. The history of ABAP is almost the same as the history of SAP AG itself. ABAP was created as a “reporting” language for SAP R/2, the predecessor of SAP R/3, in the late 1970s. ABAP stood for “Allgemeiner Berichts- und Aufbereitingsprozessor,” which in English means “General Reporting and Preparation Processor.” With the release of SAP R/3 in 1992, SAP also released a new evolved ABAP/4, which stood for “Advanced Business Application Programs/fourth generation language.” SAP R/1 and SAP R/2 were both programmed in Assembler/370 and at that time ABAP was basically a sequence of assembler macros and instructions. In order to overcome some shortages of ABAP, SAP developed ABAP/3, which was a third-generation language extension of ABAP and offered the ability to create business programs and dialog controlled transactions.

The programming language ABAP/4 is accessed through the ABAP Workbench, which allows developers to create programs, screens, and menus.

The business functionality of R/3, BW, CRM, SRM, and APO is entirely written in ABAP/4. The combination of ABAP/4 language, the ABAP Workbench, and the scalability of the SAP Basis Kernel helped some companies decide to use it as their enterprise development platform. SAP has evolved this to the “standalone” SAP Web Application Server as a runtime platform for general applications.

SAP still implements improvements on their ABAP AS. Even now a lot of development effort has been shifted into the Java AS space. ABAP supports object

orientation and is therefore called “ABAP Objects.” The latest development includes the support of Web browser–based applications and server-side scripting. SAP answered to the increasing demand for so-called xSP-based Web servers (x Server Pages, like ASP = Microsoft Active Server Pages and JSP = Sun Java Server Pages) with BSP (Business Server Pages). BSP allows developers to combine HTML with ABAP coding and generate HTML output for Web browsers. Both server-based scripting through BSP and client-based scripting through JavaScript is supported.

ABAP code is written in the ABAP Editor, which is part of the ABAP (or Developers) Workbench and stored as ABAP source code in table D010S for SAP Basis release up to 4.6C or table REPOSRC for releases as of 6.10. After the program is written, it is generated (or compiled) to executable code. This executable code (also known as report load) is stored in the tables D010L, D010Q, and D010Y for SAP Basis release up to 4.6C or table REPOLOAD for releases as of 6.10.. However, this load is not directly executed by the CPU, but rather through the ABAP Virtual Machine, which resides in the SAP Kernel. This process is more or less similar to the Java language, where the Java source code is compiled by the “javac” compiler into a platform-neutral class (Java byte code) format that is interpreted by the Java Virtual Machine (jre or java). There is a significant difference between the two byte-code formats; SAP uses Little- and Big-Endian formats to store their compiled coding. Therefore, ABAP report loads cannot be exchanged between a machine, which supports Little Endian (such as Alpha or Intel) and a machine that supports Big Endian (such as SPARC, HP-PA, and PowerPC). In case a database is exchanged between these kinds of machines, all ABAP report loads need to be regenerated.

After the generation of the ABAP source code, the resultant ABAP loads are stored in three different tables. The ABAP load consists of four tables in the database: D010LINF, D010L, D010Q, and D010Y. The table D010Y is no longer used as of SAP releases above 4.6. Table D010L or REPOLOAD contains the actual ABAP load, tables D010Q and D010Y contain the line references or the symbol table of the generated program. Table D010LINF contains general information about the load, such as the last time of change and the size of the data in D010L, D010Q, and D010Y. When you run your application servers (dialog instances) in a mixed environment on Intel CISC machines and UNIX RISC machines, you will have double growth in these load tables: both Little- and Big-Endian data will be stored.

Every time an ABAP program is changed, it needs to be regenerated before it can be used. If a program has not been generated in advance, the ABAP Virtual Machine will do this on the fly. However, this will impact the end-users response time. During one of the upgrade phases, better know as Repository Switch, the entire library of ABAP programs is changed. However, the ABAP report load is not changed, therefore, all ABAP programs need to be regenerated after the upgrade.

Figure 4.2: Edit, compile, and run an ABAP program.

TIP The compilation phase of ABAP programs is known under two terms: generation and activation. Both terms are used by SAP.

When you perform an OS/DB migration using the R3load toolset, the ABAP load tables are not copied over. After the migration, you have to run SGEN to populate them again.

It’s also possible to delete all entries from this table in case of an inconsistency:

(1) Be sure all users are of the system

(2) Delete all ABAP loads (for Oracle RDBMS):

SQL> truncate table SAPR3.D010L;

SQL> truncate table SAPR3.D010Q;

SQL> truncate table SAPR3.D010Y;

SQL> truncate table SAPR3.D010LINF;

(3) Run transaction SGEN to regenerate all ABAP loads

As of SAP Basis release 6.10 and above, the ABAP Source and Load tables have been changed. The ABAP source is stored in table REPOSRC and all ABAP load is stored in REPOLOAD. Therefore you remove the load inconsistency by just delete all rows from table REPOLOAD only, using “truncate table” statement. More information can be found in SAP Note 668560.