CALL_FUNCTION_CONFLICT_LENG — CALL_FUNCTION_CONFLICT_LENG runtime error

This dump belongs to the CALL_FUNCTION family of runtime errors, all raised by the kernel's dispatch logic when a CALL FUNCTION statement cannot be executed as coded. CONFLICT_LENG specifically means the kernel compared the length of a parameter value being passed against the length the function module's generated interface expects, and found a mismatch. This is not a data-content problem and not a type mismatch (that would be CALL_FUNCTION_CONFLICT_TYPE) - it is purely about byte length. It typically surfaces on RFC-enabled function modules called across a system boundary, where the caller's idea of the interface and the callee's actual interface have diverged because one side holds an older or newer version of the DDIC structure involved. It can also occur within a single system if a generated function group interface is stale relative to the current active version.

If the cause is a cross-system release or support package gap, the fix is to align the structure definition across the systems involved - either transport the corrected structure to the lagging system or roll back the change until both sides can be updated together; this requires a change request and coordination with the team owning the other system. If the cause is a stale generated interface within one system, regenerate the function group (or the affected programs) after the structure transport lands; no code change is needed, but a regeneration step should be added to the transport sequence. If an external non-ABAP caller is involved, the fix sits with whoever owns that client: their stub or copybook needs to be regenerated against the current interface, which is a change request on their side, not on the ABAP side. If a custom Z structure was changed informally, the long-term fix is to formalize it as a versioned interface object and only ever extend it (never shorten or reorder fields) so old callers stay compatible; this needs a change request plus a review of every caller of that structure.

The reflex fix is to change the length of the local variable or structure in the calling program until it matches whatever the dump reports, without asking why the two sides disagree. This makes the dump disappear but usually just moves the truncation somewhere less visible - fields get silently cut or padded, and the next failure shows up as a CONVT dump, a wrong value in a downstream posting, or a reconciliation break days later. Another common mistake is wrapping the call in a TRY block expecting a catchable exception; this is a raw runtime error at the kernel level, not a class-based exception, and wrapping it does not prevent the termination.

Treat any DDIC structure used in an RFC-enabled function module interface as a public contract: extend it only by appending new fields, never by changing or removing existing ones, and never resize an existing field without a coordinated release across every calling system. After any transport that touches such a structure, regenerate the function group and confirm the interface is active on every system that calls it, not just the one where the change was made. In multi-system landscapes, keep a periodic comparison of shared interface structures between systems rather than discovering drift through a dump in production.

Primarily an ABAP development issue; Basis gets involved when the mismatch is between systems at different support package levels and a landscape-level fix or transport sequencing decision is needed. The handover note should name the function module, the specific parameter and structure, the systems and release levels compared, and which side (ABAP program, ABAP interface, or external client stub) needs the length correction.

Sits alongside CALL_FUNCTION_CONFLICT_TYPE (same family, type mismatch instead of length), CALL_FUNCTION_PARM_MISSING (a required parameter absent rather than wrong length), and CALL_FUNCTION_REMOTE_ERROR (the callee itself failed rather than the interface being wrong). Commonly involves SE37 function module maintenance, SE11 structure definitions, SM59 RFC destinations, and transport tables tracked through SE01/SE10 when the root cause is a structure change that has not reached every system.