SAP ABAP

A Brief Comparison:

ABAP (Advanced Business Application Programming), is much like a COBOL and/or C hybrid. The value versus reference feature reminds me of C. The commands (MOVE, WRITE,…) and PERFORMs remind me of COBOL. ABAP constructs (Loops, subroutines, if/then,…) seem similar to constructs in other languages. The only aspects of the language not communicated in this web site are SAP GUI related features (Like functions defined in the SAP GUI). I felt ABAP GUI features/impacts would be too difficult to accurately explain.

Main ABAP parts

Introduction

The Event Concept

Data Dictionary

Locking Mechanism

Data Types

Commands

Control Structures (Flow Control Components)

Constructs (Flow Control Commands)

Tables!

More on Move and Compute

Copying Structued Objects

Arithmetic Expressions and Mathematical Functions

Concatenating and Splitting Strings

Shifting Strings

Replacing and Translating Characters in Strings

Searching Strings

Sizing Internal Tables

Solutions for retrieving lines

Updating Database Tables

Logical Databases

Drill Down and Other Stuff

Program Logic Flow (PAI and PAO)

Introduction:

SAPs ABAP is an event driven, 4th Generation Language. ABAP is not designed for sophisticated technical or scientific calculations, however, it is a high performance, portable, extensible language/solution! All of SAPS applications and part of its basic system are developed in APAB4. ABAP leverages the power of Open SQL (A subset of ANSI SQL including Select, Insert, Update, Modify, Delete, Import, and Export) and Remote Function Calls (RFCs) which allow direct program-to-program communications between R/3 Systems, between R/3 Systems and main frame-based SAP R/2 system, or between an R/3 system and external programs (VB, C++,…) with no need to consider the communication protocols, network details, or code pages. ABAP code is compiled to program code and stored in the Repository then ran (interpreted execution) on the application server. In SAP user actions and system events control the flow of an application. When an event occurs, all statements between the corresponding EVENT keyword and NEXT event keyword (To be discussed later in this content) are processed. There are many events and related rules, for example: the on-click event statements are coded after the ‘at line selection’ command (To be discussed later in this content). ABAP is not case sensitive except, as in most languages, when it comes to literals delimited (write ‘X’, WRITE’X’ are equivalent but write ‘X’, WRITE ‘x” are not equivalent). An ABAP program in an event-driven language can react to various events. For example, a user clicks on a button or double-clicks on a line in a list, and the program responds by opening a dialog box or prompting another action.

The event concept

The event concept is great, because the system automatically handles events. Events are triggered by the user or the system, so they are said to constitute the external flow of control. The external flow of control represented by events documents the main steps that occur at runtime. The internal flow of control the logic processed for an event. Each program always contains a default event start-of-selection (To be discussed later in this content). The order of the event statements in the source code of a program is completely irrelevant. There processing order is only determined by the corresponding user or system action.

The SAP Integrated Dictionary and Repository

The Dictionary and Repository are cornerstones of SAPs developers workbench. SAPS Dictionary, contains Development and Runtime Objects including Data Models, Dictionary types, Table Structures, Programs, Screens, Functions, GUI statuses with menu functions and icons, Language-dependent texts like help info-docs-errormsgs, report Variants, and ABAP/4 Queries. SAPs Repository includes the SAP Dictionaries, Data Models, Program definitions, Screen definitions, and Other Elements (metadata about fields, structures, and tables). Development Workbench tools include: Object Browser, ABAP/4 Language, Repository and Active Dictionary, Data Modeler, Query, Organizer (Test, Analysis, Performance Measurement Tools).

The dictionary guarantees a consistent usage of database tables, their structure definition must be available in development and runtime objects – The integrated and active ABAP/4 dictionary takes care of all of these things. If a dictionary object is activated, the new version is automatically available in all objects of ABAP/4 Repository. Changes to a dictionary object are distributed to all dependent development objects. As an alternative approach to dictionaries, you could use header files, which contain the global definitions and are included in all programs using an element of that header file. HOWEVER, changing a header file means that all referring to it must be recompiled, even if they only use unchanged data definitions. The ABAP/4 Dictionary has the advantage that a program with unchanged source code is only generated if one of its Dictionary objects has been activated since the last generation. This allows you to change and enlarge global definitions without affecting programs that don’t use them. The Dictionary objects reside on 3 levels (in 3 layers):
•    Tables and Structures.
•    Data Elements: Different roles played by a single domain.
•    Domains: A domain describes the technical properties of a table fiels. It specifies the set of allowed data values for that field and its output characteristics. It determines the length and type, a possible foreigh key relationship, and the number of decimal places.

Locking Mechanism:

