✒️ABAP El customizing ALE

1-Acuerdo de Interlocutor

INTERLOCUTOR ALE, es un sistema SAP remoto o un sistema legacy con el que se intercambian datos.

Cuando los datos son intercambiados entre los interlocutores, es importante el emisor y el receptor que estén de acuerdo en la sintaxis y sistemática de los datos intercambiados. A esto se le llama ACUERDO DE INTERLOCUTOR.

Los acuerdos de interlocutor son:

• Tipos de Doc y Tipo de mensajes, cuales son el identificador clave del Acuerdo de interlocutor
• Nombre Del Emnisor y Receptor que intercambiaran los IDocs para el tipo de Doc y mensajes.
• Puerto por el cual el emisor y el receptor se comunicarán.

El interlocutor se definen los 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 crearlos acuerdos de interlocutores) se crea el Acuerdo de Interlocutor.

Se debe definir el acuerdo de interlocutores en cada mandan y sistema don de se ejecutan los Doc ya que esta definición es Dependiente del mandante.

Se selecciona el sistema receptor del menú INTERLOCUTORES EDI, si no existe el menú debe crearse un nuevo nodo. Es mismo debe existir en R/3 como sistema lógico.

Para definir los IDoc, se agrega el tipo de mensaje en el sector "Parámetros de salida" y si es salida en el sector de Parámetros de entrada, si es entrada haciendo doble clic en el notan Agregar registro.

Los IDoc de salida, se indica el sistema de receptor, el puerto, tipo de base, forma en que se genera el mensaje y en que modalidad se procesa. No se especifica el sistema emisor, el acuerdo se determina entre el sistema donde se configura el mismo y en el sistema receptor.

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

2- Creación de destinos RFC, puertos y sistemas lógicos

Destino RFC, es un puerta de enlace que permite comunicar un sistema SAP con otro sistema SAP o no SAP. Se crean con SM59 ( 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.)

Dependiendo del sistema lógico, la conexión RFC será de distinto tipo, para los envíos de Doc se crearan conexiones del tipo TCP/IP especificando el nombre del servidor destino y el puerto TCP destino. LOs Doc pueden ser enviados y recibidos a través de diferentes medios, el objetivo de no acoplar la definición de las características del medio con la aplicación que lo esta utilizando el medio accedido vea PUERTOS ( es un nombre lógico para un dispositivo de entrada y salida).

Los programas se comunican con un puerto a través de una interfaz estándar, en vez de definir el medio de comunicación directamente de acuerdo de interlocutores se asigna un número de puerto y ese puerto el que designa al medio. Este permite definir las características de los puertos individualmente y usar un puerto en múltiples acuerdos de interlocutores.

Los cambios en un puerto se reflejan automáticamente en todos los acuerdos que lo estén utilizando, un puerto debe existir para cada sistema externo.

Los puertos indican la forma de envío de los mensajes EDI y se configuran por medio de WE21( es usado para la administración de los puertos en el proceso de IDOC).

Los puertos mas comúnmente utilizados.

FICHEROS: se utilizan cuando la información de Doc debe ser almacenada en un directorio del servidor de aplicaciones, no se recomienda usar nombres estáticos porque el archivo es escrito cada vez que el Doc se envía. Se recomienda usar el módulo de función EDI_PATH_CREATE_CLIENT_DOCNUM el cual genera el nombre del archivo a partir del mandante y el nro. IDoc.

FICHEROS XML: utiliza formato XML, para utilizar este tipo de puerto, es necesario definir el nombre del puerto, el formato del XML y el nombre del archivo que se genera, al igual que con el tipo de ficheros se puede invocar a la función EDI_PATH_CREATE_CLIENT_DOCNUM para que genere los nombre de los archivos de forma dinámica.

RFC TRANSACCIONAL: se utilizan cuando el sistema receptor es un sistema SAP o no SAP externo. La información del Doc será enviada a este sistema externo a través de esa puerta.

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

ABAP: cuando se utiliza el Doc esta definido desde un sistema SAP al mismo sistema SAP. Ej para definir un flujo de procesos a realizarse cuando se cree un documento especifico, luego enviado al IDoc.

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

Cuando el sistema lógico es un R/3, se lo debe asignar a un mandante, para eso utilizamos la transacción SCC4.

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.

3- Modelo de Distribución

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

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

En la distribución se definen los tipos IDoc y los pares interlocutores que participan en la distribución ALE, Esta distribución es la referencia para determinar que los datos serán replicados y quienes serán los receptores.

El modelo de distribución es compartido entre todos los interlocutores participantes, solo puede ser mantenido en uno de los sistemas, se le llama sistema líder. Solo uno de los sistema es líder, pero se puede ser configurado cualquier de los interlocutores en cualquier momento aun si el escenario ya se encuentra activo.

Puede haber varios escenarios para diferentes propósitos, solo se puede poner todo en un solo escenario, lo mas recomendable es crear un escenario por administrador. Si hay solo un administrador ALE, no tiene sentido tener ma de un escenario, pero si hay varios departamentos con diferentes requerimientos ser amas útil crear un escenario por el departamento.

Los pasos para la creación de un MODELO DE DISTRIBUCION

1. Accedemos a la transacción BD64 (creación de los modelos de distribución)
2. Cambiamos al modo de tratamiento o modificación, para ello vamos a opciones Menú MODELO DE DISTRIBUCION /CAMBIAR MODO DE TRATAMIENTO.
3. Presionamos Crear Vista Modelo.
4. En la ventana de diálogo introducimos un texto breve y el nombre técnico para le modelo de distribución.
5. Posteriormente seleccionamos el registro recién creado y presionamos Insertar Tipo de Mensaje.
6. Ahora introducimos el EMISO el nombre del sistema lógico que transmitirá el mensaje, el campo de destinatario con el nombre del sistema lógico que recibirá el mensaje y el tipo de mensaje con el mensaje que se transmitirá entre estros sistemas lógicos. (no se puede mantener un tipo de mensaje entre el mismo receptor y emisor en mas de un modelo de distribución).
7. Finalmente vemos el modelo de distribución creado.