✒️ABAP El customizing ALE

INTERLOCUTOR ALE: es un sistema SAP remoto o un sistema legacy (heredado) con el cual se intercambian datos.

Cuando los datos sin intercambiados entre interlocutores, es importante que el emisor y el receptor estén de acuerdo en la sintaxis y semántica de los datos intercambiados. A este acuerdo se denomina Acuerdo de Interlocutor.

Los datos definidos en un Acuerdo son:

· Tipo de IDoc y Tipo de mensaje, los cuales son el identificador clave del Acuerdo.

· Nombre del Emisor y Receptor que intercambiarán los IDocs para el Tipo de IDoc y mensaje.

· Puerto por el cual el emisor 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 crean loa Acuerdos de Interlocutores en el sistema SAP.

Se define el acuerdo en cada mandante y sistema donde se ejecutarán los IDocs, ya que esta definición es Dependiente de mandante.

Se selecciona el sistema receptor del menú Interlocutores EDI. Si no existiera en este menú, debe crearse un nuevo nodo. Este nuevo sistema debe existir en R/3 como sistema lógico.

Para definir el IDoc, se agrega el tipo de mensaje en el sector Parámetros de salida o Parámetros de entrada, haciendo click en Agregar registro ().

Para IDocs de salida, se indica el sistema receptor, el puerto, el tipo base, la forma en que se genera el mensaje y la modalidad en la que se procesa. No se especifica el sistema emisor.

Para IDocs de entrada, se indica el sistema emisor, el mensaje lógico, el código de proceso y la función que procesa la entrada.

Destino RFC, es una puerta de enlace que permite comunicar un sistema SAP con otro sistema (SAP o no SAP). Se crean desde la transacción SM59. Aquí podemos visualizar y actualizar destinos RFC. Se pueden crear, borrar y modificar Conexiones R/3, Conexiones Internas, Destinos lógicos, Conexiones TCP/IP y conexiones con driver ABAP.

La conexión RFC dependerá del sistema destino. En general, para envío de IDocs, se crean conexiones TCP/IP, especificando nombre de servidor destino y el puerto TCP destino.

Los IDocs pueden ser enviados y recibidos por diferentes medios. El medio es accedido a través de puertos, de manera de no acoplar la definición de las características del medio con la aplicación que lo está utilizando. (Un puerto es el nombre lógico para un dispositivo de entrada/salida).

Los programas se comunican por un puerto a través de una interfaz estándar.

En vez de definir el medio de comunicación directamente en el Acuerdo de Interlocutores, se asigna un número de puerto, y es este, el que se designa al medio. Esto permite definir las características de los puertos individualmente y usar un puerto en múltiples Acuerdo de Interlocutores.

Los cambios en un puerto se reflejaran en todos los Acuerdos que lo están utilizando. Al menos uno debe existir para cada sistema externo.

Al menos un puerto debe existir para cada sistema externo.

Los puertos indican la forma de envío de los mensajes EDI y se configuran en la transacción WE21. (Es la que se utiliza para la administración de los puertos en el proceso de IDocs.)

Los puertos más comúnmente utilizados son:

· Ficheros: Se utilizan cuando la info del IDoc debe ser almacenada en un directorio en el servidor de aplicaciones. SAP recomienda no usar nombre de archivos estáticos, dado que el archivo es sobre escrito cada vez que el IDoc se envía. Se aconseja usar el módulo de función EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y número de IDoc.

· Ficheros XML: envía documentos en formato XML. Para usar este tipo de puerto, es necesario definir el nombre del puerto, formato XML y nombre del archivo a generar. De la misma manera que con el tipo de puerto Fichero, se puede invocar a la función EDI_PATH_CREATE_CLIENT_DOCNUM para generar los archivos de forma dinámica.

· RFC Transaccional: Se utiliza cuando el sistema receptor es un sistema SAP o no SAP externo. La info del IDoc será enviada a este sistema externo a través de esta puerta.

