A web-based alternative to SM50, SM37 and ST22

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 run across many SAP systems. This post describes what a web-based interface to those transactions looks like, what data actually sits behind SM50, and where a cross-system view earns its place. It is not an argument for retiring SAPGUI.

What SM50 actually shows

SM50 is a live view of the work processes of one application server. Each row is a process with a type and a state; understanding the columns is what makes the data useful whether you read it in SAPGUI, on the OS, or in a web console.

The state column is the other half: Running, Waiting (idle, ready), Hold (blocked on a resource such as a lock, a DB operation or a GUI roundtrip), Stopped (errored). A row that sits in Hold on a semaphore or in Running far past its historical norm is the one to look at first.

The same data, three ways

SM50 is not the only path to the work-process table. The same information is available from the OS and from sapcontrol, which is exactly what makes a web console possible without a SAPGUI session:

# On the host, as <sid>adm: the dispatcher monitor (live WP table)
dpmon pf=/usr/sap/<SID>/SYS/profile/<instance_profile>
#   menu 'l' lists work processes: No, Ty, Pid, Status, Cause, Start, ...

# Via sapstartsrv: no OS login, works remotely over the SOAP port
sapcontrol -nr <nr> -function GetProcessList        # instance processes
sapcontrol -nr <nr> -function ABAPGetWPTable        # the SM50 table itself
#   returns No, Typ, Pid, Status, Reason, Start, Err, Sem, CPU, Time,
#   Program, Client, User, Action, Table: the SM50 columns, as data

ABAPGetWPTable is the important one: it returns the SM50 work-process table as structured data over the same authenticated channel a collector already uses. That is the difference between "screen-scraping SAPGUI" and reading the same source SM50 reads.

What gets harder as the landscape grows

Client install and version drift

SAPGUI runs on every admin's workstation. As people change laptops or join the team, keeping SAPGUI versions consistent and SNC certificates current is recurring work. A browser interface removes that from the workstation entirely.

Per-system logons

Operating thirty systems through SAPGUI means thirty SAP Logon entries, thirty SNC negotiations, and several windows at once. "Which systems have a long-running DIA right now?" is answered one system at a time in SAPGUI; a view that already aggregates ABAPGetWPTable across systems answers it in one place.

Operator action records

Cancelling a stuck work process from SM50 leaves a trace in the Security Audit Log only if SAL is enabled and filtered for it, and SAL is a forensic record rather than an operations action log. Auditors increasingly want an attributed history of privileged Basis operations by operator, time and outcome, which is easier to provide from a tool that produces it as a byproduct of normal use.

What a web-based alternative usually covers

• One filterable table across systems: the SM50 columns (PID, type, status, user, report, client, CPU, time) filterable across every system the operator may see; the same idea for SM37 jobs and ST22 dumps.
• An action surface with audit by default: cancelling a WP or restarting an instance runs a server-side action that checks permissions, performs it against the host (e.g. sapcontrol ... RestartService, or a WP cancel), and writes an attributed record.
• Consolidated navigation: SM50, SM37, ST22, ST04, SM12, SM21, SM59 in one tree instead of the per-transaction window model.
• Push updates: SAPGUI's SM50 refreshes on F8; a streaming view stays current without input.

What it does not replace

SE38, SE80 and SAPGUI scripting are not part of this conversation. ABAP development belongs in SAP development tools, and an existing portfolio of GUI scripts keeps running where it 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

• A collector agent runs on each SAP host, outbound-only, as a dedicated user with scoped sudo to <sid>adm; it reads the work-process table via sapcontrol ABAPGetWPTable rather than scraping a GUI. 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

1. Ask to see one view across more than one SAP system. If the demo is per-system, the cross-system case is not really covered.
2. Ask how an operator action is recorded, and how you would retrieve that record months later.
3. Ask how SAP credentials are stored on the host running the agent. Plain text on disk is not adequate.
4. Ask which roles can read which data, and whether the role model is enforced server-side, not only in the UI.

The use cases page covers the persona-level framing, and the wider transaction set is on SAP Basis monitoring. To see this on one of your own systems, write to contact@farrenio.com and we can scope a short trial together.