ITS

The technical differences between the R/3 System and the Internet make it necessary to use a special
program to connect these two systems. This is the task of the Internet Transaction Server (ITS).

The HTTP server cannot communicate directly with the R/3 System. Instead, the HTTP server starts the
Internet Transaction Server (ITS) which then establishes a connection to the R/3 System. The DIAG
interface of the R/3 System is used as the technical transmission channel for data exchange between these
systems.

The ITS forms the interface between an HTTP server and the R/3 system.

The ITS functions like a normal SAPgui in the R/3 System. It converts the screen data provided by the R/3
System into HTML documents and vice versa. Advantages of this procedure are:

A Web transaction can, almost completely, be developed and tested in the R/3 System.
Only tried and tested standard R/3 interfaces are used for the connection.
The different components of Web transactions can be included in the Workbench Organizer thus
making it easy to update SAP applications. Web transactions, like other applications, can first be
developed in a test system and later transported to the production system.
All transaction components, including those used by the ITS outside of the R/3 System at runtime, can
be stored in the R/3 System.
The advantages of automatic language processing in the R/3 System can be utilized to create language-
dependent HTML documents at runtime.

The SAP procedure allows you to create R/3 transactions for the Internet. The R/3 transaction must,
however, first be adapted to Web requirements.

ITS Tools

In addition to the ABAP/4 Development Workbench, you can use the following tools to develop Web
transactions:

ITS Debugger

The ITS debugger is not an independent tool but a special function of the ITS. You can use the ITS
debugger to establish a parallel connection between a Web transaction and a normal SAPgui. The
transaction is then displayed simultaneously in the Web browser and the SAPgui. You can activate the
ABA/4 debugger in the SAPgui and use it to analyze the current Web transaction.

SAP@Web Studio

You can use the SAP@Web Studio to edit files which are stored outside of the R/3 System in the Internet
Transaction Server's file system. The Web Studio plays an important role in creating transactions for the
Web. All files required by the ITS should be edited in the Web Studio.
The Web Studio operates outside of the R/3 System, but it is used for transferring the ITS files into the R/3
System.

Using the ITS Debugger

The ITS debugger displays the status of a transaction simultaneously in the SAPgui and Web browser. In
this way, you can determine whether a Web browser action has produced the desired result in the SAPgui.

Compiled By: Seetharam Maddali

ITS

The SAPgui is always ready for input; in other words, the ITS transfers each action in the SAPgui directly
to the application server.

To analyze an IAC transaction, log on to the ITS using the SAPgui like you would log on to an application
server.

Displaying the Transaction Status

The way in which the ITS integrates the SAP debugging tools allows you to display the Web browser and
the SAPgui simultaneously.
You can synchronize these two user interfaces by logging on to the ITS using the SAPgui. Then, when you
execute an action in the Web browser which changes the transaction status, the ITS immediately adapts the
SAPgui transaction screen.
The following figure illustrates this process.

Compiled By: Seetharam Maddali

ITS

Using the Transaction in the SAPgui

The SAPgui not only displays the transaction status but is also ready for input. The ITS transfers each
action executed in the SAPgui directly to the application server.
However, the Web browser status cannot be synchronized due to technical reasons.
The following figure illustrates this process.

Compiled By: Seetharam Maddali

ITS

Using the ABAP/4 Debugger

Since the transaction in the SAPgui is ready for input, you can activate the debugging mode by entering /H
in the SAPgui command line.
The ABAP/4 debugger is displayed in the SAPgui the next time an action is executed in Web browser. The
debugger then processes the input values that the ITS transfers to the transaction from the Web browser.
The following figure illustrates this process.

Compiled By: Seetharam Maddali

ITS

Using SAP@Web Studio

The SAP@Web Studio is important for all tasks which are executed outside the R/3 System.

You can use the Web Studio to store files in the directory structure required by the ITS. It also enables you
to store objects in the R/3 System and include these in the R/3 Workbench Organizer. The Web Studio
automatically creates service descriptions, language resource files and HTML templates based on the data
you enter and allows you to maintain these.
How to install the Web Studio is described in the SAP@Web Installation manual.
The Web Studio has three windows:

The left window lists the different objects. You can select an object from this window.
The right window displays the selected object and allows you to edit individual files.
The bottom window shows the status and error messages which appear while files are being edited.

The following figure shows the Web Studio.

Compiled By: Seetharam Maddali

ITS

The Check-In/Check-Out Procedure

Edited objects are maintained in the R/3 System using the Workbench Organizer (WBO). The Workbench
Organizer locks objects which are being edited and therefore ensures that only one user can edit an object
at any one time. In addition, the WBO transports edited objects to other R/3 Systems. The Workbench
Organizer can be called using R/3 tools.
When you load Web transaction objects from the R/3 System into the Web Studio for external editing,
these objects must also be protected against editing by other developers. Since the WBO cannot be called
directly from external applications, a special procedure is required for connection to the Web Studio.
You must use a check-in/check-out procedure when loading the objects into the Web Studio for editing and
writing them to the R/3 System after editing has been completed. When an object is checked out, a flag is
set in the R/3 System. When this object is checked in again, the flag is reset. Since this flag must be reset
before an object can be checked out, only one developer can edit an object at any time. Check-in must be
executed at the same computer and by the same developer as check-out.

Assigning Objects to a Correction

