✒️ABAP El customizing ALE
ABAP El customizing ALE
CUSTOMIZING ALE
1.- Acuerdo de interlocutor: Es un sistema SAP remoto o un sistema legacy con el que se intercambian datos.
Cuando los datos son 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 lo llama "Acuerdo de interlocutor".
Consta de los siguientes datos definidos:
- 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 emisor y el receptor se comunicaràn.
En 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 crea el Acuerdo de Interlocutor.
Se debe definir el acuerdo de interlocutores en cada mandante y sistema donde se ejecutaràn los IDOCs ya que esta definiciòn es "Dependiente del mandante".
Se selecciona el sistema receptor del menù "Interlocutor EDI". Si no existiera en este menù, debe crearse un nuevo nodo.Este 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", si es de salida y en el sector "Paràmetros de entrada", si es de entrada, haciendo click en el botòn de "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 en que modalidad se procesa. No se especifica el sistema emisor, ya que el acuerdo se determina entre el sistema donde se configura el mismo y en el sistema receptor.
Para IDOCs de entrada, se indica el sistema emisor, el mensaje lògico, el còdigo de proceso y la fucniòn que procesa la entrada.
2.- Creaciòn de destinos RFC, puertos y sistemas lògicos.
Destino RFC.- Es una puerta de enlace que permite comunicar un sistema SAP con otro sistema SAP o no SAP
Los destinos RFC se crean a travès de la transacciòn SM59 (visualizar y actualizar destinos RFC, se pueden crear, borrar y modificar conexiones R/3, conexiones interna, destinos lògicos, conexiones TCP/IP y conexiones con driver abap).
Dependiendo del sistema destino, la conexiòn RFC serà de distinto tipo. En gereral para envìo de Idocs, se crean conexiones del tipo TCP/IP, especificando el nombre del servidor destino y el puerto TCP destino.
Los IDOCs pueden ser enviados y recibidos a travès de diferentes medios. Con el objetivo de no acoplar la definiciòn de las caracterìsticas del medio con la aplicaciòn que lo està utilizando, el medio es accedido vìa puertos.
Puertos.- Nombre lògico para un dispositivo de entrada/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 en el Acuerdo de Interlocutores, se asigna un nùmero de puerto y este designa realmente el 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 reflejan automàticamente en todos los acuerdos que lo estèn utilizando.
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 por medio de la transacciòn WE21.
Puertos màs utilizados:
- Ficheros: Se utiliza cuando la informaciòn del IDOC debe ser almacenada en un directorio en el servidor de aplicaciones. SAP sugiere no utilizar nombres estàticos, dado que el archivo es sobreescrito cada vez que el IDOC se envìa. Utilizar el mòdulo de funciòn EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y no del IDOC.
- Ficheros XML: Envìa documentos en formato XML. Para utilizar este tipo de puerto, es necesario definir el nombre del puerto, el formato del XML y el nombre del archivo a generar. Al igual que con el tipo de puerto Fichero, se puede invocar a la funciòn EDI_PATH_CREATE_CLIENT_DOCNUM.
- RFC Transaccional: Se utiliza cuando el sistema receptor es un sistema SAP o no SAP externo. La informaciòn de 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 utiliza 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. Tienen la particularidad de ejecutar un mòdulo de funciones luego de enviado el IDOC.
Los sistemas lògicos se crean a travès de la transacciòn BD54.
Cuando el sistema lògico es un R/3, se lo debe asignar a un mandante. Para ello utilizamos la transacciòn SCC4.
Si bien las configuraciones de las transacciones WE20 WE21 y SM59 no se pueden transportar, existe una forma de incluir estas configuraciones en una orden de transporte para transportarlas al sistema que se desee, esto es muy ùtil sobre todo cuando se realiza un refresh de ambiente
3.- Modelo de Distribuciòn.
Es una vista donde se define la distribuciòn de los datos maestros.
La realciòn entre sistemas lògicos, tipos de mensajes, BAPIs y filtros estàn definidas en el Modelo de Distribuciòn. La 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. El escenario de distribuciòn es la referencia para determinar què datos seràn replicados y quienes seràn los receptores.
El modelo de ditribuciòn es compartido entre todos los interlocutores participantes. Por lo tanto solo puede ser mantenido en una de los sistemas, el cual lo podemos llamar el sistema lider. Sòlo uno de los sistemas es el sistema lìder, pero puede se configurado para cualquiera de los interlocutores en cualquier momento, aùn si el escenario ya se encuentra activo.
Pueden haber varios escenarios para diferentes propòsitos. Por otro lado se puede poner todo en un solo escenario. Lo màs recomendable es crear un escenario por administrador. Si hay un solo administrador ALE, no tiene mucho sentido tener màs de un escenario. Pero si hay varios departamentos con diferentes requerimientos, serà màs ùtil crear un escenario por departamento.
Pasos para la creaciòn de un modelo:
- Acceder a la transacciòn BD64.
Cambiar el modo de tratamiento a modificaciòn, para ello vamos a la opciòn del menù "Modelo de Distribuciòn / Cambiar modo de tratamiento".
Luego presionamos el botòn "Crear vista Modelo".
En la ventana de diàlogo introducimos un texto breve y el nombre tècnico para el modelo de distribuciòn.
Posteriormente seleccionamos el registro recièn creado y presionamos e botòn "Insertar tipo mensaje"
En la siguiente ventana de diàlogo, introducimos en el emisor el nombre del sistema lògico que transmitirà el mensaje, el destinatario con el nombre del sistema lògico que recibirà el mensaje y el Tipo de mensaje con el mensaje que se transmitirà entre estos sistemas lògicos.
"No se puede mantener un tipo de mensaje entre el mismo emisor y receptor en màs de un modelo de distribuciòn"
Sobre el autor
Publicación académica de Miguel Angel Acosta Acosta, en su ámbito de estudios para la Carrera Consultor ABAP.
SAP Expert
Miguel Angel Acosta Acosta
Profesión: Ingeniero de Sistemas - Ecuador - Legajo: TF64C
✒️Autor de: 238 Publicaciones Académicas
🎓Egresado de los módulos:
- Carrera Consultor en SAP SD Nivel Avanzado
- Carrera Consultor en SAP SD Nivel Inicial
- Máster ABAP for HANA
- Carrera Consultor ABAP Nivel Avanzado
- Carrera Consultor ABAP Nivel Inicial
Disponibilidad Laboral: FullTime
Presentación:
Profesional de ingeniería de sistemas en computación e informática, con experiencia en la implantación y soporte de proyectos informáticos para empresas del sector industrial y financiero.
Certificación Académica de Miguel Acosta
