Internet Transaction Server: SAP ITS Explained

Written by Ahmad Jajja · Reviewed by Danish Mustafa · August 5, 2026

In the late 1990s, a company that ran SAP, which is business software for finance, logistics, and human resources, faced a simple distribution problem. Every employee who needed SAP had to install the SAP client program, called the SAP GUI, on their own computer, and the IT team had to install, update, and support that program on hundreds or thousands of machines. Partners and customers who needed occasional access faced an even harder path, because installing company software on outside computers was slow, fragile, and often blocked by the partner's own IT rules. Teams needed a way to reach SAP through a tool everyone already had: a web browser.

The SAP Internet Transaction Server, usually called SAP ITS or simply ITS, answered that need. ITS sat between the browser and the SAP system and translated between the two worlds. It took an SAP transaction, which is a screen based business task inside SAP, such as creating a sales order or checking stock, and turned that screen into an HTML page, which is the markup a browser renders as a visible page. The user worked in the browser, clicked buttons, and filled fields, while ITS carried each action back to SAP and returned the next screen as a new page. No SAP software lived on the user's computer, and the IT team maintained one gateway instead of thousands of installs.

This guide explains ITS in plain language: what it was, how a request flowed through it, how templates shaped its pages, what its limits were, and what replaced it. It also gives an honest status note up front, because ITS history matters for anyone who still sees the name in an old system: standalone ITS is discontinued as a separate product, and modern SAP web work uses different approaches. SAP documents NetWeaver, the platform that absorbed ITS, and SAP describes its current technology platform for new web work. Our guide to enterprise integration explains how systems connect today, and our custom software work helps teams move old web gateways to modern apps.

What SAP ITS Actually Was

ITS was a gateway, which means a program that sits between two systems and translates requests in both directions. On one side, it spoke HTTP, which is the protocol, or set of rules, that browsers and web servers use to exchange pages. On the other side, it spoke the SAP protocol that drives SAP transactions, including the flow of screens, fields, and user actions that SAP GUI users knew. When a user opened an ITS address, ITS asked SAP to start the requested transaction, received the first screen definition, converted the fields and buttons into HTML, and sent the page to the browser. Each click or form submission traveled back through ITS to SAP, which advanced the transaction and returned the next screen.

That design preserved SAP logic exactly, because the logic never left SAP. ITS did not reimplement business rules in web code, and it did not copy SAP data into a separate web database. It presented SAP screens through the web, so a sales order created through ITS followed the same checks, the same approvals, and the same posting rules as an order created through SAP GUI. That fidelity, which means faithfulness to the original behavior, was ITS's main strength. A company could open a proven SAP process to new users without rebuilding the process, and auditors could trust that web orders and desktop orders followed identical rules.

ITS also served two audiences that SAP GUI served poorly. Occasional users, such as managers who approved expenses once a week, could work through a browser without learning a heavy desktop client. External users, such as suppliers checking order status or customers entering orders, could reach a controlled slice of SAP without installing company software. Administrators controlled which transactions each audience could open, so a supplier saw order status screens but never finance screens. That controlled, browser based reach was new at the time, and it shaped how companies thought about opening core systems to the web.

How a Request Flowed Through ITS

Follow one user action to see the flow clearly. A warehouse clerk opens a browser, types the ITS address for a stock check transaction, and logs in. ITS receives the HTTP request, starts a session, which is a tracked conversation between the browser and the server that remembers who the user is across pages, and asks SAP to run the transaction under that user's SAP account. SAP returns the first screen, with fields for material number and plant, which is a factory or warehouse location in SAP terms. ITS converts that screen into HTML using a template, which is a page pattern that maps SAP fields to web controls, and sends the page to the browser.

The clerk types a material number and clicks Search. The browser sends the form data to ITS, which translates the fields back into SAP input, sends the action to SAP, and waits for the next screen. SAP runs the stock check, returns a list screen, and ITS converts the list into an HTML table. The clerk sees stock levels without ever knowing that a mainframe style transaction, which means a screen driven business program, produced the page. Each round trip repeats that pattern: browser to ITS, ITS to SAP, SAP to ITS, ITS to browser. The user experiences a website, while SAP experiences an ordinary transaction session.

