Advanced Business Application Programming.
Programming language developed by SAP to create application programs.
All function modules and BAPIs are written in ABAP.

Central redundancy-free storage facility for all data used in the R/3 system.
The ABAP Dictionary describes the logical structure of application development objects and their representation in the structures of the underlying relational database.
All runtime environment components, such as application programs or the database interface, get information about these objects from the ABAP Dictionary.
The ABAP Dictionary is an active data dictionary and is fully integrated into the ABAP Workbench.

Intergrated graphical environment for developing application programs written in ABAP.

Active Server Pages (ALL)

ASP is a technology introduced by Microsoft where HTML pages contain scripts that are executable on the server. Since the scripts are executed directly on the server, the HTML client (browser) only sees the result which usually is a HTML file.
ASP are supported by Internet Information Servers (IIS), version 3.0 and higher.
For the scripts, you can use any language for which an ActiveX scripting engine is installed on this server.

Object type of the ABAP Dictionary.
When activating a lock object the system automatically generates function modules for activating and releasing locks. You can then use these function modules in your ABAP programs.
For example, you can use the authorization object S_RFC to determine for particular users which function groups they are allowed to use.

A BAPI (Business Application Programming Interface) is a well-defined interface to the processes and data of a business application system (R/3), implemented as a method of a business object type in the BOR.

BAPI-oriented view of the Business Object Repository (BOR).
The BAPI Explorer displays all business objects for which BAPIs are implemented. You can call it in the R/3 system using transaction code BAPI. In earlier releases, it was called BAPI Browser.

The Business Object Repository (BOR) contains business object types and the corresponding meta information. Meta information is, for example, the basic data required for administering business objects in the BOR or information on type conversion between R/3 and the OLE client.

A business object represents a concept from the real world. In particular, it describes an object that implements a business logic.

This browser displays all SAP business objects from the BOR. For each object, you can view all assigned methods (BAPIs and other). In contrast to the BAPI Explorer, you can navigate to the source coding of the underlying function modules. To call the browser, use transaction code SWO2.

An open architecture for cross-platform development of client/server applications based on object-oriented technology. Clients have access to an object through interfaces implemented on the object. COM is language-neutral, so any language that produces ActiveX components can also produce COM applications.

Proxy classes for the actual business object types in the R/3 System. Their runtime instances (proxy objects) then use the business logic implemented in R/3. In particular, each proxy object has the same interfaces as the object with which the client wants to communicate.

Name used to identify the target system in an RFC call.
You need a destination to be able to establish a connection to another R/3 system in the first place. A destination contains parameters that specify the technical system settings, security options, and logon data of the access-enabled users; it is created in the calling system.
Each destination defines its own context ("roll area"), so that in repeated calls of one or even different function modules via the same destination you can use the global memory (the global data) of these function modules.

Group of logically related function modules which, at runtime, share a program context.
For each function group the system generates a main program for the function modules contained in it. In addition, the function group contains global data and subroutines that can be shared by all function modules of this group.

Function for general use.
Function modules are external subroutines written in ABAP. You create them using the Function Builder tool. The system stores them in a central function library. Function modules are available in R/3 (R/2) across all applications and throughout the system. This allows you to avoid redundant coding and to write programs more effectively.

Global Unique Identifiers are 128-bit numbers used to identify components uniquely (interfaces, ActiveX controls,…). As a synonym, UUID (Universal Unique Identifier) is used.
GUIDs are not assigned globally, but created locally on the machine. When the system generates GUIDs, it includes date and time as well as the machine address.

Microsoft IDL Compiler is used to generate proxy classes and type libraries from IDL files.

Packing the parameters of method calls into a transferable package and sending it to a component across threads or processes.

The internal state of an object results from changes of the values of all its attributes. MTS objects that do not accumulate an internal state from successive method calls are called stateless objects. Successive method calls are independent of one another.
In contrast, an object is statefull if it can accumulate an internal state which results from one or more method calls. For example, a remote function module may be able to change global variables and thus accumulate an internal state in R/3 that has an effect on subsequent calls.

Central storage facility for all development objects of the ABAP Workbench (SAP's integrated graphical development environment).
These development objects include ABAP programs, screens, function groups, documentation, and so on.

A service that provides the synchronization and management of nondurable resources within a process, providing for simple and efficient sharing by Microsoft Transaction Server objects.

For example, the Resource Dispenser of the DCOM Connector is used to keep the RFC connections to the R/3 system in a pool and to reactivate them repeatedly and assign them to MTS business objects. This allows for R/3 accesses with a high performance.

Resource pooling is a process that keeps a resource alive even after the application has released all references to it and it is no longer needed at the moment. The resource is kept in a pool and can be reused if the need arises, provided that is has not yet exceeded it maximum life span.

Remote Function Call.
SAP's interface protocoll based on CPI-C.
RFC allows you to call remote function modules between different SAP systems (R/3 and R/2) and between these SAP systems and external systems.

Function modules of the R/3 function library that can be called remotely.
In contrast to function modules you call locally, these function modules are flagged as "can be called remotely" when they are created in the Function Builder.
You call remote functions in ABAP using the statement CALL FUNCTION with the addition DESTINATION. The addition determines where to execute the remote function module.

Graphical User Interface.
Software components of the presentation layer of an R/3 system that form an interface to the users. The presentation layer is responsible for sending data to and receiving data from the R/3 application servers. By default, you log on to the R/3 system via SAPGUI.

Exceptions automatically triggered by the R/3 system when you call a remote function module. They include:

• SYSTEM_FAILURE
  triggered if no connection to the target system (RFC server) could be established; for example, if the system closed down on the receiving side.
• COMMUNICATION_FAILURE
  triggered if a communication problem arose after the connection to the target system was established; for example, if the called function module could not be found in the system.

A transaction is a Logical Unit of Work (LUW). Such a unit defines an inseparable sequence of database operation that transforms the database (DB) from one consistent state into another. This implies that when calling a transaction, the DB operations must be executed either completely or not at all ("all or nothing" principle).

R/3 systems can establish trust relationships between one another.
If a calling R/3 system (RFC client) is known by the called system (RFC server) as Trusted System, no logon is required in the called system. For this relation, the called system must be registered in the calling system as trusted system. The called system is then referred to as Trusting System.
The trust relationship is not mutual, but exists only in one direction.

The type library is a file that contains type information (descriptions of data types, methods, interfaces) of one or more objects. The type library provides the clients that use these objects with this information.
To create a type library, transfer the descriptions given in the IDL file to the MIDL Compiler. A type library can also be an ordinary file (file.TLB) or be delivered as resource in an executable file (DLL or EXE).

User-specific work area in the main storage provided for the duration of a program and administered dynamically by the system.
The user context (also called "roll area") contains the current data of a running program and must be available to each dialog step of this program.
If an RFC function module or a BAPI is called remotely, the user context contains the authorizations of the accessing R/3 user as well as any temporary results of the call. The remote user context is kept until the caller closes the RFC connection.

Work processes as components of an application server in the R/3 system are responsible for executing the dialog steps of application programs. Each work process is connected to a storage area in which the context ("roll area") of the currently executed application is stored. A work process contains two software processors - the screen processor and the ABAP processor - and a database interface. The screen processor is responsible for executing the screen flow logic (evaluation of user interactions). The ABAP processor executes the processing logic of the application program and communicates with the database interface.