The SAP Internet Programming Model, Part 1

Transcription

1 The SAP Internet Programming Model, Part 1 Since the first SAP ITS-enabled R/3 release (R/3 3.1G), the number of standard Internet Applications Components (IACs) provided by SAP has constantly increased. SAP R/3 4.5 currently provides over 100. These IACs are available in many different application areas of the R/3 System, but SAP is currently focusing on procurement, self-service areas such as human resources, and consumer-to-business functionality. This is the first in a series of articles that will walk you through the current SAP Internet programming model. This article lays the groundwork by examining the SAP Internet Transaction Server (SAP ITS) architecture and core concepts. All IACs delivered with the standard R/3 System are based on a common infrastructure called SAP ITS. The SAP Basis infrastructure consists of two components: SAP ITS is the runtime engine bridging the R/3 application server and mainstream Web server software. It supports Netscape Enterprise Server (NSAPI), Microsoft IIS (ISAPI), or any CGIcapable Web server. SAP@Web Studio is the extension to the SAP development environment for Web-related objects residing outside the R/3 System. The SAP ITS development approach is to write Internet applications inside the R/3 System using the R/3 programming model for R/3 transactions, function modules, and reporting. This approach is also known as the "inside-out" approach because the business logic programming, process, and customization of the Internet applications occur within the R/3 System. Outside the R/3 System, the visualization of these Internet applications (in the form of HTML template files, MIME files such as images, sound, video, and so forth) is stored. R/3 is used as the Internet application builder platform, and SAP ITS extends the R/3 environment to the Internet. SAP is now using this approach for all of its IACs so that customers can develop, deploy, maintain, and upgrade all their business logic (Internet as well as regular SAPGUI-based applications) in a single development and runtime environment. For Internet application developers, it provides a homogeneous environment with advantages such as single language programming (ABAP), R/3 data dictionary support, R/3 transaction handling, etc. In addition, many important features of the R/3 System (such as internationalization and load balancing) are automatically extended to the Internet. In working to Internet-enable the R/3 System, the ITS development team defined the following key requirements: Performance and scalability Compatibility with all standard Web browsers (no special software or plug-ins required on the client; however, if needed, Java, Javascript, etc. possible on client) Security Separation of business logic and visual appearance Common basis for all R/3 application areas World-wide market (i.e., same application can run in any location without code modifications) Backward compatibility (>= R/3 3.0D)

2 Satellite system (i.e., Basis system can be installed and upgraded independently from core R/3 System). The idea of separating business logic and visualization is based on the assumption that successful Internet applications require developers with different skill sets: A good programmer who understands the business requirements and knows how to code the business logic A good designer or UI specialist who not only understands graphic design but also can give recommendations for an intuitive user interface. It is difficult to find developers who possess both of these skill sets. ITS puts these skill sets together as follows: The UI designer and ABAP programmer begin jointly by defining and designing the application, including its navigation from a user interface perspective. The UI designer works hand-in-hand with the application programmer even before the ABAP coding starts defining a UI from a usability perspective. The ABAP programmer then writes the actual application in the SAP development environment and can test it by using the SAPGUI only. No HTML layer is required at this stage. The UI designer takes over after the application has been coded and is running in the SAPGUI environment. SAP@Web Studio is used to create the look of the application with HTML. No expertise in the ABAP development environment, business application programming, or R/3 customizing is necessary. Because HTML is the common denominator that all major browsers can handle, ITS is primarily used to send plain HTML to the browser. If your user community has a homogeneous installation of a recent Web browser, you can also use DHTML, JavaScript, VBScript, and JavaApplets in your HTML templates. The language you use in the templates is transparent to SAP ITS. ARCHITECTURE SAP ITS is a gateway between the Web server and the SAP R/3 application server. It allows for effective communication between the two systems despite their technical differences (e.g., stateless World Wide Web vs. session concept/state in the R/3 System). Currently available for the Windows NT platform, SAP ITS consists of two major components: the Web Gateway (WGate) and the Application Gateway (AGate). WGate extends the Web server functionality. It constitutes a relatively small portion of SAP ITS functionality compared to the AGate component. WGate forwards each incoming request to AGate, thus accomplishing two goals: 1. The ITS server process (AGate) can be detached from the actual Web server. For security and performance reasons, AGate can be installed on a host separate from the Web server and WGate. This dual host installation physically separates all sensitive information on AGate from the Web server host, which is typically considered vulnerable to security intrusions. You can also put AGate behind a firewall for additional security.

