ALE uses IDocs as the data transport mechanism. The ALE layer manages the routing, control, and monitoring of these IDocs between systems. The configuration involves three main components:

1. Logical Systems: Unique identifiers for each SAP system in the landscape.

2. Distribution Model (BD64): Defines which message types should be sent from which system to which receiver.

3. Partner Profiles (WE20): Define communication parameters, ports, and processing function modules for IDoc transmission.

The ALE process typically involves generating an outbound IDoc in the sender system, transmitting it through the RFC (Remote Function Call) interface, and then processing it as an inbound IDoc in the receiver system. ALE also supports filtering and conversion rules, allowing selective data distribution.

In essence, ALE + IDoc work together to enable reliable, asynchronous, and automated data exchange across SAP landscapes — ensuring that distributed systems remain synchronized without manual intervention. This is crucial in large organizations with multiple SAP instances or hybrid SAP/non-SAP integrations.

Technically, an IDoc consists of three main parts:

1. Control Record – contains metadata like IDoc type, sender, receiver, and message type.

2. Data Records – contain actual business data segments defined by the IDoc type (e.g., E1KNA1M for customer master).

3. Status Records – log the current status of the IDoc (e.g., sent, processed, error).

When data is sent, SAP creates an outbound IDoc using a Message Type (like ORDERS) and an IDoc Type (like ORDERS05). This IDoc is then passed to the ALE layer, which determines the receiver system through a Distribution Model and Partner Profile configuration.

In the receiving system, the IDoc is processed via an inbound function module that updates the target application tables. IDocs enable asynchronous communication, ensuring data consistency even when systems are temporarily offline. In summary, IDocs are the backbone of SAP’s system-to-system data integration framework, ensuring standardized, reliable, and auditable data exchange.

• Enter a Name for the Basic Type

  • Enter a name for your new Basic Type.
    👉 Convention: Start with Z or Y (for custom objects).

• Click the “Create” Button

  • A pop-up will appear asking for the development class (package).

  • If it’s for testing only, choose $TMP (local object, not transportable).

• Define the Attributes

  • Give a short description of the Basic Type.

  • Save.

• Add Segments

  • You’ll be taken to a screen where you can assign segments.

  • To add:

    • Click Edit → Create Segment.

    • Enter an existing segment (created in WE31) or create a new one.

  • Assign the minimum and maximum occurrence (e.g., 1 for mandatory, 0..999 for optional, repeatable).

  • Build your hierarchy (parent/child segments).

• Save and Activate

  • After assigning all segments, save.

  • Then click Edit → Set Release to release the Basic Type.

In this way you can create a basic type and add the segment to it.

Each segment has:

• A unique name (e.g., E1KNA1M for customer master data).
• Defined fields with fixed length and data types.
• A hierarchy (segments can have child segments).

Create a segment.  (WE31)

Create a segment as per the fields you want to get fetched. Like in zlibrary we can fetch the bookid bookname bookauthor etc.

Segment name: ZSEGDPM

Now, release the segment.

After release, you can see the output as

After saving the segment if you want to make some changes then you need to first cancel the release and then make the changes.

By following the Above steps we can create a segment for an IDOC.