✒️ABAP / El customizing ALE Por Jaime Gomez Arango

Selector Alummnos / Empresas

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.


 

Escanear / Compartir

 

 


Sobre el autor

Publicación académica de Jaime Eduardo Gomez Arango, en su ámbito de estudios para la Carrera Consultor ABAP Nivel Avanzado.

SAP Expert


Jaime Eduardo Gomez Arango

Profesión: Ingeniero de Sistemas y Computación - España - Legajo: SW34C

✒️Autor de: 149 Publicaciones Académicas

🎓Egresado de los módulos:

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

✒️+Comunidad Académica CVOSOFT

Continúe aprendiendo sobre el tema "El customizing ALE" de la mano de nuestros alumnos.

SAP Master


El customizing ALE Acuerdo de interlocutor El acuerdo de interlocutor define cómo se intercambian datos entre un sistema SAP y un sistema remoto o Legacy. Es fundamental que emisor y receptor acuerden la sintaxis y semántica de los datos. Incluye datos como tipo de iDocs, tipo de mensaje, nombre del emisor y receptor, y el puerto de comunicación. Permite definir parámetros de salida (para iDocs salientes) y de entrada (para iDocs entrantes). Se crea a través de la transacción WE20 y debe configurarse en cada mandante y sistema involucrado. Para el receptor, se selecciona o crea un nodo en el menú Interlocutores EDI;...

Acceder a esta publicación

Creado y Compartido por: Juan Ignacio Romero

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Master

Introducción: La configuración de comunicaciones ALE/EDI es fundamental para el intercambio de datos entre sistemas SAP y no SAP. Esta guía cubre los componentes esenciales para establecer estas conexiones. 1. Acuerdo de Interlocutor (WE20) ¿Qué es? Un acuerdo técnico entre sistemas que define las reglas para el intercambio de IDocs. Elementos clave: Tipo de Mensaje y Tipo Base del IDoc Sistemas Emisor y Receptor Puerto de comunicación Configuración: Transacción: WE20 Se define en Parámetros de Salida...

Acceder a esta publicación

Creado y Compartido por: Oscar Aravena Muller / Disponibilidad Laboral: FullTime

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert



ALE (Application Link Enabling) es una tecnología de SAP que permite integrar sistemas SAP entre sí o con sistemas externos, manteniendo la consistencia de los datos a través de la transferencia controlada y segura de información. ALE se basa en la arquitectura distribuida y es utilizada para la comunicación asincrónica entre sistemas mediante IDocs (Intermediate Documents). El proceso de configuración (customizing) de ALE se centra en definir los elementos técnicos y lógicos que permiten esta comunicación. Este customizing se realiza principalmente en la transacción SALE (ALE Customizing), que agrupa los pasos necesarios para configurar correctamente los entornos emisores...

Acceder a esta publicación

Creado y Compartido por: David Ibarra / Disponibilidad Laboral: FullTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

La lección "Customizing ALE" abarca la configuración de los componentes necesarios para la integración de sistemas SAP, incluyendo la creación y gestión de acuerdos de interlocutor, destinos RFC, puertos y sistemas lógicos, además de la configuración del modelo de distribución. • Acuerdo de Interlocutor Es un acuerdo entre emisor y receptor sobre la sintaxis y semántica de los datos intercambiados. â—¦ Datos definidos: Incluyen el tipo de IDoc y mensaje, los nombres del emisor y receptor, y el puerto de comunicación. â—¦ Transacción WE20: Herramienta estándar para crear el Acuerdo de Interlocutor. â—¦ Dependiente de mandante:...

Acceder a esta publicación

Creado y Compartido por: Roberto Fluder Ahumada

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP SemiSenior