3 Although both components can be installed on a single host, SAP recommends the dual host for production installations. For simple test or development installations without security concerns, a single host installation is sufficient. 2. The Web server specifics are encapsulated in the WGate component and do not affect AGate. The installation program automatically detects which Web server you are running and installs the matching WGate. WGate is available in NSAPI (Netscape), ISAPI (Microsoft), or CGI versions. Regardless of whether you select a single or dual host installation for SAP ITS, AGate is an active server process that can allocate its resources independently of any Web server constraints. Among many other things, AGate is responsible for: Establishing the R/3 connection using the DIAG (=SAPGUI) or RFC protocol Generating HTML pages based on the data from the R/3 System Managing the login process Managing the session context and timeouts Code page conversions and national language support. AGate can communicate to one dedicated R/3 application server, or it can be configured to use the SAP message server to loadbalance incoming requests over a number of R/3 application servers. WGate and AGate communicate via SAP Network Interface (NI) over a TCP/IP connection. In addition to these two key components, there is a Windows NT service called ITS Manager that is responsible for starting and stopping the AGate process as well as monitoring the AGate process during runtime. VIRTUAL SAP ITS INSTANCES You can have several SAP ITS installations on a single Windows NT host. These virtual SAP ITS instances all share the same executable code (so you cannot install two different SAP ITS versions on a single host) but run with completely separate configuration settings and separate directory trees for their respective HTML templates, service files, and so forth. An SAP ITS instance typically corresponds to one R/3 System. A high-load production instance is usually put onto a dedicated host. For development and testing, however, several SAP ITS instances can be installed on the same hardware. This lowers the number of physical hosts required if you have SAP ITS installations with low load requirements. Each virtual SAP ITS instance requires a dedicated Web server. (IIS4.0 and Netscape Enterprise Server 3.0 and 3.51 support the configuration of virtual Web servers.) SAP also recommends putting the Web-based SAP ITS administration tool on a separate SAP ITS instance for security reasons. This tool provides information on performance and grants access to the configuration of all SAP ITS instances installed on the same host. The monitoring functions provide current and historic performance information and give access to SAP ITS log and trace files. Administration functions include access to the registry as well as SAP ITS configuration files (such as service files and HTML templates). For security reasons, you should not run this administrator tool as a part of any production SAP ITS instance.

4 NATIONAL LANGUAGE SUPPORT SAP ITS offers National Language Support (NLS) via the Unicode character set delivered with Microsoft Windows NT 4.0 at the AGate component. By using Unicode, SAP ITS is able to run multiple distinct character sets on one hardware box without requiring additional SAP ITS servers for this purpose. Therefore, SAP ITS avoids the complexity of handling multiple character sets. Where Unicode is not yet supported, SAP ITS automatically converts to and from multibyte code pages. To support multiple language variants of the same transaction, SAP ITS not only provides the codepage capabilities but also separate language resource files. Internally, SAP ITS provides NLS through language-independent HTML templates into which language-specific text can be merged at runtime from the SAP R/3 data dictionary or from a language resource file residing on the ITS server. SAP recommends that you retrieve all language-dependent text from the SAP R/3 data dictionary. Language resource files provide an alternate source. SAP ITS AT RUN TIME All SAP ITS-based Internet applications are called IACs regardless whether they are implemented as transactions, RFCs, or reports. Although this article series focuses on the Web transaction programming model (as most IACs are implemented as R/3 transactions), WebRFC and Web Reporting programming options are also available with SAP ITS. Not every R/3 transaction can be run on the Internet immediately -- for technical and usability reasons. (A future article in the series will discuss the criteria transactions must meet in order to run on the Web.) A service -- an Internet application based on a Web-enabled IAC -- consists of a "service" file (containing all settings required to connect to R/3 and to control the connection), HTML templates, language resources, and any graphics that may be needed. Figure 1 shows the principle operation of ITS for one

5 request/response cycle. Figure 1. An ITS request/response cycle. Let's say you want to start a service called "purchase" from your Web browser (see Figure 2). You would send the following URL to your Web server: " Figure 2. Starting a service from a Web browser. The Web server calls the extension wgate. WGate establishes the connection and forwards the information to AGate. AGate then loads a service file. You can define parameters in a particular service file or in a central overall service file that contains settings that apply to all services (global.srvc). The more specific setting always overrides the more general setting if a parameter is defined more than once. In our example, AGate looks for the service file named Purchase.srvc. The service file always defines which R/3 application will drive the service. In the case of a Web Transaction, the parameter ~transaction is always defined in the service file. Parameters required but not defined in the specific service file Purchase.srvc will be resolved via the global.srvc. (The R/3 System connect settings typically apply to all services alike and are consequently defined in the global.srvc). Typically, global.srvc is defined during the SAP ITS installation process. AGate opens a SAPGUI connection to the R/3 System because you're requesting a service start -- designated by the "!" on the URL. If this were not a service start but a subsequent request by the same user, ITS would identify the SAPGUI connection previously established and send the information down

