✒️ABAP El customizing ALE
ABAP El customizing ALE
Customizing ALE
Partner Agreement
An ALE partner is a remote SAP system or a legacy system with which data is exchanged. For communication between partners, i.e., sender and receiver, to work correctly, there must be an agreement on the syntax and semantics of the exchanged data. This agreement is called a Partner Agreement.
A Partner Agreement is defined by the following data:
- IDoc Type and Message Type: These are the key identifiers of the Partner Agreement.
- Sender and Receiver Names exchanging IDocs for the IDoc Type and Message.
- Port through which sender and receiver communicate.
Specific message data to be transmitted will be defined in the input or output parameters as appropriate.
Partner agreements are created using transaction WE20. These must be defined in each client of the system where the IDocs are executed, as their definition is client-dependent. The receiving system is selected from the "EDI Partners" menu. If it does not exist, it should be created. This new system must exist as a logical system within our SAP system.
To complete the IDoc definition, we will add the message type in the corresponding sector. Output Parameters if it is an outbound IDoc, Input Parameters if it is an inbound IDoc.
For Outbound IDocs, the following parameters are required:
- Receiving System.
- Port.
- Base Type.
- Message Generation Method.
- Processing Mode.
For Inbound IDocs, the parameters will be:
- Sending System.
- Logical Message.
- Process Code.
- Function that performs the input processing.
Creation of RFC Destinations, Ports, and Logical Systems
An RFC destination is a gateway that allows communication between one SAP system and another SAP or non-SAP system. RFC destinations are configured through SM59. Depending on the destination, the RFC connection will be of one type or another. Generally, IDocs are sent via TCP/IP connections. These connections require informing the server name and the destination TCP port.
A port is the logical name for an input/output device. Programs communicate with a port through a standard interface and allow defining the communication medium for Partner Agreements. Each port, with its characteristics, can be assigned to multiple Partner Agreements. At least one port must be defined for each external system.
Ports indicate how EDI messages are sent and are configurable via WE21.
There are different types of ports:
- Files: Used if the IDoc information needs to be stored in a directory on the application server. It is recommended not to use static file names to avoid overwriting. Dynamic file names can be created using the EDI_PATH_CREATE_CLIENT_DOCUMENT function based on the client and IDoc number.
- XML Files: Allows sending documents in XML format. These ports require the port name, XML format, and the filename to generate. The filename can be dynamically generated with the same function mentioned above.
- Transactional RFC: Used when the receiving system is an external system, either SAP or non-SAP.
- XML-HTTP: In this port, an RFC destination is specified instead of defining the XML file name.
- ABAP: Executed when communication is within the same SAP system. An RFC destination specifies a function module to be executed once the IDoc is sent.
Logical systems are created with transaction BD54. If a logical system is an SAP system, we must assign it a client. To do this, access transaction SCC4.
Configurations made in WE20, WE21, and SM59 cannot be transported. There is a way to force their inclusion in a transport order:
- Create a custom transport order using transaction SE01.
- Double-click on the task of the order and press the Modify button.
- In the next screen, enter the following fields:
- Program ID: R3TR.
- Object Type: TABU.
- Object: RFCDES for entries from transaction SM59, EDIPORT for entries from WE21, and TBDLS and TBDLST for entries from WE20.
- Double-click on the table name, and a new screen will appear where you can enter the records generated in the corresponding tables. If you want to transport all destinations from SM59, enter *. Do the same for WE20 and WE21.
Distribution Model
The Distribution Model is a view where the distribution of master data is defined. In the Distribution Model, the following functions are performed:
- Relationships between logical systems, message types, BAPIs, and filters are defined.
- Applications and the ALE layer use it to determine recipients and control data distribution.
- Distribution scenarios define IDoc types and partner pairs participating in an ALE distribution. They serve as a reference to determine which data will be replicated and its recipients.
The Distribution Model is shared among all participating partners. However, it is only maintained from one system, the so-called leading system. From this system, the model is configured for any partner, even if the scenario is already active.
Different scenarios can be created within a Distribution Model for different purposes. It is recommended to have one scenario per administrator. So, if we have different departments with different requirements, we will have one scenario per department.
To create a Distribution Model, follow these steps:
- Access transaction BD64 and switch to modification mode using the menu option Distribution Model => Change Treatment Mode.
- Press the "Create Model View" button. In the dialog window, enter a brief text and the technical name for the Distribution Model.
- Select the newly created record and click the "Insert Message Type" button. In the new dialog window, enter the sender's logical system name that will transmit the message, the recipient's name that will receive it, and the message type to be transmitted between sender and recipient.
It is important to note that it is not possible to maintain the same message type between the same sender and receiver in more than one Distribution Model.
 
 
 
Sobre el autor
Publicación académica de Jaime Eduardo Gomez Arango, en su ámbito de estudios para la Carrera Consultor ABAP.
Jaime Eduardo Gomez Arango
Profesión: Ingeniero de Sistemas y Computación - España - Legajo: SW34C
✒️Autor de: 108 Publicaciones Académicas
🎓Cursando Actualmente: Consultor ABAP Nivel Avanzado
🎓Egresado del módulo:
Disponibilidad Laboral: FullTime
Presentación:
Ingeniero de sistemas y computación con 8 años de experiencia el desarrollo frontend & backend (react/node) y en cloud (aws), actualmente desarrollando habilidades en sap btp, ui5, abap y fiori.
Certificación Académica de Jaime Gomez