RFC Destination Connection Test Failure

Reported as an interface that stopped overnight rather than as an RFC problem. Typical phrasing: the nightly order file did not arrive at the warehouse, the pricing update job in the cloud system never picked up the batch, or a Fiori app on BTP shows a generic communication error when it tries to call the backend. Nobody mentions SM59 at first. The connection worked yesterday and nobody changed anything, according to whoever raises the ticket. By the time it reaches the integration team it has usually already been escalated as a business outage, with the underlying detail being that the scheduled job, IDoc dispatch, or OData call is failing at the connectivity layer before it ever reaches application logic.

Pull the exact error text from the SM59 connection test alongside the system log entries in SM21 for the same timestamp, then compare that timestamp against the communication user's last password change date in SU01 or the certificate expiry date in STRUST. A failure that starts precisely at a password expiry or certificate expiry timestamp is proof of cause, not coincidence, and settles the argument about whether it is a network problem before the network team is engaged unnecessarily.

If the cause is a locked or expired communication user, unlock and reset the password directly in SU01; this is a data fix in the target client, has no transport, and takes effect immediately. If the cause is an expired or mismatched certificate, renew the PSE in STRUST and re-exchange the public certificates between both sides; this is done directly per system and is not transportable, but both ends must be updated together or the fix will not hold. If the cause is a Cloud Connector problem, restart the connector or correct the virtual host mapping and ACL entry in the BTP cockpit and Cloud Connector administration; this is a BTP-side configuration change, not an ABAP transport. If the cause is a gateway ACL block, add the required entry to secinfo or reginfo and reload the gateway; this is a Basis security change that should go through the same controlled process as any other ACL edit, since a careless entry re-opens a security gap. If the cause is network-level, raise a ticket to the network or firewall team with the specific host, port and timestamp; there is no application-side fix.

The reflex is to delete and recreate the RFC destination, or to copy the connection parameters from a similar destination that still works. This sometimes appears to fix it, because recreating the destination resets cached logon data, but it does not address a locked user, an expired certificate, or a gateway ACL entry, so the failure returns within a day or after the next password rotation. It also loses any custom settings on the original destination, such as a specific logon group or trace level, that someone will have to reconstruct later.

Basis or the integration/connectivity team owns the destination itself; the BTP administrator owns the Cloud Connector side when one is involved. The handover note should carry the destination name, target system and client, the exact SM59 error text, the certificate or user expiry date if that was the cause, and confirmation of whether the fix was a data change (user unlock, certificate renewal) or a config change requiring gateway restart or ACL update.