Customizing Steps To Make IDocs Work

Before you can send or receive IDocs, there is some customizing work to be done. This defines the processing chains and tells R/3 how messages are processed and how to find the target.

SM31 View-Maintenance Table EDMSG: Define Message Type

Add The New Message Type To Table EDMSG

WEDI -> Maintain Message Type SM31 --> Table Maintenance	The table is maintained as the primary lookup table for all valid message type. Any valid message type must be seen in there.
	It is a maintainence view on table EDMSG.

SM30 Maintenance Table EDIMSG: Define Combinations IDoc Type and Messages

Register Valid Combination Of IDoc and Message Types

WEDI -> Develop -> Maintain IDoc Type SM30 --> View Maintenance	The table registers which message type may go with a certain IDoc type. It is primarily used as lookup and valdation whether sent or received data is consistent. The entries in this table must be maintained because most transaction involving IDocs would cross-check any user entry for validity.
	It is a maintainence view on table EDIMSG.

Allocate function module to logical message

WEDI --> Develop -> Allocate function module to logical message	The table registers which message type may go with a certain IDoc type. It is primarily used as lookup and valdation whether sent or received data is consistent. The entries in this table must be maintained because most transaction involving IDocs would cross-check any user entry for validity.
	It is a maintainence view on table EDIFCT..
	Assigns the function module to process a message/IDoc-typecombination.

Define

WEDI -> Develop ->	The table registers which message type may go with a certain IDoc type. It is primarily used as lookup and valdation whether sent or received data is consistent. The entries in this table must be maintained because most transaction involving IDocs would cross-check any user entry for validity.
	It is a maintainence view on table TBD51.
	This is the registration panel for a standard IDoc input function. All routines who require standard IDoc processing (i.e. using the standard automated IDoc process workflow) rely on a function module to be registered in TBD51. The documentation for the TBD51 contain also the description of the required interface structure of a standard IDoc input function.

Maintaining process codes (inbound)

WEDI -> Develop -> Process codes	This assigns a workflow object to the incoming message pack. There are several alternatives which may be triggered by an IDoc. However, the usual procedure would be to input the IDoc via a function module. This steps assigns the actual input process to a logical input method as defined the step below.
	It is a maintainence view on table TBD52 Step 1
	Step 2
	Step 3

Define and Assign A Logical Input Method

WEDI -> Develop -> Process codes	The logical message is a key name for the workflow process to determine the subsequent step after receiving an IDoc. Every IDoc processing arrives in an intermediate step at a process code. The process code is linked to the actual input method.
	It is a maintainence view on table TEDE2.
	Though it appears as an unnecessary intermediate step, it provides a convenient shim to physically decouple the arriving IDoc from the processing method. This allows to replace quickly and dynamically the actually process workflow.

SM31 View Maintenance Table CDP21: Input Partner Profile

SM31 View Maintenance Table ???: Port Definition

SALE - Customize ALE functions

If you want to use the IDocs in combination with automated ALE processing (transaction BALE or change pointers), then you have to maintain the distribution module for ALE with transaction ALE.