Un IDoc está estructurado en tres partes principales: Cabecera (Control Record) : Contiene información general sobre el IDoc, como el tipo de IDoc, el número, la fecha de creación, el emisor y el receptor. Segmentos de Datos (Data Records) : Almacenan los datos reales que se están intercambiando. Cada segmento puede contener varios campos con información específica, y los segmentos pueden repetirse según sea necesario. Registro de Estado (Status Records) : Muestra el estado del IDoc en el proceso de transmisión, como si fue enviado con éxito, si hay errores, etc. Estas tres partes permiten que el IDoc sea un medio eficiente para...

Acceder a esta publicación

Creado y Compartido por: Exequiel Eduardo Acevedo / Disponibilidad Laboral: FullTime

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

El customizing ALE El acuerdo del interlocutor: -Interlocutor ALE: Es un sistema SAP remoto o un sistema legacy con el que intercambian datos. Cundo los datos son intercambiados entre interlocutores, es importante que el emisor y el receptor estén de acuerdo en la sintaxis y semantica de los datos intercambiados.

Acceder a esta publicación

Creado y Compartido por: Luis Enrique Romero Pinto

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert


Si bien las configuraciones que realicemos en las transacciones estandar WE20 WE21 y SM59 no se pueden transportar existe una forma de incluir estas configuraciones en una orden de transporte de modo de transportarlas al sistema que queramos, esta opcion nos puede ser de mucha utilidad si se va a realizar un refresh del ambiente SAP en el cual estamos trabajando, y deseamos conservar las entradas generadas en estas transacciones de configuracion, de modo de no tener que generarlas manualmente luego del refresh y mandante. Cuando hablamos de refresh nos referimos a que en las empresas cada X cantidad de tiempo se pisan los datos del ambiente de testing con los datos provenientes del ambiente de produccion para mantener el ambiente de pruebas...

Acceder a esta publicación

Creado y Compartido por: Jose Medina / Disponibilidad Laboral: FullTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

Interlocutor ALE: es un sistema SAP remoto o un sistema legacy con el que se intercambien datos. Los datos definidos en un Acuerdo de Interlocutor son: Tipo de IDOC y Tipo de mensaje, los cuales son el identificador clave del Acuerdo de interlocutor. Nombre del Emisor y Receptor que intercambiarán los IDOCS para el tipo de IDOC y mensaje. Puerto por el cual el mensaje y el receptor se comunicarán. En el interlocutor se definen datos específicos de cada mensaje a transmitir en los parámetros de salida o entrada según corresponda. A través de la transacción WE20 se crea el Acuerdo de Interlocutor. Para definir el IDOC, se agrega el tipo de mensaje en el sector "Parámetros...

Acceder a esta publicación

Creado y Compartido por: Javier Miguel Angel Barcelo / Disponibilidad Laboral: PartTime

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Master

EL ACUERDO DE INTERLOCUTOR. Interlocutor ALE: Es un sistema SAP remoto o un sistema legacy con el que se intercambian datos. Los datos definidos en un acuerdo de interlocutor son: • Tipo de IDocs y tipo de mensaje. • Nombre del Emisor y Receptor que intercambiarán los IDocs para el Tipo de IDoc y mensaje. • Puerto por cuál el Emisor y el Receptor se comunicaran. Través de la transacción WE20 se crea el Acuerdo de interlocutor. Transacción WE20: mediante está transacción crearemos los Acuerdos de interlocutores en el sistema SAP. Se debe definir el acuerdo de interlocutores en cada mandante y sistema dónde se ejecutarán los IDocs. Se selecciona el sistema receptor...

Acceder a esta publicación

Creado y Compartido por: Gerardo Jose Campos Tovar / Disponibilidad Laboral: FullTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert


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...

Acceder a esta publicación

Creado y Compartido por: Jaime Eduardo Gomez Arango / Disponibilidad Laboral: FullTime + Carta Presentación

 


 

👌Genial!, estos fueron los últimos artículos sobre más de 99.000 publicaciones académicas abiertas, libres y gratuitas compartidas con la comunidad, para acceder a ellas le dejamos el enlace a CVOPEN ACADEMY.

🔎Buscador de Publicaciones:

 


 

No sea Juan... Solo podrá llegar alto si realiza su formación con los mejores!