A web-based alternative to SM50, SM37 and ST22
Why operating SAP through SAPGUI gets expensive across many SIDs, what a web-native alternative covers, and what to look for in one.
SAPGUI is still the canonical interface for SM50, SM37, ST22 and the rest of the Basis transaction set. There is nothing wrong with the transactions themselves. The question is whether the workflow around them still fits how operations work across multiple SAP systems.
This post describes what a web-based interface to those transactions looks like and where it adds value. It is not an argument for replacing SAPGUI entirely.
What gets harder as the landscape grows
A few areas where the SAPGUI-only workflow tends to cost more time as the number of systems and operators grows.
Client install and version drift
SAPGUI runs on every Basis admin's workstation. As people change laptops, switch operating systems, or join the team, keeping SAPGUI versions consistent and SNC certificates current is a recurring task. A browser-based interface removes that maintenance from the workstation.
Per-system logons
Operating thirty SAP systems through SAPGUI means thirty SAP Logon entries, thirty SNC negotiations, and several windows open at once. Switching between systems and between transactions is mechanical work that accumulates over a shift.
Cross-system views
"Which systems have a long-running dialog work process right now" is a useful operational question. SAPGUI answers it one system at a time. A central view that already aggregates work-process data answers it in one place.
Operator action records
Killing a stuck work process from SM50 leaves a record in the Security Audit Log if SAL is enabled and filtered for it. SAL is a forensic record, not an operations-friendly action log. Auditors increasingly ask for an attributed action history of privileged Basis operations, by operator, time and outcome, and that is easier to provide from a tool that produces it as a side effect of normal use.
What a web-based alternative usually covers
One filterable view across systems
SM50 reimagined as a table with columns for process ID, type, status, user, report, client, CPU and elapsed time, filterable across every system the operator is allowed to see. The same idea applies to SM37 background jobs and to ST22 dumps.
Action surface with audit by default
Killing a work process or restarting an instance happens through a server-side action that checks the operator's permissions, performs the operation against the SAP host, and writes an attributed audit record. The auditor sees who did what, against which system, when, and what happened.
A consolidated navigation
SM50, SM37, ST22, ST04, SM12, SM21, SM59 and a few related transactions in a single navigation tree. Reduces the per-task switching that SAPGUI's per-transaction window model requires.
Push updates
SAPGUI's SM50 refreshes when you press F8. A web tool that streams updates keeps the screen current without operator input.
What it does not replace
SE38, SE80 and SAP GUI scripting are not part of this conversation. ABAP development belongs in SAP development tools. If your team has a portfolio of GUI scripts for batch operations, those continue to run where they always did.
There is also a long tail of one-off forensic transactions where SAPGUI remains the right answer. A web tool is meant to cover the high-volume daily work, not every edge case.
How Farrenio approaches this
The use cases page covers the persona-level framing. Technically:
- A collector agent runs on each SAP host. It is outbound-only and runs as a dedicated user with scoped sudo to the SAP <sid>adm account. Security details.
- Platform-side aggregation feeds a web console with cross-system views and live updates.
- Every privileged action goes through a server-side permission check and is recorded with operator, IP, target and outcome.
What to look for when evaluating
- Ask to see a single view across more than one SAP system. If the demo is per-system, the cross-system case is not really covered.
- Ask how an operator action gets recorded and how you would retrieve that record some months later.
- Ask how credentials are stored on the host that runs the agent or collector. Plain text on disk is not adequate.
- Ask which roles can read which data, and whether the role model is enforced server-side rather than only in the UI.
If you want to see this on one of your own systems, write to contact@farrenio.com and we can scope a short trial together.
Run Farrenio against your own SIDs.
14-day sandbox tenant. No card. Real data.