Every work process is specialized in a particular task type: dialog, background, update, enqueue, spool, message, or gateway. The last two types are somewhat different than the rest. In client/server terms, a work process is a service, and the computing system that is running the particular services is known as a server. For example, if the system is just providing dialog services, this is a dialog server, although commonly called an application server.
The dispatcher assigns tasks to the free work processes, making optimal use of system resources and balancing the system load. The dispatcher knows and distributes accordingly the pending tasks according to the processing type of the defined processes. The work process definitions are instance specific. The difference among the various work processes only affects their mission or special services as assigned to the work processes through the dispatching strategy. Figure shows the work processes from within R/3. To get to this screen, select Tools | Administration | Monitor | System Monitoring | _Process Overview, or type /NSM50 in the command field.
Displaying work process within Web AS (Copyright by SAP AG)
Dialog Work Processes
The dialog work processes are in charge of the interactive tasks of the R/3 system. A dialog work process performs the dialog steps corresponding to the interactive user sessions. The jobs held by the dispatcher in the request queues after user input are assigned to the next free work process. The dialog work processes execute just one single dialog step at a time and become immediately free for the next user request (dialog step), which is assigned by the dispatcher. This is called work process multiplexing. This means that the dialog work processes can be constantly switching between different user sessions. This type of processing allows a great deal of resource distribution; otherwise the system would need as many dialog work processes as the number of expected interactive users. It works exactly the same as multiuser operating systems. The SAP profile parameter that controls the number of interactive dialog work processes per instance is rdisp/wp_no_dia. Chapter explains with greater detail the profile parameters.
Depending on the type of business transactions the users are working on, a dialog work process can support from 5 to more than 10 simultaneous users each. This means that 10 dialog work processes could theoretically support approximately 100 users. However, this is just a rule of thumb. Tuning this parameter means that if users have to wait long to get a free work process, you should increase the parameter. This, however, has some limitations, such as the total number of processes running on the server and the availability of main memory. When there are a large number of concurrent interactive users expected in a SAP Web AS system, there will certainly be a number of application servers. Some of these application servers can become special dialog servers, containing a dispatcher process and a number of dialog work processes.
Dialog Step Data Flow
Figure shows the flow of a user request through the different components and processes. Initially, the user enters data into the screen fields and presses the Enter key. These data are received by the SAP GUI process and are converted to an internal format and sent to the Message server, which directs the connection to an available instance of the application server dispatcher (1).
Data flow in dialog steps
The dispatcher checks whether there are available work processes for processing the dialog step. If there are not, the request goes to the request queues (2) until one becomes available. Once a dialog work process is available, the dispatcher sends the user data to the work process (3). Within the dialog work, the task handler is in charge of assigning the corresponding tasks to the internal components (dynpro or ABAP), using the SAP memory buffers, using the roll and page area for user context storage and switching, and finally sending a SQL request to the database (4). The database system sends the requested data back to the work process (5), which in turn passes it to the presentation server (6).
The SAP GUI formats the data and fills up the screen for the user (7). The time it takes to get from step 1 (user request) to step 7 is known as response time. The response time is one of the main indicators of how healthy (well-tuned) the system is. A SAP instance profile parameter controls the maximum allowed time for interactive execution of a dialog step: rdisp /max _wprun _time The default value for this parameter is 300, which indicates the length of time in seconds that the dispatcher allows the work process to run. When this value is reached, the dispatcher stops the work process and the user gets a TIME_OUT error.
Background Work Processes
The background work processes are in charge of executing ABAP programs submitted for background execution. Large background processes are best suited for periods when the system isn't used interactively such as in the evenings. From an administrative point of view, the background work processes correspond to the batch jobs queues. The ABAP programs submitted for background processing are executed in the planned time by the background work processes. The sequence of program execution is scheduled with batch jobs.
Application server with background work process
Every job can be made of one or several steps that are consecutively processed. A step is an ABAP program or an external program. There are many types of jobs and different ways to submit them for execution. Normally, these background jobs are not immediately processed but are processed when the system reaches the planned time for execution if there are available resources. Background processing is very useful for submitting programs requiring long processing times, because interactive execution would exceed the allowed processing time (rdisp/max_wprun_time) and thus abort with a TIME_OUT error, as indicated in the previous section.
There is a batch scheduler that takes care of initiating the jobs at the specified time. The system allows for periodic jobs' execution. This means that programs are submitted with a repetition interval, and when the jobs execute themselves, the first thing they do is plan a new execution time at the required interval. This feature is very useful for control or cleaning jobs within Web AS.
The SAP profile parameter that controls the number of background work processes per instance is rdisp /wp_no_btc. The background process can be further organized into different types of job queues based on the priorities needed in the particular installation. Background jobs are very important in the daily management and operation of the system.
Spool Work Process
The spool work process is in charge of formatting the data for printing and passing it to the host spool system. Figure includes a simple scheme of a SAP instance with a spool work process. The spool requests, indicating the printer and the printing format of the spool request, are generated during dialog or background processing and are held on the spool database. The data themselves are kept in a special area, known as TemSe (temporal sequential objects), which is additional SAP Web data that is stored temporarily. There is a profile parameter rspo/store_location that controls where the TemSe stores the Web AS spool data. It can be either on the database or on a file. When the data are to be printed for the spool job, an output request is generated, which is executed by the spool work process. Once the spool work process has edited the data for printing, it sends a print request to the operating system host spool.
Spool work process
The SAP profile parameter that controls the number of spool work processes per instance is rdisp/wp_no_spo. Before release 4.0 this value was limited to one spool work process per SAP instance, although there was the possibility of installing more than one instance per host and getting more than one spool work process. That restriction does not exist anymore with release 4.0 and newer releases.
Enqueue Work Process
The enqueue work process, also known as the lock work process because it has direct access to the lock table, is in charge of the lock management system. It allows multiple application servers to synchronize their access to the database and maintain the data consistency. In order for the system to run in a consistent manner, it must ensure that when a transaction's dialog steps are handled by different work processes, they retain the assigned locks until the end of the transaction or the intentional release of the lock, even when switching work processes. Commonly there is only one enqueue work process for a single SAP system; however, there are circumstances where, for performance reasons, it might be useful to configure up to four enqueue work processes for a setting of two to four large systems. Web AS note 127773 contains details. The profile parameter that controls the number of enqueue work processes is rdisp/wp _no _enq.
The function of this work process is to protect applications from blocking among themselves during data access. For that reason, a locking/unlocking mechanism must be present. This is the function of the enqueue work process. The locks (enqueues) are managed by the enqueue work process using a lock table that resides in the main memory. When the processes receive a locking request, the enqueue work process verifies whether the requested lock object interferes with other existing entries in the lock table. The ABAP applications logic considers that data modifications are usually done when a previous reading has taken place. For that reason, the locking requests are made before the data reading requests.
SAP designed the locking mechanism so that each lock not only needs to be respected by the application server executing the transaction but also by all other servers within the SAP system. The name of the SAP instance running the enqueue service is included in the common parameter profile, the DEFAULT.PFL file. The parameter is rdisp/enqname = <instance_name>, for example, rdisp/enqname = adminix _C12 _00.
The lock objects are special types of objects defined in the ABAP dictionary. The blocking type can be shared (type S), exclusive (type E), or exclusive but not cumulative (type X). The exclusive locks are used to avoid parallel modification of the data, which means that exclusively locked data can be displayed or modified by only one user. With the shared mode, several users can access the same data at the same time in display mode. As soon as any user processes the data, the remaining users do not have further access to them. An optimistic lock is established when a user accesses a record and a concurrent transaction has not updated the record. If the concurrent transaction updates the record, the current user's transaction is rejected.
Locks of type exclusive but not cumulative can only be called once. So a lock request will be rejected if an exclusive lock already exists. When the lock objects are defined in the dictionary, there are two ABAP function modules automatically generated for them: one to lock the object (enqueue) and another function to unlock it (dequeue). These functions are called at the beginning and at the end of a transaction, respectively. If for some reason there are problems between the locking and unlocking of an object, it remains locked until the administrator manually deletes the lock. Refer to Chapter 10 on how to proceed with the locking mechanism management. The locking object mechanism is intimately related with the SAP logical units of work (SAP LUWs).
Update Work Process
The update work process is in charge of executing database changes when requested by the dialog or background work processes.
Update work process
The dialog work processes can generate database modifications with the corresponding instructions to the database server, independently of whether these work processes run on the same or different machines as the database.However, when the ABAP language element CALL FUNCTION ... IN UPDATE TASK is executed, it raises the order for the modification to occur in the update server. Specific update work processes then modify the database accordingly.
It is recommended to have the update service on the same server as the database for better performance. However, with fast network controllers, it does not make much difference having the update server on a different host than the database. The update is an asynchronous process, which means that the update requests are processed at the moment and in the order they arrive at the work process. This makes a more homogeneous response time. The drawback is that the transaction might not have finished when another update transaction is waiting.
If for any reason the update transaction cannot be completely accomplished, the user will get a system message and an express mail. Sometimes this is due to database problems, such as tablespaces becoming full and the like. If the transaction could not finish correctly, the system rolls it back. The rollback of a transaction is possible by having a separate dialog part from the update part. The dialog program first generates log records in the VBLOG table, which are then processed by the update program (run within the update process) once the dialog is finished.
The log records, read by the update work process, contain all the necessary information to make the modifications. During the update phase, the database is modified. The update of a log record can have several parts, known as the update components. This division permits the system to structure the objects that make up the update transaction components according to their importance. An update request can contain a primary update component (V1) and several secondary ones (V2). The time-critical processes are held inside the V1, the less critical within the V2. In order to be able to initiate the V2 components of the log record, the V1 component must have finished. However, the V2 components can be executed in any order and even in parallel if there are enough update processes defined. The execution of primary components (V1) corresponding to different log records can be also done in parallel using several update work processes.
Before release 3.0 of R/3 , there was only one type of update work process taking care of both V1 and V2 components. With the release of version 3.0, a new profile parameter was established to indicate the number of update work processes for secondary components, also. The important profile parameter is rdisp/vbname = <instance name>. This is a common parameter for the full SAP system and therefore is always in the DEFAULT.PFL file. The other parameters, rdisp/wp_no_vb and rdisp/wp_no_vb2, indicate the number of update work processes of types V1 and V2, respectively. These are defined inside the instance-specific profile parameter file.
If there are error situations during the update, these cannot be solved with user online actions. The active update process component is then stopped. If the errors occurred in the primary component (V1) of a log record, the modifications are rolled back. The log record receives a corresponding status flag and is not taken out of the VBLOG table. Subsequent V2 update actions are not executed.
However, if the interrupted or error component is a type V2, only the modifications done by this particular component are rolled back. The corresponding log record is marked with a status flag and is not deleted from the table. The other components can follow normal update processing. After an error situation or update interruption, the system automatically notifies the user by express mail about the aborted update and creates an error log entry in the system log. Then it is possible to evaluate and treat the update according to the error message received.
The message server is a service used by the different application servers to exchange data and internal messages. This server does not have the structure of the typical work processes previously described. However, it acts like a service. The message server routes the messages between application servers. Since the release of version 3.0, it is also used for license checking and workload balancing together with the SAP logon utility. There is only one message server per SAP Web AS system. The message server process is the one that makes the application servers exchange messages between them, such as brief internal messages: update start, enqueue, dequeue, and batch job start. The communication is established among the dispatchers using the TCP/IP network protocol and the sockets defined in the services file.
Every application server has a unique name for the message server. All application servers know which the update server, the enqueue server, and the batch and spool servers are and set those services active, indicating an address to the message server. The location of the host running the message server is configured in the DEFAULT.PFL common profile. The parameter is rdisp/mshost = <hostname>. Notice the difference from previous parameters such as the update or enqueue services, in which the value of the parameter pointed out the instance name. In this case, the value is a hostname, as included in the standard TCP/IP hosts database. The message server host is not restricted to the database server. It can run on any of the hosts that make up the SAP client/serversystem. The way this service is started is also different from other work processes. It has its own start execution line in the start profile. Chapter 4 includes more information on the start profiles.
The gateway server allows the communication among Web AS R/3, R/2, and external applications. This service is a CPIC handler that implements the CPIC protocol for communication. This is commonly known as a SAP gateway. The function of the SAP gateway is to exchange larger amounts of data between application servers, in contrast to the message server, which only exchanges brief internal and control messages. The SAP gateway exchanges application data; thus the amount of information is larger. The communication agents can be located on the same system, in another Web AS system, in an R/2 system, and also in an external program. Figure shows a simple architecture of the SAP gateway server. The SAP gateway processes communicate using the TCP/IP protocol in the Web AS side and the LU 6.2 when communicating with IBM mainframes running R/2. In the case of Siemens equipment running R/2, the protocol used is UPIC.
The presentation interface is the component in charge of making functionally equivalent the presentation and the handling of Web AS, no matter the type of front end used. For each user session there is a SAP process (SAP GUI) that enables the use of all available presentation possibilities of the corresponding window software. These processes (historically known as terminal processes) are in charge of, among other things, managing the graphical elements of the Web AS system.
The connection between the SAP GUIs and the SAP dispatcher is made with an optimized protocol, known as DIAG, in which small data packages are sent through the network. In the SAP R/3 system, all the menus options, the buttons, and even most of the graphical elements are inside the database. This means that the real screens are not held in the PC software, but are sent on demand. You may notice that the time it takes to go from one screen to another is longer when you are among the first users to log on to the system. As the buffers become filled with cached data, this time noticeably decreases.The presentation interface allows for upload and download functions from the application server. It also includes possibilities for file transfers and communication with popular Windows applications, including MS-Excel, MS-Word, and MS-Access. This is possible, of course, when using a Windows-based front end. Both SAP GUI for HTML and SAP GUI for Windows have this capability.
Another feature available in the presentation interface is the SAP graphic utility, which establishes a dialog between the ABAP application and the graphic utility in the presentation server for extracting data to make up graphical representations of the information. You should refer to the SAP online documentation or print document file called SAP Graphics: User's Guide for more information and instructions on the subject.
The underlying database of the SAP Web AS system acts as the main container for all the information managed by the system. The database includes almost everything the users can see on their screens: program source code, screens, texts, menu options, customer information, printer definitions, statistical information, transactional data, and so forth. The database interface supports different relational databases from different vendors. The main task of the database interface is to convert the SQL requests (ABAP open SQL) from the SAP development environment to the database's own SQL requests. During the interpretation of the ABAP open SQL statements, the database interface makes a syntax check to verify that the statement is correct, and it also automatically tries to make an optimal use (reuse) of the SAP buffers in case a similar SQL statement was requested previously. These buffers are held locally in the main memory of each application server.
Besides using the portable SQL dialect from SAP (ABAP open SQL, previously known as SAP-SQL), it is also possible to access the database directly using ABAP native SQL (previously known as EXEC-SQL) statements. With ABAP native SQL calls, a developer can make specific database SQL calls, which are not supported using the standard ABAP open SQL statements. However, this method is not recommended because the code might not be completely portable or could cause problems during upgrading of the database engine or the Web AS applications. This method could also compromise sap's consistency/authorization security. SAP tools assist in maintaining authorization integrity.
The database interface also has a cursor caching method. Database cursors are like portions of memory that are allocated by the system to process SQL statements. A cursor caching method means that the system tries to reuse, if possible, the access paths that were previously used to process SQL statements. However, this method is not recommended because the code might not be completely portable or could cause problems during upgrading of the database engine or the Web AS applications. The database is the heart of the SAP Web AS system. It not only is the central source of information for companies' business data, but also the container of user information, software components, documentation, and administrative statistical data to be used when managing or monitoring the system.
One of the most important logical parts of the database is the ABAP object repository, which contains the following:
The database, of course, includes the data themselves. SAP distinguishes three different types of data: master, control, and transaction data. Master data contains information that does not change often, such as a user's name, printer's definition, or address of a supplier. This type of data is usually used the same way for similar objects. Control data is held in control tables and includes system and technical functions of the SAP system. Transaction data is the most volatile and frequently used information in day-to-day business operations, such as customer orders or accounting transactions including payments, debits, credits, and so on. The SAP-declared dictionary tables have the corresponding structure in the physical underlying database. The Web AS system handles different types of tables. SAP transparent tables are structures that exactly match an underlying database table. With certain database knowledge, users can view or manage these tables directly from the database's own utilities—but this is not advised because it may introduce inconsistencies. Other table types managed by SAP that may eventually disappear are cluster tables, made of several SAP tables related using foreign keys, and pooled tables, corresponding to a set of tables stored in a single table.
The database interface sends the data read from the ABAP dictionary tables to the ABAP programs by placing them in special work areas (memory buffers known to the work processes). Conversely, the database interface gets the modified data from those areas and sends them to the database. Software developers can easily declare and work with such areas because the dictionary is integrated with ABAP. Within an ABAP program, the developer can create additional tables that only exist as long as a program is running. These internal tables can be dynamically enlarged so that it is not necessary for developers to know in advance the amount of memory the internal tables will occupy.
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.