6 to R/3 on that channel. SAP ITS identifies sessions by a session ID, which is either returned from the browser to the server on the URL or in a cookie (see service file setting ~cookies). The R/3 System starts the transaction and sends the initial screen to AGate. AGate finds the template matching this screen. There is a one-to-one relationship between screens and HTML templates. Templates are named by program name and screen number (for example, zmwzpocr_1000.html). If there are language resource files, AGate will load them at this time. AGate then interprets the HTML template file and merges the information displayed on the R/3 screen (and contained in the language resource file) into the HTML template, creating the actual Web page. AGate forwards that page via WGate and the Web server to the Web browser. Let's say your R/3 instance has a Web transaction zpocr consisting of two screens -- screen 1000 and screen 3000 in a program called zmwzpocr. On the SAP ITS server, you have a service file called purchase.srvc, and it contains an entry ~transaction zpocr. Also, you have a template file for each R/3 screen -- zmwzpocr_1000.html and zmwzpocr_3000.html -- on the SAP ITS server. As soon as SAP ITS receives the request to start service purchase, it determines via the service file purchase.srvc that it needs to start Web transaction zpocr. AGate establishes a connection to R/3 based on the connection parameters defined in the service files and logs on to R/3. As soon as the first R/3 screen (1000) comes up, SAP ITS locates the matching HTML template (zmwzpocr_1000.html) and merges the R/3 data into the template, creating the final Web page 1000, which it sends to the browser (see Figure 3, arrows 1 and 2).

7 Figure 3. Steps of a Web transaction. Your user keys in the required information and submits the HTML form. SAP ITS receives the HTTP request and writes the data received from the Web onto the R/3 screen (arrow 3). SAP ITS maps each HTTP request variable to a corresponding R/3 screen field by matching the HTTP request variable name with the R/3 screen element name. SAP ITS then starts the processing in R/3 by sending an OK code received from the Web (arrow 4). As soon as the next R/3 screen (3000) comes up, the same sequence of steps is repeated. IMPLEMENTATION DETAILS AGate is implemented with a so-called dispatcher/worker thread model. A dedicated dispatcher thread listens on the port for incoming requests from WGate. As soon as a request is received, the dispatcher thread picks an idle worker thread from a pool of worker threads. If no worker thread is available, the incoming request is queued. The worker thread determines whether the incoming request is an initial request from a new user or a subsequent request from an already ongoing session. If it is an initial request, the worker thread looks for an empty slot in the session pool data structure. When it finds a slot, it assigns the request a session ID. (This session ID is later sent with the response to the Web browser to identify future requests as part of the same session.) It then opens a SAPGUI connection to R/3 and initiates the logon procedure to R/3. All information pertaining to this connection is stored for future reference in the session slot. Thus, the session pool keeps track of all R/3 connections for currently pending Web sessions. The session pool is statically allocated at startup time of the AGate process. If it is a subsequent request, the worker thread identifies the Web user by looking at the session ID and finds the corresponding session pool slot that contains all information to resume communication in the ongoing R/3 session. After the connection to R/3 is established or found in the session pool, the worker thread passes the information it received from the Web to R/3 and waits until R/3 responds. As soon as R/3 sends the follow-up screen, the worker thread finds the corresponding HTML template and interprets it -- that is, fills the data received from R/3 into the HTML template file -- before sending it back to WGate. The worker thread then becomes idle again and returns to the pool of worker threads. The connection to R/3 remains open, and its status is stored in the session pool. So that sessions don't remain open indefinitely, there is a timeout thread, which rolls over all session slots in use to determine whether the timeout limit has been reached. If it has, the connection is closed and the session slot is marked unused again. It is important to point out that a thread is only busy for one request/response cycle. It's not bound to a Web session. So the number of worker threads you need to configure should equal the number of requests you want to handle concurrently.

8 The session slot however remains allocated until the Web session is terminated. Termination can occur through an explicit logoff from the user, through timeout, or if the same service is started from the same browser (in which case the previous session is automatically cleared). TUNING INFORMATION The SAP ITS monitoring and administration tool (available as of version 2.2) provides access to key performance numbers for each SAP ITS instance (see Figure 4). Figure 4. ITS Administration. The SAP ITS setup procedure provides two registry configurations that are appropriate for most initial configuration needs: Default configuration (requiring 128MB of memory) Minimize memory usage (requiring 32MB of memory). Choose Minimize memory usage if you are setting up a small test or development system. This setting is especially useful for setting up ITS on your personal development PC. For production installations, choose Default configuration.

