Internet Transaction Server: How SAP Screens Reach the Browser

The internet transaction server, almost always shortened to ITS, is a translator. On one side sits an SAP system whose transactions draw their own screens, built for the SAP GUI program that users install on their PCs. On the other side sits a web browser that understands HTML and nothing else. The ITS stands between the two and converts: it takes the screen an SAP transaction produces, rebuilds it as an HTML page for the browser, and carries the user’s clicks and typing back.

That one trick changed who could use SAP. A purchasing clerk, a manager approving leave, or a supplier checking an order no longer needed SAP software installed and configured on their machine. They needed a browser and a web address. SAP built whole product lines on it in the R/3 era, from employee self-service to online stores, because an existing transaction became a web application without a rewrite.

This guide explains how the internet transaction server in SAP works: what it converts, the standalone version, the integrated version inside today’s systems, the templates and services underneath, the ITSmobile variant for warehouse scanners, and the admin and security basics from SAP’s own documentation.

What the internet transaction server actually converts

An SAP transaction is a program that works screen by screen. SAP calls these screens dynpros, and the SAP GUI draws them with its own controls: input fields, tables, tabs and buttons that exist nowhere in HTML. A browser cannot show a dynpro. So the ITS keeps an HTML template for each screen, a page layout with marked spaces where the live values belong. At runtime the ITS takes the values from the current screen, pours them into the template, and sends finished HTML to the browser.

The templates mix plain HTML with HTMLBusiness, SAP’s template language for the ITS, which places the screen’s field values and labels into the page. When the user clicks a button, the browser posts the form, the ITS hands the entries to the transaction as if typed into the SAP GUI, the transaction moves to its next screen, and the ITS converts that screen in turn. SAP’s documentation describes the ITS watching for mismatches too: if the screen in SAP and the page in the browser fall out of step, the ITS tells the transaction to resynchronize.

Two points matter here. First, nothing about the transaction changes: the same ABAP program, the same business logic and the same authorizations run as in the GUI. Second, the conversion happens live, screen by screen, which is why the ITS could put an existing transaction on the web in days instead of the months a rewrite would take. Teams treated it as a fast shortcut to web access for systems they already owned, much like the build, test and learn loop in our rapid prototyping guide.

The ITS also sat inside a bigger story. Getting a closed enterprise system to face the web was one half of a wider problem, and our guide to enterprise application integration covers the other half: how SAP and its neighbors exchange data behind the scenes. The ITS handled the human-facing half, the screens.

The standalone ITS: WGate, AGate and a server of its own

In the R/3 era, the internet transaction server was a separate product installed on its own machine, next to a web server. SAP’s installation guides from that period, such as the SAP@Web guide for release 4.6C, describe two components doing the work.

The first component, the WGate or Web Gateway, lived on the same machine as the web server, received each browser request, and forwarded it over a TCP/IP connection. The second, the AGate or Application Gateway, did the heavy lifting: it signed in to the SAP system the way an SAP GUI would, ran the transaction on the user’s behalf, and turned the resulting screens into HTML pages. Bigger installations added more AGate servers, and the WGate shared new sessions evenly across them.

Running a standalone ITS meant publishing. Developers built a service for each transaction (services are explained below), then published its templates and MIME files to the ITS server’s file system. Settings lived in plain text parameter files named like global.srvc and webgui.srvc, and an ITS Administration tool watched over the AGate processes, workthreads and sessions. It worked, but it was one more server to install, patch and keep in step with the SAP system behind it.

The integrated ITS: the translator moves inside

SAP ended that arrangement with SAP Web Application Server 6.40. From that release on, the integrated internet transaction server is part of the application server and is installed automatically together with the SAP kernel. Nothing extra needs a separate machine, and the browser talks directly to the SAP system. SAP’s own overview of ITS in the NetWeaver Application Server walks through the differences in detail.

Three changes define the integrated design. First, the WGate is gone: the Internet Communication Manager, or ICM, receives HTTP requests and passes them to the ITS request handler, so no separate web server is needed either. Second, the files moved: templates and MIME files live in the SAP system database and load at runtime, and the old .srvc parameter files disappeared, replaced by per-service settings in transaction SICF. Third, the plumbing is shared: normal SAP work processes and ICF session management replace the ITS’s own workthreads and session store.

Platforms collect such specialist parts over the years: Java platforms define an application client container to run client-side programs against server resources, and the SAP platform keeps the integrated ITS to render screens for browsers. Both are named runtime pieces inside a bigger server, each doing one job well.

The integrated version has one firm limit, and SAP states it plainly: it supports screen-based applications only. Programs built on older ITS programming models, namely ITS Flow Logic, WebReporting, WebRFC and GUI XT, do not run on it. A company that still needs one of those must keep a standalone ITS for it. As a piece of software architecture, the whole move is a classic: SAP deleted an entire server tier by folding the translator into the platform.

Templates, themes and services: how a screen becomes a page

To put a transaction on the web, a developer creates an ITS service. SAP’s documentation defines a service as the set of files that controls one transaction called from a browser. The pieces are a service description with the controlling settings, one or more themes that carry the look of the pages, one or more HTML templates, and the ICF service definition that enters the service in the ICF tree. Language resource files and MIME files join the set when a service needs texts in several languages or its own images and media.

