CONNE_IMPORT_WRONG_OBJECT_TYPE¶

The type of an IMPORTING parameter from a remote call does not match the declaration in the caller.

During an RFC call, the remote system returned a parameter whose type or structure does not match what the calling program declared in its IMPORTING clause.

Symptom¶

ST22 shows:

Runtime Errors         CONNE_IMPORT_WRONG_OBJECT_TYPE
Short text             Wrong object type for import parameter.

The dump names the parameter and the source/target types in the "Variables in memory" section.

Cause¶

Root cause	Details
FM parameter type changed	Remote FM's EXPORTING parameter type was updated but the calling program was not
Cross-release type drift	Caller and remote system are on different support package levels
Structure extended	Remote structure gained new fields; local structure is the old version
Transport timing	Newer FM was transported to target before the updated calling program

Reproduce¶

To reproduce this locally, define two versions of the same structure — one "old" (as the caller expects) and one "new" (as the remote FM now returns):

" Simulate the mismatch:
" Remote FM now exports EV_DATA as ZMY_NEW_STRUCT (with extra field)
" but our local code still declares it as ZMY_OLD_STRUCT (without that field)

" Old structure (what we have locally)
TYPES: BEGIN OF ty_old_struct,
         matnr TYPE matnr,
         menge TYPE menge_d,
       END OF ty_old_struct.

" New structure (what the remote FM now returns — has an extra field)
TYPES: BEGIN OF ty_new_struct,
         matnr  TYPE matnr,
         menge  TYPE menge_d,
         werks  TYPE werks_d,   " new field added in remote system
       END OF ty_new_struct.

DATA ls_old TYPE ty_old_struct.

" In a real scenario this would be a remote call:
" CALL FUNCTION 'Z_GET_DATA' DESTINATION 'SYSTEM_B'
"   IMPORTING ev_data = ls_old   " <-- type mismatch → CONNE_IMPORT_WRONG_OBJECT_TYPE

Fix¶

Step 1 — Identify the mismatched parameter from ST22 Note the parameter name and the expected vs actual types shown in the dump.

Step 2 — Check the remote FM signature In the target system, open SE37, find the function module, and check the EXPORTING parameters tab for the current type.

Step 3 — Update the local structure and calling program

" Transport the updated structure from the remote system first (SE11 → add to TR → import)
" Then update the calling program to use the new type:

TYPES: BEGIN OF ty_new_struct,
         matnr TYPE matnr,
         menge TYPE menge_d,
         werks TYPE werks_d,   " aligned with remote FM
       END OF ty_new_struct.

DATA: ls_data TYPE ty_new_struct,
      lv_msg  TYPE c LENGTH 200.

CALL FUNCTION 'Z_GET_DATA'
  DESTINATION 'SYSTEM_B'
  IMPORTING
    ev_data = ls_data             " now matches remote FM signature
  EXCEPTIONS
    communication_failure = 1 MESSAGE lv_msg
    system_failure        = 2 MESSAGE lv_msg
    OTHERS                = 3.

IF sy-subrc = 0.
  WRITE: / ls_data-matnr, ls_data-menge, ls_data-werks.
ELSE.
  MESSAGE lv_msg TYPE 'E'.
ENDIF.

Step 4 — Synchronise type definitions If the type is defined in the remote system, transport it to the local system via SE11 so both sides share the same definition.

Use TABLES parameters for cross-release compatibility

For long-lived RFC interfaces that may evolve, consider using a generic TABLES parameter with string-encoded data rather than typed structures. The overhead is worth avoiding type drift between systems.

Prevention¶

When changing an RFC-enabled FM's parameter types, update all calling programs in the same transport cycle.
After any support package application that changes DDIC types, run a where-used check on affected structures.
Always specify COMMUNICATION_FAILURE and SYSTEM_FAILURE in remote FM calls — they help distinguish connection errors from type errors.

CONNE_IMPORT_WRONG_OBJECT_TYPE¶

Symptom¶

Cause¶

Reproduce¶

Fix¶

Prevention¶

See also¶

Comments