SOST table — SAPconnect send request monitor

One line in the SOST monitor represents one send request handed to SAPconnect for outbound delivery, such as a workflow email, a background job spool sent as a fax, an EDI message, or an internal SAPoffice document routed externally. SOST itself has no persisted rows; the screen queries the send request status held by the SAPconnect kernel layer together with the job, spool, and application log entries generated while that request was processed, and presents them as one row per request. Because of this, a consultant cannot join to SOST in a report or a CDS view the way they would join to a real transparent table. Anything that needs to be proven for audit or reporting purposes has to be pulled from the underlying job, spool, and log tables that actually persist the data, using the send request's job name, spool number, or log number as the connecting key.

These are the columns shown on the SOST selection and list screens, not confirmed ABAP Dictionary field names, since no dictionary table backs the transaction.

Since SOST has no join key of its own, the joins that matter are between the underlying persistence tables used to reconstruct a send request's history. When a send is processed asynchronously it runs as a background job, so the job that executed the send links job header to job step through TBTCO-JOBNAME = TBTCP-JOBNAME, with TBTCS holding the step control data. When the output channel produces a spool object, for example a fax or a print-based send, the spool request and its device format link through TSP01-RQIDENT = TSP03-RQIDENT. Detailed error messages for a failed send are usually written to the application log, joined through BALHDR-LOGNUMBER = BALDAT-LOGNUMBER. If the send originated from a SAPoffice document, SOOD carries the object type and object ID that the workflow or report passed to SAPconnect in the first place.

The SOST selection screen is client-independent in the sense that send requests belong to the client the user is logged into, but it does not expose a client field for cross-client comparison the way a table maintenance screen would. Always restrict by date range and status before running the selection in a productive system; SAPconnect processes a high volume of small requests and an unrestricted 'all statuses, all dates' query on a busy mail-enabled system returns thousands of rows and is slow to render. When the underlying job, spool, or log tables are queried directly instead, the same rule applies: filter TBTCO/TBTCP by job name pattern and date, TSP01/TSP03 by creation date and requester, and BALHDR/BALDAT by log object and date, because none of these tables are selective without a date restriction.

Symptom: a user reports a fax or an outbound email never arrived. In SOST, select status Error or Incorrect for the relevant date range and find the request by recipient. If the entry shows a job reference, look it up in TBTCO by job name and date to confirm whether the job actually ran or is still scheduled. If the entry produced a spool object, check TSP01 for the spool request status and TSP03 for the device format actually used. If the row carries a log number, read BALHDR/BALDAT for the exact error text, since the SOST status column alone only says error, not why.

SOST continues to exist as a transaction in S/4HANA and SAPconnect remains the standard mechanism for outbound email, fax, and EDI dispatch from the ABAP stack. Because SOST was never a transparent table, there is no CDS compatibility view or table conversion associated with it. The tables it draws on for job, spool, and application log data continue to exist in S/4HANA in largely the same shape, though spool and print administration have been simplified in some areas of the newer stack.

Most SOST-related incidents come from treating the monitor as if it were a permanent audit table with fixed retention and a single authoritative status.

Basis owns the SAPconnect node configuration, the RFC destination to the mail or fax gateway, and the scheduling of the send jobs. The functional team that triggers the document, for example workflow or output determination, owns why the send was generated and with what content. Anything failing downstream of the gateway, such as SMTP relay rejection, belongs to the messaging or email infrastructure team outside SAP.

TBTCO, TBTCP, and TBTCS hold the background job that actually executes an asynchronous send. TSP01 and TSP03 hold the spool request generated when the output channel is print or fax. SOOD identifies the SAPoffice document object behind the send request. BALHDR and BALDAT hold the detailed error text behind a failed send. The transaction used to administer SAPconnect nodes and jobs alongside SOST is SCOT.