WE57 — Assign Message Type to IDoc Type and Object Type

WE57 maintains table EDIMSG, which links a message type, an IDoc basic type (and optionally an extension), an object type, and the function module or BAPI wrapper used to post it inbound. The one structural fact that causes most confusion: the assignment is keyed on the specific extension, not just the basic type. An entry that works fine for the base IDoc type ORDERS05 with no extension does not automatically cover a customer extension of the same basic type. Each extension used inbound needs its own registered line, or the system has nothing to validate against and refuses to process the IDoc, even though every other configuration piece (partner profile, process code, segment definition) is correct.

WE57 is reached for almost exclusively during troubleshooting or setup of inbound IDoc processing, not during routine operation. It comes up when a new inbound interface is built around a custom IDoc extension, when an existing interface is cloned to a new message type, or when an inbound IDoc sits in status 56 with an error referencing an unregistered message type / object type combination. In a BTP integration landscape it surfaces mainly on legacy IDoc-based flows still running through the classic IDoc adapter into an on-premise system behind Cloud Integration or a middleware layer, rather than on newer OData or event-based interfaces where this table plays no role at all.

Run SE16 on EDIMSG and filter on the message type from the failing IDoc. Compare the IDOCTP and extension (CIMTYP) columns against the control record of the failing IDoc in EDIDC for the same message type. If no row matches the exact basic type plus extension combination, the assignment is missing regardless of what WE20 or WE42 show. Cross-check the function module named in the EDIMSG row against the one referenced in the inbound process code to rule out a stale or renamed function module.

The EDIMSG mechanism and the WE57 transaction are unchanged on S/4HANA; this is core IDoc/ALE plumbing that was not touched by the Fiori migration. There is no Fiori app for this maintenance activity because it is a technical configuration table, not a business transaction. On S/4HANA the practical shift is that fewer new interfaces are built on IDoc extensions in the first place, so WE57 maintenance is increasingly confined to legacy flows being kept alive rather than greenfield development.

This is technical integration configuration, typically owned jointly by an ABAP or interface developer and a functional consultant who understands which object type the inbound data should land against. A good handover states the message type, the exact IDoc type and extension involved, the object type expected, and whether the fix is a new EDIMSG entry or a correction to an existing conflicting one, plus the transport request it travels in.

WE20 and WE42 are the natural companions: WE20 confirms the partner profile actually references the IDoc type and extension in question, and WE42 confirms the inbound process code and function module chain. WE19 is the practical test tool for re-firing a corrected IDoc without waiting for the source system to resend. For interfaces routed through a middleware layer, SXMB_MONI helps confirm whether the failure originates before the IDoc even reaches the EDIMSG check or after, which narrows down whether the fix belongs in WE57 or further upstream.