TH_WPINFO — Reading work process status via TH_WPINFO

TH_WPINFO reads the work process table of an application server instance and returns it to the caller in the same shape and content that SM50 or SM51 render on screen: process number, type, status, current user, report or transaction, and timing figures. It talks directly to the kernel/dispatcher interface rather than to an application table, so the data reflects the instance's live state at the moment of the call, not a persisted snapshot. It is not part of any released customer API contract; SAP does not guarantee interface stability across releases the way it does for a BAPI. In practice it is widely used inside Basis-written monitoring jobs, health-check scripts, and third-party monitoring tools that need work process load without opening SM50 manually, frequently invoked against a remote instance through an RFC destination rather than only locally.

Only the parameters that can be stated with confidence are described here in functional terms rather than by exact technical name, since the precise signature is not something to guess at for a page like this.

The exceptions on this function module map to failure to reach or read the target instance, not to business logic problems, and treating them as optional is where monitoring code goes wrong.

Resolve the target instance identifier first, either from the system's own instance list or from configuration, and decide whether the call is local or should go through an RFC destination pointing at that specific instance. Call the function module, check the return code and each exception explicitly rather than relying on a generic catch-all, and treat a non-zero return as a failed read, not as zero work processes. After a successful call, inspect the returned table for plausibility: an unexpectedly empty table on an instance known to be up is itself a signal worth logging, since it usually means the exception handling upstream discarded a real error. Do not call this in a tight polling loop across many instances without a minimum interval; each call has real cost on the dispatcher being queried.

The underlying kernel and dispatcher architecture that TH_WPINFO reads from is common to both ECC and S/4HANA, and the function module continues to exist and behave the same way on S/4HANA on-premise systems. It has not been published as a released, whitelisted API and is not appropriate to call from custom code in an S/4HANA Cloud, public edition system under clean-core rules. There is no announced customer-facing successor; current SAP monitoring direction for work process and instance health runs through the standard CCMS monitoring infrastructure and, at the landscape level, through dedicated monitoring products, rather than through a new function module replacing this one.

Most incidents involving this function module trace back to how its output is interpreted rather than to the function module misbehaving.

This sits squarely with the Basis or infrastructure team responsible for instance and work process monitoring. Application development teams should not be building business logic that depends on it, and any custom job that calls it should be documented and owned by whoever maintains the monitoring landscape, since it is the team that will be paged when the polling job itself starts failing.

TH_WPINFO is frequently paired with a simple reachability check against the target instance before the work process read is attempted, since a failed connectivity test explains an empty result far better than debugging the function module itself. It has no meaningful dependency on application-layer tables; its data source is the kernel's own in-memory work process table on the queried instance, not a database table.