You must not only protect objects against simultaneous editing but must also ensure that each object is
inserted in the WBO. All objects which are loaded from the R/3 System to a local computer must be
assigned to an open correction or repair.
Before Web objects can be checked out, they must be assigned to an open correction in the R/3 System
using the transaction SMW0. If no open correction exists, the transaction creates one.

Transporting Objects

When a transaction is created, certain objects (service description, HTML templates, language resource
files) are created outside the R/3 System. These objects must then be transported from the Web Studio to
the R/3 System after the transaction has been tested. Since these objects have no predecessors in the R/3
System, they can be transported without having to be checked against existing objects.

To transport objects, enter the transaction code SMW0 in the command field of the SAPgui. To display the
new objects select Settings Choose New ITS Objects. Assign the new objects to a correction.
When you assign a new object to a correction, the WBO creates a TADIR entry for the object. The 'new
object' flag is reset when the TADIR entry is created.

Objects that do not yet have a TADIR entry (i.e. new objects that have been checked in) can be reserved
without being assigned to a correction.

Starting a Web Studio Session:

To start the Web Studio, select Start Programs SAP@Web Studio Studio in the Windows NT4.0
desktop.

Defining the Root Directories

The Web Studio functions correctly only if two root directories have been defined. These directories are
described in Directory Structure.
To define these root directories, select Options Set Working Dir and Options Set WebServer Root Dir
in the Web Studio. The syntax of the object names enables the Web Studio to create a relevant path name
for each ITS object in the root directory.

Compiled By: Seetharam Maddali

ITS

Security Aspects

This section describes the security measures that can be applied when the Internet Transaction Server (ITS)
is used to connect the R/3 System to the Internet.
The ITS consists of two parts, WGate and AGate:

WGate is the part of the ITS that connects to an HTTP server.

AGate is the part of the ITS that communicates with the R/3 System. It transfers and translates data
between WGate and the R/3 System.

The description of the important security aspects when connecting an R/3 System to the Internet requires
knowledge of the complete system architecture.

The following diagram illustrates the structure of a complete installation.

The HTTP server (1) forms the interface to the Web. Closely integrated (as a DLL), the WGate (2)
represents the general interface between the HTTP server and the AGate gateway (3). AGate communicates
with the HTTP server on one end and with the R/3 System (4) on the other. The separation of AGate and
WGate means that AGate and the HTTP server can be installed on different systems.
The connection between the Web browser (5) and the HTTP server is over TCP/IP. A proprietary protocol
is used between WGate and AGate. The DIAG and RFC protocols are used for the link between AGate and
the R/3 System.

Compiled By: Seetharam Maddali

ITS

General Security Measures

The architecture of the R/3 connection and the principal characteristics of the Web affect system security.
This section describes several of the basic security measures.

HTTP-S and Product-Specific Security Measures

There is no direct relationship between use of the ITS and the security of the connection between the Web
browser and the HTTP server.
If necessary, the connection between the HTTP server and the Web browser should be secured with
conventional means such as HTTP-S.
You should also follow the latest recommendations provided by the vendor of your HTTP server software
regarding the security of the connection between the Web browser and the HTTP server.

Separated Installation
The WGate DLL runs in the HTTP server's address space. Theoretically, this setup allows manipulation
which could permit unauthorized third parties access to the resources of the system where the HTTP server
is running. For this reason, the HTTP server should be installed on a system separate from the AGate
system.
The file system of the AGate system contains several essential files for the ITS which contain security-
relevant information such as passwords. Although this information is encoded, we recommend very secure
protection of the file system. If you install the HTTP server on a system separate from the system where
AGate is installed, you can protect the AGate system from the HTTP server system using a firewall, as
described in the next section.

Firewalls

A firewall opens access to a server only for selected programs and services. Generally, a firewall is always
used to separate an internal network from the Internet. Such a firewall is recommended for all Web
applications, not only those that are based on the ITS.
SAP recommends that you install a firewall between the computer used for the HTTP servers and that used
for the AGate. This requires you to install WGate and AGate on different systems.
Depending on the configuration of the R/3 System, it may also make sense to use another firewall and a
SAProuter to protect the application server(s).

ITS Security Measures

In addition to the general security measures that should be present regardless of ITS, the ITS itself
contributes towards system security. This section describes the security measures provided by ITS.

Encryption

The data stream between WGate and AGate can be encrypted to prevent third party interception. This
currently involves a proprietary solution. SAP are currently working on implementing a commercial
security product.
To encrypt the data stream between WGate and AGate, set the registry parameter SecureCommunication on
the AGate system to 1. This key is in
HKEY_LOCAL_MACHINE SOFTWARE SAP ITS AGate.
A generally applicable logon must exist for all services for which no individual logon process into the R/3
System is supported. The necessary data - including the password - is saved in the service description. The

Compiled By: Seetharam Maddali

ITS

password is DES encrypted. For this reason, a special tool (such as the SAP@Web Studio of ITS) must be
used to modify the passwords.

Protection Against Break-Ins

A logon to the R/3 System is required for every service that is started from the Web. ITS stores a status for
each current transaction. Accordingly, all user requests received from the Web that are part of a Web
transaction can utilize the existing connection to the R/3 System. Because all transactions in the Web are
status-free, requests from the Web must be assigned to an R/3 connection. The assignment of status-free
requests from the Web to existing connections in the R/3 System theoretically enables unauthorized third-
parties to piggyback on an existing session. Appropriate ITS measures are used to hinder such attempts.

Compiled By: Seetharam Maddali