ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
SAP has three different layers as presentation layer (GUI), application layer (programs run on this) and data base layer where all data is stored and retrieved from user driven conditions, commands given by end user programmer through presentation layer.
SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, i5/OS on IBM System i (formerly iSeries, AS/400) and z/OS on IBM System z (formerly zSeries, S/390). Supported databases are DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).
The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
Let’s have a look at the different kind of transactions:
In ABAP, there are two different types of programs:
Report programs follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.
The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
Functions are invoked in ABAP programs by means of the CALL FUNCTION statement. A very important feature of ABAP is the ability to call function modules in another SAP system or in an external application using the RFC (Remote Function Call) mechanism. It is also possible to call functions asynchronously; the ABAP program then does not wait for the function to return but instead continues immediately, while the function executes in a separate context.
With these objects in its repository, the ABAP Dictionary:
Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.
The following are examples of data lacking integrity:
Managing data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.
The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.
Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.
When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
This brief description of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.
PROGRAM TEST. WRITE 'Hello World'.This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "Hello World".
You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
The two-line "Hello World" program from above could also be written as
PROGRAM TEST. WRITE 'Hello World' .or even as:
Free formatting is convenient, but with complex code, such as deeply nested IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a "Pretty Printer" function, which can take care of proper indentation.PROGRAMTEST.WRITE'Hello World'.
One obvious exception to the free-formatting rule are text literals. A text literal is a sequence of alphanumeric characters in the program code enclosed in single quotes. If a text literal in an ABAP statement extends across more than one line, then a ‘&’ character must be used to combine a succession of text literals into a single one. Example:
USERPROMPT = 'Please double-click on a line in the output list ' &'to see the complete details of the transaction.'.
proGRAm TEsT. WriTe 'Hello World'.Users can configure the way source text is presented (all upper case, all lower case, ABAP keywords in upper case and variable names in lower case, etc.) according to their own preference.
The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
To concatenate a sequence of separate statements, write the identical part only once and place a colon (:) after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
Chaining is very often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:
WRITE FLIGHTINFO-CITYFROM. WRITE FLIGHTINFO-CITYTO. WRITE FLIGHTINFO-AIRPTO.Chaining the statements results in a more readable and more intuitive form:
WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.
In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
You could, for example, write the same statement like this:
WRITE: FLIGHTINFO-CITYFROM,In a chain statement, the first part (before the colon) is not limited to the keyword of the statements. For example, the codeFLIGHTINFO-CITYTO,FLIGHTINFO-AIRPTO.
SUM = SUM + 1. SUM = SUM + 2. SUM = SUM + 3. SUM = SUM + 4.could be written in chained form:
SUM = SUM + : 1, 2, 3, 4.
SELECT * FROM FLIGHTINFO
WHERE CLASS = 'Y' "Y = economy
OR CLASS = 'C'. "C = business(...)
ABAP accepts all data types defined in the SAP dictionary or in Type Pools. Types can also be defined inside the program itself. Object numeric (I for integer, F for floating point), packed decimal (P), character (C or N, where the N type is used for numeric strings that can be used in computation) or hexadecimal (X). Date fields (type D) and time fields (type T) have a "dual" nature; in an input/output context they behave like strings, but in a computational context they are numeric integers. This makes date and time calculations extremely easy. For example:
DATESENT = '20070901'. VALIDTO = DATESENT + 60. WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.In this example, a string literal representing September 1, 2007 is assigned to DATESENT. DATESENT is then used in a numeric calculation to produce another data field, VALIDTO. VALIDTO is then output as a string. The optional "DD/MM/YYYY" modifier displays the date in a predefined format, here "31/10/2007". Without the modifier the date would display as "20071031".
All ABAP variables must be explicitly declared in order to be used. The convention is for all declarations to be at the top of the program, or subroutine. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:
DATA: COUNTER TYPE I,
VALIDITY TYPE I VALUE 60,
TAXRATE(3) TYPE P DECIMALS 1,
LASTNAME(20) TYPE C.
DATA: ORIGIN TYPE COUNTRY.
DATA: T_FLIGHTS TYPE TABLE OF FLIGHTINFO,
T_LOOKUP TYPE HASHED TABLE OF FLT_LOOKUP.
DATA: BOOKING TYPE REF TO CL_FLT_BOOKING. Notice the use of the colon to chain together consecutive DATA statements.
ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs. Note, however, that syntax checking is stronger in ABAP Objects programs, and some syntactical forms (usually older ones) of certain statements are not permitted.
Examples of declarative keywords:
TYPES, DATA, TABLES
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE. '''
Examples of control keywords:
IF, WHILE, CASE
Examples of call keywords:
CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
Examples of operational keywords:
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, the programmer is saved the task of dynamic memory management in his or her programs. Internal tables should be used whenever there is a need to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects. A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP Objects are not related, they do not have the same line type. The line type is stored in the value of the reference pointer and can be viewed in the debugger. If one object attempts to access another unrelated object's components, you will receive an error specifying that the line types do not match.
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key is UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries with the same key. The uniqueness depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. An internal table which has a line type that is itself an internal table, has an empty key.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Later versions of ABAP permit the definition of secondary keys.
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. (Think of index as "record number". It is not to be confused with a database index, for example). From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
There are three batch input methods:
(1) In the Direct Input Method, the programs are provided by the SAP system. These programs are available for Standard Applications. Under this method, the data base is updated using a Function Module, which is responsible for executing the appropriate consistency checks.
(2) In the Call Transaction Method, the ABAP Program reads the external data which is present on the Application or Presentation Server, and uses the ABAP Statement CALL TRANSACTION USING to run a SAP statement.
(3) In the Session Method the program reads the data and the SAP system stores the data in a "Batch Input Session". The session records the actions that are required to transfer data into the system using normal SAP transactions.
ABAP Objects offers a number of advantages, even for procedural programming. Many advanced features of ABAP use object-oriented interfaces.
Sharing Data: With ABAP shared objects, you can aggregate data in memory once at a central location. Different users and programs can then access this data without the need for copying.
Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
*----------------------------------------------------------------------- * set an exclusive lock at level object-type & object-id *----------------------------------------------------------------------- IF NOT lf_bapi_error = true. IF ( NOT istourhd-doc_type IS INITIAL ) AND ( NOT istourhd-doc_id IS INITIAL ) CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF' EXPORTING obj_typ = istourhd-doc_type obj_id = istourhd-doc_id EXCEPTIONS foreign_lock = 1 system_failure = 2 OTHERS = 3. IF sy-subrc <> 0. * terminate processing... lf_bapi_error = true.— * ...and add message to return table PERFORM set_msg_to_bapiret2 USING sy-msgid gc_abort sy-msgno sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 gc_istourhd gc_enqueue_refdoc space CHANGING lt_return. ENDIF. ENDIF. ENDIF. " bapi error
REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB . ************************************************************************ *Simple example to use ALV and to define the ALV data in an internal *table ************************************************************************ *data definition tables: marav. "Table MARA and table MAKT *---------------------------------------------------------------------* * Data to be displayed in ALV * Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto- * matically determine the fieldstructure from this source program Data: begin of imat occurs 100, matnr like marav-matnr, "Material number maktx like marav-maktx, "Material short text matkl like marav-matkl, "Material group (so you can test to make " intermediate sums) ntgew like marav-ntgew, "Net weight, numeric field (so you can test to "make sums) gewei like marav-gewei, "weight unit (just to be complete) end of imat. *---------------------------------------------------------------------* * Other data needed * field to store report name data i_repid like sy-repid. * field to check table length data i_lines like sy-tabix. *---------------------------------------------------------------------* * Data for ALV display TYPE-POOLS: SLIS. data int_fcat type SLIS_T_FIELDCAT_ALV. *---------------------------------------------------------------------* select-options: s_matnr for marav-matnr matchcode object MAT1. *---------------------------------------------------------------------* start-of-selection. * read data into table imat select * from marav into corresponding fields of table imat where matnr in s_matnr. * Check if material was found clear i_lines. describe table imat lines i_lines. if i_lines lt 1. * Using hardcoded write here for easy upload write: / 'No materials found.'. exit. endif. end-of-selection. * To use ALV, we need either a reference to a structure defined in * the SAP Data Dictionary (DDIC) or an in-program structure called * the Field Catalog. * The Field Catalog can be declared explicitly or generated by FUNCTION * 'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any * report source, including this report. *---------------------------------------------------------------------* * Store report name i_repid = sy-repid. * Create Fieldcatalogue from internal table CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE' EXPORTING I_PROGRAM_NAME = i_repid I_INTERNAL_TABNAME = 'IMAT' "capital letters! I_INCLNAME = i_repid CHANGING CT_FIELDCAT = int_fcat EXCEPTIONS INCONSISTENT_INTERFACE = 1 PROGRAM_ERROR = 2 OTHERS = 3. *explanations: * I_PROGRAM_NAME is the program which calls this function * * I_INTERNAL_TABNAME is the name of the internal table which you want * to display in ALV * * I_INCLNAME is the ABAP-source where the internal table is defined * (DATA....) * CT_FIELDCAT contains the Fieldcatalouge that we need later for * ALV display IF SY-SUBRC <> 0. write: / 'Returncode', sy-subrc, 'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'. ENDIF. *This was the field catalog *---------------------------------------------------------------------* * * Call for ALV list display CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY' EXPORTING I_CALLBACK_PROGRAM = i_repid IT_FIELDCAT = int_fcat TABLES T_OUTTAB = imat EXCEPTIONS PROGRAM_ERROR = 1 OTHERS = 2. *explanations: * I_CALLBACK_PROGRAM is the program which calls this function * * IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains * now the data definition needed for display * * I_SAVE allows the user to save his own layouts * * T_OUTTAB contains the data to be displayed in ALV IF SY-SUBRC <> 0. write: / 'Returncode', sy-subrc, 'from FUNCTION REUSE_ALV_LIST_DISPLAY'. ENDIF.