CALL_FUNCTION_SEND_ERROR — CALL_FUNCTION_SEND_ERROR dump diagnosis and fix

This dump belongs to the CALL_FUNCTION exception family raised by the RFC/CPIC communication layer, not by ABAP application logic. It means the CALL FUNCTION ... DESTINATION statement got far enough to open a connection but the send of the request data failed before the target system could process it. This is different from CALL_FUNCTION_REMOTE_ERROR, where the call reached the other side and an error came back from execution there. SEND_ERROR is a transport-layer failure: the packet never arrived intact, or arrived but the receiving work process was gone, or the gateway rejected the connection outright. The calling program is almost always innocent; the dump usually indicates something wrong between the sending application server and the target system's gateway or dispatcher, or a target system that terminated mid-transaction.

If the target system was down or restarting at the time, this is transient: confirm with Basis that the instance is now up, retest via SM59, and rerun the failed job. No change request needed. If the gateway connection limit was hit, Basis needs to raise the relevant gateway parameter or find and close the process leaking connections; this is a Basis parameter change requiring a change request if it touches production gateway configuration. If a firewall or saprouter dropped the session, network/Basis must adjust the idle timeout or add a keepalive setting on the affected route; this typically needs infrastructure sign-off and a change request since it affects shared network equipment. If the receiving work process crashed, the fix lives in whatever caused that crash on the target side, found via its own ST22, not in the calling program. If payload size is the driver, the ABAP side should split the call into chunks or move to a different transfer method (IDoc, file, or asynchronous RFC), which is a code change requiring proper testing and a change request. If the destination itself is misconfigured, correcting SM59 is a Basis or Basis-security task, low risk, but still change-managed in production landscapes.

The reflex is to wrap the CALL FUNCTION in a bigger TRY/CATCH or add COMMUNICATION_FAILURE and SYSTEM_FAILURE to the EXCEPTIONS list and move on once the dump stops appearing. This suppresses the visible symptom but leaves the underlying network flakiness or gateway exhaustion untouched, so the interface now fails silently or retries into the same wall, and whoever depended on that data never finds out it did not arrive. Blindly increasing the RFC timeout has the same problem: it papers over a connection that drops for reasons unrelated to how long the caller is willing to wait.

Add explicit EXCEPTIONS handling for COMMUNICATION_FAILURE and SYSTEM_FAILURE on every outbound synchronous RFC call so a failure produces a controlled error message and, where appropriate, a retry with backoff instead of an uncaught dump. For high-volume interfaces, monitor gateway connection counts and set alerting before the configured maximum is approached. Keep RFC destinations under regular connection testing (scheduled SM59 test or equivalent monitoring) so a dead target is caught before a business job hits it.

Primarily Basis: network path, gateway capacity, and target system availability are infrastructure concerns. ABAP gets involved only if the calling program lacks proper exception handling or needs restructuring for large payloads. The handover note should include the RFC destination name, target host and system number, the exact timestamp, and whether the target system's own logs show a corresponding crash or restart.

Closely related to CALL_FUNCTION_REMOTE_ERROR, which fires when the call reaches the target but execution there fails, and CALL_FUNCTION_NOT_FOUND, which indicates the function module itself is missing on the target. A TIME_OUT dump can appear instead of SEND_ERROR when the same network delay is interpreted as an RFC timeout rather than a hard connection break. Tables and transactions involved include the RFC destination configuration, SM59, SMGW on both systems, and SM21 system logs.