•    A Logical Unit of Work (LUW) is a set of steps in a transaction (Like Insert 2 Rows, Update 1 Record, Delete 1 Record .. the SQL commands between the first and the command COMMIT).
•    A Transaction is a program that changes objects in a database in a consistent way. A transaction is defined in the object browser. Transactions are called by menu functions or from programs. You can start transactions from a program by (1) Issuing the command CALL TRANSACTION, (2) Issuing the command LEAVE TO TRANSACTION, or by (3) using a standard function with a variant as parameter. When the user finishes the called transaction the system returns to the caller if called by a simple call transaction. If you start a transaction with LEAVE TO TRANSACTION the calling transaction is finished immediately and the user won’t come back to that transaction (All entries of the transactions are popped … in the context of this subject PSU refers to oading information and pop refers to unloading information. Using the SKIP FIRST SCREEN of the command CALL TRANSACTION and LEAVE TO TRANSACTION allow you to suppress the initial screen of the called transaction.
•    All LUW steps must complete successfully before a LUW is submitted as part of a transaction.
•    An unsuccessful LUW results in a data object/base Roll Back to the last successful LUW.
•    An Update tasks can handle database changes. In fact, it would take less effort to use the UPDATE TASK technique instead of collecting the transaction data in internal tables (to be discussed later in this content) and figuring out the proper opportunity for the COMMIT WORK Command. You write a set of functions containing the database change operations (this update function needs to be classified in the function administration screen as UPDATE WITH START IMMEDIATELY). The addition of IN UPDATE TASK has the effect that the function is not invoked immediately. Instead the data is transferred with the function call to an intermediate system area. When the IN UPDATE TASK is used the COMMIT WORK command does not execute the database commit directly but rather delegates the commit to the asynchronous update task. The update task takes the data from the intermediate system area, executes the update function, and releases all locks of the calling dialog transaction. After the COMMIT WORK statement a dialog program does not wait for a response from the update task – an end user can continue working even when the system load is very high. Here is an example of UPDATE TASK being used:
Call function ‘ABAP_TEST’ in update task
Exporting I_bookings = bookingsM
I_actfli = actfli.
…
commitwork.
Data Types
Return to Table of Contents
As in every language, are available and can be categorized as follows:
•    System Fields: Variable/Information available for utilization from any process. Some examples are SY-DATUM (Used in Date Processing) and SY-INDEX (Used in Loop processing).
•    Complex Non-Elementary Types and Data Objects: A Next record is an example:
* IN the following the person structure is a nested structure:
Types: Begin of address,
City(25),
Street(30),
End of Address,
Begin of Person,
Name(25),
Address type address,
Endo of Person.
Data Receiver type person.
* TableName-FieldName = …
Receiver-name = ‘Smith’.
Receiver-address-city=’Big City’.
Receiver-address-street = ‘Main Street’.
•    Elementry Types: Base Data types that include character, number (integer, packed, floating), date, time, Hex, non-complex records, and tables. These types are defined with the key word DATA. For example ‘DATA GL_TASK(240) type character’.

Internal tables in ABAP :

Only live during the runtime of a program. Used as snapshots of database tables or as containers. You can combine the contents of different database tables into one internal table creating a temporary view. Can consist of any number of lines (or entries) of identical type. You should know in advance how many lines will be inserted into an internal table at runtime to get the best performance. Tables are collections of Records created with the combination of the reserved words TYPEs, DATA, and OCCURS (For performance the occurs documents the estimated upper limit for the lines of the table). For example, ‘DATA MyTable like MyRecord OCURS 1000 [WITH HEADER LINE]‘. The Number following the occurs is only an estimate (used for performance) and not a limitation. ‘With header line’ is optional, serving only to populate a data object with the same structure/content as a line in a table created (a work area for the current/last record. You get the table itself with an additional data object of the same structure a an individual line.). When you declare WITH HEADER LINE you don’t need to declare and extra record for a work area. Internal tables/cursors can be loaded from database tables. An internal program record structures as a Dictionary table is defined by the TABLES declaration, while using the LIKE to refer to all or only some fields. It is also possible to define data types and constants in type pools of the dictionary which can be used in programs with TYPE-POOLs declarations. Many table operations require an extra record to use to hold the new record’s information as you add it. Using the additional ‘WITH HEADER LINE’ in the defining data statement, when the table is created, an additional data object with the same type as an individual line in a table is created called a ‘HEADER LINE’ which can be used as a default record to hold the record currently being added to a table. If a table does not have a header line you must provide a separate record to hold the content of the current line. Example: DATA all_customers like customer occurs 100. The line type of an internal table can also be specified using a reference to an elementary or non-elementary type (You can have multiple lines defined). Fields and types can refer to elementary types (c for character for example). Some rules to remember:
•    Records (or structures) are defined using begin of/end of.
•    Internal tables are defined using occurs.
•    Always start with elementary types and fields.
Embedded/Nested internal tables cannot have header lines. ABAP Keywords dealing with internal tables (append, loop,…) implicitly distinguish between the header line and the body of a table, but some (like move) do not. In the case of th e move you must specify the body (not header) explicitly using brackets. There are 4 ways to fill an internal table:
•    You can read data from database tables via SELECT command.
•    You can append lines using the APPEND command.
•    You can insert lines at a specified position using the INSERT command.
You can transport complete tables with the MOVE command.