State management, which means remembering where the user is in a multi screen task, made this flow delicate. Web pages are naturally stateless, which means each request stands alone unless the server remembers context, while SAP transactions are stateful, which means each screen depends on earlier screens in the same session. ITS bridged that gap by holding the SAP session open between browser requests and tying it to the browser session. If the browser session timed out, or the network dropped, the SAP session could hang or lose its place, and the user had to start again. Teams learned to set timeouts carefully and to design ITS transactions with short, simple flows that survived interruptions.

Architecture: The Parts Around ITS

A full ITS setup held several parts, and each part owned one job. The web server received browser requests and passed them to ITS. The ITS server itself, sometimes called the ITS engine, ran the translation, held sessions, and talked to SAP through SAP's communication interface. The SAP application server ran the transactions, enforced business rules, and guarded the data. Templates and style files lived on or near the ITS server, shaping how each SAP screen appeared as a page. A load balancer, which spreads incoming requests across several servers, could sit in front of several ITS servers, so many users could work at once without overloading one gateway.

That split gave teams flexibility and a clear scaling path. A company could add ITS servers as browser usage grew, without adding SAP application servers at the same rate, because ITS servers handled presentation while SAP servers handled business work. It also gave teams a security boundary: browsers talked only to the web and ITS tier, never directly to SAP application servers, and firewall rules, which are network rules that allow or block traffic, enforced that boundary. An attacker who reached the web tier still faced SAP login and authorization checks, which decide what a given user may do, before touching business data.

The architecture also carried a cost that teams felt over time. Every layer added latency, which is the delay between a user action and the visible result, because each click traveled through browser, web server, ITS, and SAP, then back again. Every layer added a place to configure, monitor, and patch. When a page looked wrong, the team had to decide whether the template, the ITS engine, the network, or the SAP transaction caused it, and that diagnosis took skill in both web and SAP worlds. Companies that ran ITS well staffed it with people who understood both sides, and companies that treated it as a simple web server struggled with exactly those cross layer problems.

Templates: How Screens Became Pages

Templates decided what users actually saw, and they deserve a close look. A template mapped SAP screen elements to HTML controls: an SAP input field became a text box, an SAP table became an HTML table, and SAP buttons became web buttons. Designers could add company logos, colors, navigation, and help text around the converted fields, so an ITS page looked like a company website rather than a raw SAP screen. That styling freedom mattered for external users, who judged the company by the page they saw, not by the SAP logic behind it.

Templates also carried limits that shaped every ITS project. A template described one transaction screen, so a transaction with many screens needed many templates, and a change to the SAP screen, such as a new required field, could break the template until a designer updated it. Testing therefore covered two layers: the SAP transaction itself, and the template rendering of each screen, on the browsers the company supported. Teams that skipped template testing shipped pages where a field sat off screen, a button did nothing, or a required value never reached SAP, and users blamed SAP for what was really a web presentation bug.

Skilled ITS teams treated templates as code, with version control, which tracks changes over time and lets teams recover earlier versions, and with a test pass on every SAP change. They kept templates simple, avoided clever scripts inside pages, and tested with realistic data, including long product names, special characters, and empty results. That discipline kept ITS pages reliable, but it also showed the model's ceiling: every SAP screen change rippled into web work, so the web layer never truly separated from the SAP screens it presented. Modern web apps break that coupling by calling APIs instead of converting screens, which is a central reason ITS gave way to newer approaches.

Security and Access Control in ITS

Security in ITS started with SAP's own checks, which was a strength. A browser user logged in with an SAP user account, and SAP authorization objects, which are fine grained permissions tied to business actions, decided which transactions and which data that user could touch. ITS did not invent a second permission system. It carried the user's identity into SAP and let SAP enforce the rules it already enforced for desktop users. That single source of permission truth kept web and desktop access consistent, and it let auditors review one set of rules for both channels.

Teams still had to secure the web layers themselves. ITS addresses needed transport encryption, which scrambles data in transit so outsiders cannot read it, and the web tier needed protection against common web attacks, such as crafted input that tries to run code or steal a session. Session handling needed care: an ITS session left open on a shared computer could let the next person continue the previous user's SAP work, so timeouts, logout buttons, and warnings on shared machines mattered. Public facing ITS pages needed extra review, because every field on a public page was an invitation for probing, and a page that exposed internal error details could teach an attacker how the system worked.

