Before looking into application server and its architechture
we just check where an ABAP program lies in the whole process.
Let's see the simple figure to under stand the linkage of sata
base,presentation and application servers : ABAP applications are written in the ABAP programming language, and run within the application layer of the SAP Web Application Server.
These components are responsible for the presentation of data for users and the receiving of user entries. When web browsers are used as user interfaces, HTML pages prepared in the presentation layer are accessed by application programs through the classes and interfaces of the Internet Connection Framework (ICF), which wrap the HTML pages. The presentation in a web browser is based on Web Dynpro ABAP (MVC-based technology for creating platform-independent web-based interfaces) and also still Business Server Pages (BSP, HTML pages that incorporate server-side scripts written directly in ABAP). When you use the SAP GUI that is available in versions for MS Windows, Java and Web Browser, user interfaces are displayed in windows that are based on the (classical) dynpro technology. The layout of a dynpro can contain a set of predefined screen elements or GUI controls (wrapped by the classes of a Control Framework, CFW).
Here, application programs are executed. The application layer contains a kernel written primarily in C/C++ that serves as a platform for the application programs. The kernel of AS ABAP provides Virtual Machines for ABAP with ABAP Objects (main programming interface of AS ABAP for business applications), XSLT and ST (transformation languages for transforming ABAP data to XML and vice versa), and still JavaScript (obsolete, server-side scripting in BSPs beside ABAP).
Here, persistent data is held in a database. The database is accessed by ABAP programs through the database interface of AS ABAP that is subdivided into an Open SQL interface and a native SQL interface. Open SQL is a subset of the Structured Query Language (SQL) realized directly by ABAP statements. Native SQL are database-specific SQL instructions that are passed directly to the database system (either statically or dynamically via ADBC).
In addition to several work processes whose number and type are determined at the startup of NetWeaver AS ABAP, each ABAP application server contains a dispatcher, a gateway and the shared memory. The tasks of these components are briefly described in the following:
ABAP programs communicate with the database
management system of the central relational database (RDBMS) and with the
presentation layer. A SAP-specific graphical user interface (SAP GUI) for users
logged on to a SAP System and Web browsers for Web-based applications are
available to you as presentation layers.
Now, lets go through the main topic application
server,ABAP.
The Application Server ABAP (AS ABAP) allows you
to program applications in ABAP. It provides the ABAP runtime environment (a
virtual machine for ABAP programs), the ABAP Workbench, and an integrated
change and transport system (CTS).
AS ABAP can be used either by people using user
interfaces (Web Browsers or SAP GUI) or by other software components through
the network. For sap gui two main protocols are used: HTTP/HTTPS/SMTP for
Internet connections (controlled by the so-called Internet Communication
Manager, ICM) and SAP's own Remote Function Call (RFC) protocol (via the RFC
interface).
Most of the components of AS ABAP can be divided
into three layers:
Presentation Layer :
Application Layer :
Persistence Layer :
we shall look into the structure of the ABAP-AS.
Ø Structure of an ABAP Application
Server
All ABAP application servers including the
message server represent the application layer of the multi-tier architecture
of an ABAP-based SAP System. These application servers execute ABAP
applications and communicate with the presentation components, the database,
and also with each other, using the message server.
The following diagram shows the structure of an
ABAP application server:
·
Work Processes
Work processes are components that are able to
execute an application (that is, one dialog step each). Each work process is
linked to a memory area containing the context of the application being run.
The context contains the current data for the application program. This needs
to be available in each dialog step.
To link the work process and the users logged on
the application server dispatcher is used.
·
Dispatcher
The dispatcher is the link between the work
processes and the users logged onto the ABAP application server (that is, the
SAP GUIs of these users). Its task is to receive requests for dialog steps from
the SAP GUI and direct them to a free work process. In the same way, it directs
screen output resulting from the dialog step back to the appropriate user.
·
Gateway
This is the interface for the communication
protocols of NetWeaver AS ABAP (RFC, CPI/C). It can communicate with other ABAP
application servers of the same NW AS, with other SAP Systems, or with external
non-SAP systems.
·
Shared Memory
All of the work processes on an ABAP application
server use a common main memory area called shared memory to save contexts or
to buffer constant data locally.
The resources that all work processes use (such
as programs and table contents) are contained in shared memory. Memory
management in the NetWeaver AS ABAP ensures that the work processes always
address the correct context, that is the data relevant to the current state of
the program that is running. A mapping process projects the required context
for a dialog step from shared memory into the address of the relevant work
process. This reduces the actual copying to a minimum.
Ø Advantages of this Type of
Architecture
The structure of the ABAP application servers
described here supports the performance and scalability of NetWeaver AS ABAP.
The fixed number of work processes and dispatching of dialog steps leads to
optimal memory use, since it means that certain components and the memory areas
of a work process are application-independent and reusable. The fact that the
individual work processes work independently makes them suitable for a
multi-processor architecture.
Local buffering of data in the shared memory of
the ABAP application server reduces the number of database reads required. This
reduces access times for ABAP application programs considerably. For optimal
use of the buffer, you can concentrate individual applications (financial
accounting, logistics, human resources) into separate ABAP application server
groups.
Database Connection
When you start up a NetWeaver AS ABAP, each ABAP
application server registers its work processes with the database layer, and
receives a single dedicated channel for each. While the NW AS is running, each
work process is a user (client) of the database system (server). You cannot
change the work process registration while the system is running. Neither can
you reassign a database channel from one work process to another. For this
reason, a work process can only make database changes within a single database
logical unit of work (LUW), that is an inseparable sequence of database
operations.
No comments:
Post a Comment