Developers build these files with the Web Application Builder, which is part of the ABAP Workbench. The builder stores the dynamic files (service descriptions, templates, language resources) in the system database, and the MIME files live there too, read once at runtime and then held in the ICM cache. A service answers to its service name rather than to the transaction code, although the two are often the same, and customer-built service names follow the usual naming rules and start with Y or Z. SAP explains each file type on its Creating the ITS Service help page.

Most users never meet a custom service, because SAP ships the most used one itself: webgui, better known as SAP GUI for HTML. It renders transaction screens on the fly, so a user who opens the WebGUI address gets the familiar SAP menu and can start transactions in the browser. Custom services matter where the plain GUI look does not fit, such as a simplified self-service page or the small screens of a scanner, which is where ITSmobile comes in.

ITSmobile: SAP on the warehouse scanner

Warehouses run on handheld devices: barcode scanners with small screens, a few big buttons and no mouse, carried down aisles all day. Standard WebGUI pages do not fit them, so SAP provides ITSmobile, the mobile branch of the ITS. SAP’s warehouse documentation explains that ITSmobile uses the same template technique, with an HTML template provided for every screen of the application, and ships with a template generator for simple screens.

In SAP Extended Warehouse Management, the RF framework (RF stands for radio frequency) connects these browser-based devices to the system, and SAP documents ITSmobile as the template-based connection for them. Because devices differ in screen size and browser, teams create different services with different style sheets for different device families, and they cut each screen down to the few fields a picker or packer actually needs: scan a bin, confirm a quantity, move on. The result feels nothing like desktop SAP, but the transactions behind it are the same ones.

The cloud shifts this picture slightly. In SAP S/4HANA Cloud, SAP’s support guidance names SAP GUI for HTML as the standard interface for RF devices and notes that there is no ITSmobile to configure there. On-premise systems, where most large warehouses still run, keep using ITSmobile, and the integrated ITS underneath it.

Running ITS today: activation, troubleshooting and security

Because the integrated ITS ships with the kernel, running it is mostly a matter of switches. SAP’s installation and activation page gives the order: set up and configure the ICM first, then, in transaction SICF, activate the service you want to run and the shared MIME service at default_host/sap/public/bc/its/mimes. The two SAP services system and webgui must also be published to the INTERNAL site, because other services borrow their objects. After that, SAP GUI for HTML answers at an address of the form http(s)://host:port/sap/bc/gui/sap/its/webgui.

Two profile parameters matter most. The parameter itsp/enable turns the integrated ITS on (1) or off (0), and SAP notes that even when it is on, the ITS only uses system resources when someone actually calls it. The parameter em/global_area_MB sizes the shared memory that holds the runtime versions of the HTMLBusiness templates, and it needs raising when users arrive in several languages or browsers, because each combination adds templates.

When a service will not open, admins tend to say the ITS is not available, and SAP’s ITS troubleshooting guide sends them through a fixed order of checks. Step one is the health check in transaction SITSPMON. Then come versions: the guide asks whether the SAP kernel, especially its disp+work component, is current, and whether the latest Basis support package has delivered the newest ITS handler classes, CL_HTTP_EXT_ITS and CL_HTTP_EXT_ITS_2. Configuration, the service’s GUI parameters and the ITS profile parameters, comes last. The guide also names the failures it sees most, such as a refused session carrying the message “New session was refused due to memory bottleneck”.

Security follows from the same switches, which is why “internet transaction server its security” is such a common search. The ITS puts a logon screen on the network, so the traffic should run over HTTPS; SAP’s tuning guide already treats encryption and decryption as one of the web server’s main costs. Every service activated in SICF is reachable, so admins activate only what the business uses. The itsp/enable switch doubles as a safety control: SAP suggests turning the ITS off on application servers that should never serve web screens, such as batch or update instances, and using dedicated servers for browser traffic. And because ITS fixes arrive inside kernel patches and Basis support packages, patching is a security habit here, not housekeeping.

Where the internet transaction server stands today

The ITS never left. It changed address. Inside every SAP NetWeaver Application Server, and the ABAP platform behind SAP S/4HANA on-premise systems, the integrated ITS still renders SAP GUI for HTML, still powers ITSmobile in warehouses, and still exposes custom services to browsers. SAP maintains it as a standard part of that platform, on the same kernel and support package rhythm as the rest of the stack.

Around it, the world moved on. SAP builds its newest screens as Fiori apps, designed for browsers and phones from the start, and S/4HANA’s home screens speak Fiori. But the classic transactions that run factories, warehouses and finance departments were written for the GUI, and companies still depend on large numbers of them. For those, the browser door is WebGUI, and behind WebGUI stands the ITS. The standalone server survives only at the edges, kept for the old programming models the integrated version refuses to run.

Conclusion

The internet transaction server is SAP’s long-running answer to a simple problem: SAP screens and web browsers do not speak the same language. It solved the problem first as a standalone server with its WGate and AGate gateways, then moved inside the application server with release 6.40 and stayed there. If you open SAP in a browser today and see a classic transaction looking back at you, the ITS did the translation, quietly, one screen at a time.