SAP R/3 Dcoument : The SAP ITS Architecture:

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 CGI-
capable 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)

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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: "www.mysite.com":
http://www.mysite.com/scripts/wgate/purchase/!

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

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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).

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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.

Article From www.saptechjournal.com

SAP R/3 Dcoument : The SAP ITS Architecture:

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 www.saplabs.com. 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: http://www.saplabs.com/ 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

www.saptechjournal.com

Please visit the above site for the original article

Article From www.saptechjournal.com