9 You can configure the session pool and the worker threads in the Windows NT registry. SAP recommends using the SAP ITS administration tool, which gives you access to all configuration parameters and SAP ITS performance information from a Web browser. In the default configuration, the worker threads are configured as follows: MaxWorkThreads. The maximum number of worker threads allowed for a single SAP ITS instance. The default value for the Minimize memory usage configuration is 4. For Default configuration there is a value of 80. The number of worker threads determines how many requests can be handled concurrently. MinWorkThreads. The minimum number of worker threads the instance is allowed. Obviously, MinWorkThreads always has to be smaller than or equal to MaxWorkThreads. When AGate starts, only MinWorkThreads will be created. If the dispatcher thread can't find any idle worker threads anymore, it will create additional worker threads until it hits the MaxWorkThreads limit. The default value for Minimize memory usage is also 4. Every five minutes, the timeout thread checks the number of idle threads. If there are enough, the number of worker threads reverts back toward the default by IncWorkThread. IncWorkThread. This parameter controls how many worker threads can be created or destroyed at a time. The default value is 1. MaxSessions. The maximum number of sessions an SAP ITS instance is allowed to handle. In other words, this parameter determines the number of session slots available. For Minimum memory usage, it defines a session pool with 100 slots. For Default configuration, it defines a pool with 2000 slots. TimeoutSweep. The interval of time (in seconds) specifying how often SAP ITS checks for timed-out sessions. SAP ITS sessions that exceed their timeout maximums without sending a request are killed. TimeoutPercentage. The proportion of the timeout limit that is granted to sessions in situations of high load. When the maximum number of sessions has been reached, SAP ITS may kill idle sessions before they reach their timeout limits. For example, if a service has a timeout limit of 20 minutes, and TimeoutPercentage is 75 percent, then a session running this service could, in high-load situations, be terminated after an idle time of only 15 minutes. SECURITY The R/3 Internet architecture has many built-in security features, such as the option to run WGate and AGate on separate hosts. SAP recommends that you set up a network infrastructure that makes use of these features to control access from the Internet and intranets to SAP ITS and the core business system. SAP also recommends that you use other security components, such as firewalls, packet filters and SAPRouters to separate individual parts of the network from one another. If you follow these guidelines, unauthorized access -- if it does occur -- is restricted to a small part of the system and cannot harm your internal systems, including R/3.

10 There are two key actions involved in securing a network infrastructure: Protect key components by firewalls to break down the network infrastructure into smaller compartments, tightening access restrictions the closer you get to R/3. Encrypt the communication between components. FIREWALLS As Figure 5 illustrates, you can configure up to three firewalls: Figure 5. The three levels of firewall (security zones increase from left to right). Web server protection. The Web server should always be protected against all network packets other than HTTP. You can accomplish this by configuring the router to pass packets to the corresponding TCP port only. The default port of all Web servers is 80 for the unencrypted HTTP protocol. Web servers that support HTTPS (HTTP plus the Secure Sockets Layer) use port 443 by default. HTTPS provides the encryption between Web browser and Web server and should be used for communication of sensitive information. This first router and packet filter allows access from the general Internet (or intranet) to the Web server's TCP port. Windows NT on the Web server should be set up to be as restrictive as possible from a security perspective. All unnecessary network services should be disabled. AGate server protection. SAP recommends that you take additional measures to isolate the Web server from the internal corporate network. This prevents additional damage if, for example, an intruder were to gain control of the Web server. You should impose strict controls over any connection between the external network, where the Web server and WGate are located, and the internal corporate network that contains the AGate server.

11 R/3 server protection. For maximum security, you can install a firewall between AGate and R/3. ENCRYPTION The obvious communications choice between Web browser and Web server is HTTPS. Between WGate and AGate you can choose between an easy-to-install DES-based encoding (as opposed to strong encryption) and the more sophisticated SNC-based encryption. To use SNC between AGate and R/3, you need ITS 2.2. The simple DES-style encoding of communication is based on a static key and can consequently provide only limited protection. SNC uses an external security product to apply encryption to communication links. An additional security product needs to be set up prior to the ITS installation and must be configured to integrate with R/3 and ITS. SNC provides the best security option but requires much more effort to put in place. FURTHER INFORMATION If you do not have ITS and SAP@Web Studio, you can download them free from All ITS releases are backward compatible to R/3 3.0D and higher. For further information on other options -- such as internationalization, binary data transfer between R/3 and ITS, and resynchronization, consider the following resources: Programmer's documentation: SAP@Web Studio Help or R/3 online documentation CD-ROM Latest ITS releases for download: devarea/its.htm SAP TechEd'98 post-conference CD-ROM SAP Security Guide SAP training class BC440. Note : This article appeared in the first issue on Please visit the above site for the original article