In the hardware-oriented view, the server or the central server in a network provides data, memory, and resources for the workstations (clients).
In the software-oriented view, you define both the client and the server at the process level, or as a service provided by a software component. This software component (for example, an SAP Web Application Server) can comprise one or more processes. It is then called a server for that service. Software components that use a service are called clients.
SIMPLE CLIENT/SERVER CONFIGURATION
The processes often used for operating business application software are
presentation processes (for displaying screens); application processes (for executing application programs); and database processes (for managing and organizing database data).
To configure an SAP system, you will have to distribute the required processes among the available hardware. You can have single-tier or multitier configurations, depending on the number of hardware layers.
In single-tier configurations, one single computer performs all the processes (database, application, and presentation). This is known as classic mainframe processing. It is generally used for tests and demonstrations.
Sometimes you need special presentation servers that are responsible solely for formatting the graphical interface. In this case, a two-tier configuration is implemented. This can cover a significantly higher number of users with its distributed presentation processes.
In a three-tier configuration, each layer runs on its own host. You can use many application servers to simultaneously work with the data of a database server.
For more complex client or server configurations comprising more than three tiers, you may have to implement a multitier configuration. You can add an additional level, which could be a Web server.
INSTANCE OF AN SAP SYSTEM
An instance combines SAP system components providing one or more services. These services can be started or stopped simultaneously. You can install and operate the database for an SAP system on a physical computer, separately from the instances of the SAP system.
The central instance of the SAP system offers services that no other instance of the system offers. Examples of central instance services are the Message Server and the Enqueue work process for AS ABAP and the Software Deployment Manager (SDM) for AS Java.
The central services instance provides the central services of the AS Java, the Message Service, and the Enqueue Service.
Dialog instances constitute the other instances of the system.
If the same computer constitutes both the central instance and the database, it becomes acentral system.
AS ABAP PROCESSES
On every application server, a number of parallel work processes are possible in the runtime environment for ABAP.
Requests to run the work processes are distributed by thedispatcher.
Requests for the execution of dialog steps are handled by dialogwork processes. Each dispatcher must handle at least two dialog work processes.
Spool work processes pass on the sequential data flows to printers.
Each SAP system should have at least one spool work process.
Requests to execute updates are handled by update work processes. At least one update work process is required for each SAP system.
Background work processes execute programs that run without interacting with the user. Every SAP system needs at least two background work processes.
The enqueue work process administers the lock table in the shared memory.
Only one enqueue work process is needed for each system.
Apart from these work processes, the AS ABAP provides additional services (these are not work processes) for internal and external communication:
The Message Server (MS) handles communication between the distributed dispatchers. The message server is configured only once per SAP system.
Communication between multiple SAP systems, or between SAP systems and external application systems, is possible through the Gateway reader (GW). You only need one Gateway reader for every dispatcher.
The Internet Communication Manager (ICM) is used for communicating with the SAP system using web protocols such as HTTP. It receives requests from the client and forwards them to the SAP system for processing. You can configure a maximum of one ICM process per application server.
AS JAVA PROCESSES
Various processes exist in AS Java:
The server processes receive incoming requests through the dispatcher.
Every dispatcher handles 1 to 16 server processes.
The server process executes the Java applications.
A list of Java dispatchers and server processes is managed by the JavaMessage Service (MS), which communicates within the Java runtime environment.
Logical locks set (by the executed Java application program) in a server process fall under the purview of the Java Enqueue Service.
You can install Java software components on the SAP Web AS Java using the Software Deployment Manager (SDM).
POSSIBLE TYPES OF SAP NETWEAVER AS
The SAP NetWeaver AS can be of different types.
The AS ABAP system has the complete infrastructure for developing and using ABAP-based applications.
The AS Java system provides the complete infrastructure for developing and using J2EE-based applications.
The AS ABAP+Java system comprises the infrastructure in which you can develop and use ABAP-based and J2EE-based applications.
AS ABAP ARCHITECTURE
The Message Server provides information on which instances of the system are currently available. The ABAP dispatchers of the individual application servers communicate through the ABAP message server – one per SAP system. You can log on to the AS ABAP either through the SAP GUI for Windows or the SAP GUI for Java using logon groups. The message server then performs a load distribution of users to the available instances. After the load distribution, the SAP GUI communicates directly with the dispatcher. You remain logged on to this instance until you log off again.
If you use Web protocols such as HTTP for accessing the AS ABAP, the ICM receives the request. The ICM forwards the request to the dispatcher of its instance. The Gateway Reader (GW) accepts communications from other SAP systems through Remote Function Call or RFC.
AS JAVA ARCHITECTURE
In AS Java, the central services like Message Service (MS) and Enqueue Service (ES) run in the Central Services Instance. All other instances of the system are usually called dialog instances. The Java MS provides a central message service for internal communication. The Java ES holds the logical locks. When the AS Java is accessed using a browser, the Java dispatcher receives the requests. The server processes then process these requests.
AS ABAP+JAVA ARCHITECTURE
In AS ABAP+Java, the central instance can be recognized by processes like ABAP MS, enqueue work process, and SDM. The Java central services instance provides the central services of the Java runtime environment (Java MS and Java ES). Dialog instances refer to all other instances.
The Internet Communication Manager decides whether the request should be forwarded to the ABAP or the Java runtime environment. Depending on the URL the ICM forwards the request to the respective dispatchers. The work processes respond to the requests accordingly. The ABAP and Java runtime environments communicate with each other using SAP Java Connector (JCo).
PROCESSING A USER REQUEST
The processing of a user request in AS ABAP involves the presentation layer, the application layer, and the database layer. The screen entries of a user are accepted by the SAP GUI and are forwarded to AS ABAP. The ABAP dispatcher distributes the requests one by one to the available work processes for processing of data. You must read data from the ABAP schema of the database or write to it, to process user requests. The ABAP schema of the database has direct links with every work process. Once the process is complete, the dispatcher sends back the end result of the work process to the SAP GUI.
The buffers help to speed up the processing of user requests by reducing the number of database hits for data processing. Each instance has its own buffers.
PROCESS FLOW FOR REQUEST
Application programs include process logic, which is executed by work processes.
A work process includes
internal memory; a task handler that coordinates the actions within a work process; software processors; and a database interface.
The database interface translates the OPEN SQL statements from ABAP into the corresponding SQL statements for the specific database used (Native SQL). TheABAP interpreter executes the actual processing logic of ABAP application programs. The screen processor tells the ABAP processor which subprogram to execute, depending on the processing status of the screen flow logic.
The dialog work process is selected by the dispatcher. It involves a roll-in of the user context first. The work process then processes the user request. This may be a request for data from the database or from the buffers in the shared memory. The dialog work process processes the dialog step, after which the work process rolls out the user context back to the shared memory. The user sees the result after it has been transferred to the SAP GUI on the new screen.
DATABASE QUERY FLOW
In ABAP, you can access the application data in the database using ABAP Open SQL (or Structured Query Language, which is a database query language), regardless of the Relational Database Management System (RDBMS) used. The database interface that interprets the OPEN SQL into Native SQL thus allows the programs to be database-independent. The buffer stores data that are frequently needed. Thus the system is spared the trouble of retrieving this data from the database. Furthermore, native SQL commands used directly in ABAP can fetch data. This eliminates the need for local buffers or interpretation of commands by a database interface.
PROCESSING DIALOG REQUEST
A program with individual dialog steps may consist of several screens.
Each dialog step in a program is assigned to one specific dialog work process.
A dialog work process sequentially processes the dialog steps for various users and programs. Work process multiplexing uses different dialog work processes during program runtime.
DIALOG WORK PROCESS MULTIPLEXING
Process Before Output or PBO refers to the processing before the screen image is sent. Process After Input or PAI refers to the processing after a user interaction on the screen. ThePAI part of a dialog step logically belongs to the preceding screen image; whereas the PBOpart logically belongs to the subsequent screen image.
PRINCIPAL CHARACTERISTIC: TRANSACTION
Transactions are processing units grouped to provide specific modules.
The four principal characteristics of transactions can be summed up in the acronym ACID:
Atomic Consistent Isolated Durable
An atomic transaction either succeeds fully or does not have any effects at all. This ensures that inconsistent, partial results are not stored.
A consistent transaction is one in which the system status always reflects one that is accurate and consistent in business terms and will not change otherwise.
Changes made within a transaction are isolated, as they cannot be seen by any other transaction, unless the confirmation Commit is executed.
The results of a transaction are durable because after the final confirmation they are stored permanently in the database.
RELATIONSHIP BETWEEN DATABASE TRANSACTION AND SAP TRANSACTIONS
SAP transactions need not be executed within one single dialog work process. For requests that change data on the database, database transactions are initiated. Applications whose dialog steps are sequentially executed by the same work process cannot run within the same database transaction if they are not related to each other. Therefore, a work process must start a new database transaction foreach dialog step.
LOCK MANAGEMENT IN AS ABAP
The SAP lock principle is that SAP programs should make lock entries in a lock table. The lock table is located in the main memory of the instance with the enqueue work process. If a user wants to change the access to data, the executing dialog work process requests a lock. A dialog request processed on the enqueue server results in a dialog work process that can access the lock table directly; else, the work processes communicate through the MS.
The application developer can choose between different lock modes, such as at most read access and change access.
The application developer can choose between various lock modes.
Write locks – in the lock mode Exclusive – can be edited only by one user. Read locks – in the lock mode Shared – allows concurrent read access to the locked data for several users. Enhanced write locks – in the lock mode eXclusive noncumulative – allow write locks to be successively requested and released by the same transaction. Optimistic locks – in the lock mode Optimistic – respond like read locks at first; can be changed to write locks; and can be set if the user displays the data in change mode.
THE PRINCIPLE OF ASYCHRONOUS UPDATES
SAP transactions can off-load time-intensive database changes by using the updating system. During a dialog work process, the data temporarily stored for processing may be passed to an update work process for further processing. The dialog work process, in that case, does not wait for the update request to be completed. This type of update is asynchronous.
With the ABAP command COMMIT WORK, you complete the dialog part. Each dialog step corresponds to a database transaction, which is executed either completely or not at all in the database. It is duly completed with a COMMIT command.
THE ASYNCHRONOUS UPDATE PROCESS
An asynchronous update process triggers several steps:
The program first locks the data record for other users by addressing the enqueue work process.
If the lock entry to the lock table is successful, the program passes the lock key to the user. The program then reads the record to be changed from the database
In the active dialog work process, the program calls a function module using CALL FUNCTION ... IN UPDATE TASK. It then writes the change request to database update tables. These are called VB* tables; they act as temporary memory; and store the data to be changed. Later on this data can be collected and written to the application tables in the database.
After the dialog part of the transaction ends, the program initiates the close of the transaction with the COMMIT WORK statement.
The update work process reads the log records that belong to this SAP transaction from the VB* tables. This is based on the information (key of the update order, lock key) transferred from the dialog work process.
The changes are marked and collected in the VB* tables.
The lock entries in the lock table must be reset.
PRINTING IN AS ABAP
A spool request contains information on the output data requested; the formatting of this data; and the printer model used. The spool request is stored in the TemSe (temporary sequential file). A spool work process formats the data specified in the spool request and creates an output request. The data in the output request is in an appropriate format for the printer. You can pass on this data to an appropriate operating system spool process locally (on the same computer) or remotely (over a network connection). The operating system then performs all remaining tasks, such as queuing and data transfer to the selected printer.
SCHEDULING BACKGROUND TASKS (JOBS)
As an end user, you can schedule the program to be started in the background as a job from the application transaction. The job then “waits” for the planned execution time in the job scheduling table. This scheduling is facilitated by the background scheduler and the job is executed.
GATEWAY COMMUNICATION
Each instance of an AS ABAP system contains a gateway.
A gateway enables communication between the instances of a system or between various systems using RFC.
The gateway reader is the main process of the gateway system. The dispatcher starts the gateway reader and checks it periodically. The gateway forwards the request to the gateway of the remote system. The remote gateway transfers the request to the dispatcher. This in turn forwards the request to one of its work processes, which then communicates directly with its gateway.
PROCESSING A WEB REQUEST
The Internet Communication Manager (ICM) receives Web requests. The ICM then uses the URL to decide where it should forward the request.
Any request to the Java runtime environment goes to the Java dispatcher (2b), which then forwards it to a Java server process (3b). The Java server process then refers to the Java schema of the database (if applicable) and sends the response back to the ICM using the Java dispatcher process. The ICM reroutes this response from the SAP system to the user who sent the request (5).
Any request to the ABAP runtime environment is forwarded by the ICM to the ABAP dispatcher (2a), which then handles it like a typical SAP GUI request and forwards it to the work process (3a).The relevant work process now communicates directly with the ICM (4a). The ICM forwards this response to the user who sent the request (5).
No comments:
Post a Comment