· XML-HTTP: en vez de definir el nombre del archivo XML, se especifica un destino RFC.

· ABAP: se utilizan cuando el IDoc está definido desde un sistema SAP al mismo sistema SAP. Esto sirve, por ejemplo, para definir un flujo de procesos a realizarse cuando se cree un documento específico. Ejecutan un módulo de funciones después de enviado el IDoc.

Los sistemas lógicos se crean desde la transacción BD54.

Cuando el sistema lógico es R/3, se lo debe asignar un mandante, a través de la transacción SCC4.

NOTA (Audio Tip): Si bien las configuraciones que realicemos en las transacciones estándar 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 opción nos puede ser de mucha utilidad si se va a realizar un “refresh” del ambiente SAP en el cual estamos trabajando y deseemos conservar las entradas generadas en estas transacciones de configuración, de modo de no tener que generarlas manualmente luego del refresh del ambiente y mandante.

Cuando hablamos de refresh nos referimos a que en las empresas cada cierta cantidad de tiempo se reemplaza los datos del ambiente de testing con los datos existentes en el ambiente de producción para mantener el ambiente de pruebas con datos actuales. Para grabar las configuraciones entonces vamos a crear una nueva orden de transporte en la transacción SE01, hacemos doble clic en la tarea de la orden y presionamos el botón para modificarla. Allí veremos una pantalla y en el campo ID de programa vamos a introducir la opción R3TR, en el campo tipo de objeto introducimos TABU, en el campo objeto introducimos RFCDES para las entradas generadas en la transacción SM59, EDIPORT para las entradas generadas en la transacción WE21 y TBDLS y TBDLST para las entradas generadas en la transacción WE20. Luego si hacemos doble click en el nombre de la tabla veremos una nueva pantalla en donde podremos introducir los registros generados en las tablas correspondientes. Si deseamos transportar todos los destinos RFC de la transacción SM59 aquí debemos introducir * (asterisco). Lo mismo ocurre con las transacciones WE20 y WE21.

Es una vista donde se define la distribución de los datos maestros.

La relación entre sistemas lógicos, tipos de mensajes, BAPIs y filtros están definidas en el modelo de distribución. Las aplicaciones y la capa ALE usan el modelo de distribución para determinar los receptores y para controlar la distribución de datos.

Los escenarios de distribución definen los tipos de IDocs y los pares de Interlocutores que participan en una distribución ALE y son la referencia para determinar qué datos serán replicados y quiénes serán los receptores.

El modelo de distribución es compartido entre todos los interlocutores participantes. Por lo tanto, solo puede ser mantenido en uno de los sistemas (sistema líder), pero puede ser configurado para cualquiera de los interlocutores en cualquier momento, aún si el escenario se encuentra activo.

Puede haber varios escenarios para diferentes propósitos. Por otro lado se puede poner todo en uno solo. Lo más recomendable es crear uno por administrador. Si hay un solo administrador ALE no tiene sentido tener más un escenario. Pero si hay varios departamentos con diferentes requerimientos, será más útil crear un escenario por departamento.

Los pasos para la creación de un Modelo de distribución:

1) Accedemos a la transacción BD64 para la creación del Modelo.

2) Cambiamos el modo de tratamiento a modificación, Menú/Modelo de Distribución/Cambiar modo de tratamiento.

3) Presionamos botón Crear vista modelo

4) Introducimos texto y nombre técnico para el modelo de distribución.

5) Seleccionamos el registro recién creado y botón Insertar tipo mensaje.

6) En la siguiente ventana de dialogo:

a) Indicamos en el campo Emisor el nombre del sistema lógico que transmitirá el mensaje

b) En el campo Destinatario el nombre del sistema lógico que recibirá el mensaje y,

c) En el campo Tipo de mensaje con el mensaje que se transmitirá entre estos sistemas lógicos.

NOTA: No se puede mantener un tipo de mensaje entre el mismo emisor y receptor en más de un modelo de distribución.