✒️ABAP Los IDocs de entrada
ABAP Los IDocs de entrada
Understanding Incoming Interfaces
Unlike outgoing IDocs, incoming IDocs don't have different process types. Once created in the database, they follow the same execution path, regardless of their origin.
In SAP, an IDoc can be created in two ways:
- Through middleware, which sends the message in IDoc format to the incoming port. Examples include SAP PI/PO.
- By an IDoc file, which is processed by the EDI_DATA_INCOMING function module.
For an ABAP programmer, involvement is limited to:
- Configuring incoming IDocs.
- Defining an inbound process code.
- Establishing inbound partner agreements.
Configuring Incoming IDocs
To configure incoming IDocs, use transaction BALD. The necessary configuration points are found under IDOC / Inbound Process / Function Module.
Key configurations include:
- Setting attributes for the function module processing the document. This is done with transaction BD51. By defining a function module, we can update the attributes of incoming IDocs. The module needs to be added to the BD51 list to be recognized by SAP as usable for IDoc processing.
- Assignment of Base Type-Message Type-Process Function. Use transaction WE57 to assign the function module from the previous step to a message type. This step links an object with a processing method. Multiple assignments per message type are possible, as there might be multiple function modules handling attribute updates or interpreting different structures of the same message type.
Inbound Process Code
This code determines how an incoming IDoc is processed. Its main attribute is the function module assigned for this purpose. For parameterization, use transaction WE42. Here, we'll create a new entry.
The process code defines whether the message processing is done with ALE services or not, and the processing class. ALE services provide various functionalities, including segment filters and version/type modifications. The processing class determines whether the process code will execute a function module, another operation code (obsolete option), or a workflow task.
The "Process with ALE service" option, usually not associated with Z message types, allows specifying start and end process events (only for standard messages). We must specify the type of business object generated.
Inbound Partner Agreement (WE20)
The inbound partner agreement must be updated for each incoming IDoc in each receiving system. To update it, select one of the message sending systems and add a new "Input Parameter." The definition of the receiving system is implicit in relation to the system where the agreement is updated. In the "Input Partner Type, Logical System" folder. If there is no information in the input parameters, and the sending system does not exist, it should be created based on the sender-receiver system type (Logical System, client, vendor, etc.).
The partner agreement defines the interface model. Therefore, we will define:
- Message type to receive.
- Object type.
There are two input options defining the treatment of the received IDoc:
- The process code: Responsible for interpreting the IDoc information and updating the corresponding transaction(s).
- The process form: "Immediate launch" or "Launch through a background program."
The background process option is used when the IDoc information should not be updated upon reception but processed periodically through a Job.
 
 
 
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