Access design also mattered. The safest ITS setups exposed only the transactions each audience needed, and nothing else. A customer portal exposed order entry and order status, not finance or payroll. A supplier portal exposed delivery schedules, not pricing internals. Teams reviewed the exposed list regularly, because a transaction added for one project often stayed exposed long after the project ended, quietly widening the surface. Our guide to safe test spaces explains how to test such gateways without exposing live data, and support and maintenance work covers the reviews that keep old gateways safe.

What Replaced Standalone ITS

Standalone ITS ended as a separate product because SAP folded its job into the platform itself. SAP NetWeaver, which is SAP's technology platform for building and running business applications, gained integrated ITS, which runs the same screen conversion inside the NetWeaver stack instead of on a separate gateway server. Companies with existing ITS applications could move them to integrated ITS without rebuilding every template, which softened the transition. For new work, though, SAP and its customers moved toward different patterns entirely, and integrated ITS became a bridge for legacy screens rather than a foundation for new apps.

The newer patterns start from APIs and purpose built apps. Instead of converting an SAP screen into a page, a modern app calls an API to fetch exactly the data it needs, and it presents that data in an interface designed for the task, the device, and the user. A warehouse worker gets a mobile app with big buttons and barcode scanning, not a converted desktop screen squeezed onto a phone. A customer gets a checkout flow designed for the web, not a repurposed internal transaction. APIs also let non SAP systems join the flow, so a web store, a logistics partner, and SAP can share data without any of them presenting another system's screens.

SAP Fiori, which is SAP's design approach for role based, modern web apps, represents that shift most clearly. Fiori apps target one role and one task, such as approving leave requests or checking inventory, and they run in a browser or on a mobile device with a clean, consistent design. They call SAP services through APIs, rather than converting transactions, so the interface and the business logic evolve separately. A team that still runs ITS screens should treat Fiori style apps and APIs as the long term direction, and treat integrated ITS as the way to keep old screens running while the team migrates task by task, not as a permanent home for new work. Teams building that kind of modern web app often use website development skills, since the replacement is a browser app rather than a converted transaction screen.

Moving Off ITS: A Practical Checklist

A team that still runs ITS should start with an inventory, not a rewrite. List every ITS transaction in use, who uses it, how often, and what business outcome it serves. Many ITS estates hold surprises: transactions nobody uses anymore, transactions duplicated by newer apps, and transactions used by one external partner through an undocumented address. Rank the list by business value and by risk, and retire the unused entries first, because every retired screen shrinks the surface the team must secure and maintain. Keep the inventory in a place the whole team can see, and update it when a new ITS address appears.

Next, map each live transaction to its replacement path. A simple inquiry screen may map to a standard Fiori app or a small API based page. A complex order entry flow may need a purpose built app with its own testing. A partner integration may map to an API exchange with no screens at all. For each mapping, note the SAP data it touches, the authorization rules it needs, and the test cases that prove the replacement matches the old behavior. That mapping turns a vague "migrate off ITS" goal into a sequenced project with testable steps, and it lets the business approve one replacement at a time instead of betting on a single big switch.

Finally, run old and new side by side during each cutover, and keep a rollback plan, which is a tested way to return to the old path if the new one fails. Compare outputs between ITS and the replacement for the same inputs, watch logs for errors the new app hides, and train users on the new screens before the old address closes. Close the old ITS address only after the replacement has run cleanly for a full business cycle, such as a month end close, because month end reveals cases that daily use hides. A migration that respects that discipline costs more planning and far less panic, and it leaves the team with modern apps instead of a new generation of screen conversions.

Conclusion

The Internet Transaction Server gave SAP a browser front door at a time when every user needed installed client software. It translated SAP transactions into web pages, preserved SAP business rules exactly, and opened core processes to occasional and external users without a desktop rollout. Standalone ITS is discontinued, integrated ITS inside NetWeaver carries its legacy screens, and modern work belongs to APIs and purpose built web and mobile apps. Teams that still run ITS should inventory every exposed transaction, map each one to a modern replacement, and migrate task by task with side by side testing. ITS deserves respect as a bridge technology, and bridges deserve a plan for what comes after them.

Frequently Asked Questions

Relevant blogs

Back to all blog guides · Back to Software Development guides · Explore Custom Software Development Services