SOST — SAPconnect Send Request Monitor

SOST displays the queue of send requests that have passed through the SAPconnect framework, which is the generic dispatcher SAP uses to hand outbound communication to external channels: SMTP for email, fax gateways, SMS gateways, and in older setups X.400 or RML print. The one structural fact that explains most confusion is that SOST does not send anything itself. It only reports what SAPconnect has recorded. A document can look perfectly fine in the application (an output form, a workflow step, a background job) and still never reach SOST at all, because it failed before it was ever handed to SAPconnect, or it can sit in SOST forever in a waiting state because the SMTP node it depends on is stopped, misrouted, or has no free processing slot.

Reached for whenever a business user or process owner says an email, fax, or automated notification 'never arrived' but the sending application (output determination, workflow, ABAP send via class-based mail API, IDoc-to-email mapping) reported success. It sits downstream of the business transaction and upstream of the actual mail relay or fax modem, so it is the natural midpoint check: did the request even leave the sending program, and if so, did SAPconnect manage to hand it off. It is not the tool for checking whether the recipient's mail server accepted or bounced the message; that is visible only in the header detail or, for deeper SMTP-level tracing, requires looking at the node configuration in SCOT and the ICM or gateway logs.

In SE16, checking the send request's recipient-level status is the fastest confirmation: look at the status field on the recipient record tied to the document ID shown in SOST detail, and cross-check the timestamp against when the sending application actually created the document. If the document ID exists but no status record was ever written, the request died before SAPconnect processed it, pointing back to the sending program rather than SAPconnect. A gap between creation timestamp and any status update longer than the normal job cycle indicates the SAPconnect scheduler was not running in that window.

SOST and the underlying SAPconnect framework work the same way on S/4HANA as on ECC; there is no structural change to how send requests are queued or monitored. Fiori does not replace SOST with a dedicated app for this monitoring function, so consultants on S/4HANA still use the classic transaction for send request troubleshooting. Configuration of nodes and job scheduling remains in SCOT.

Primarily a Basis problem once a send request is confirmed stuck or erroring inside SAPconnect, since node configuration, job scheduling, and SMTP connectivity are infrastructure concerns. Functional teams own it up to the point of confirming the document was correctly generated and handed off. A good handover includes the document ID, the exact SOST status and error text, the timestamp, and confirmation of whether the same failure is isolated or affecting a batch.

SCOT is the natural next stop, since it holds the node configuration and job scheduling that SOST failures usually trace back to. SP01 is useful when the underlying output is a print or fax request routed through spool before reaching SAPconnect. SICF matters when the outbound channel is HTTP-based rather than SMTP. SLG1 is worth checking for application-level errors logged by the sending program before the document ever reached SAPconnect.