guía rápida de parametrización ale

45
Barcelona 12 de Julio de 2002 MODELOS DE INTERFASE ALE MODELOS DE INTERFASE ALE

Upload: jhonbarriga

Post on 06-Sep-2015

276 views

Category:

Documents


0 download

DESCRIPTION

Interfase ALE

TRANSCRIPT

MODELOS DE INTERFASE ALE

Barcelona 12 de Julio de 2002

1. Introduccin

En el presente documento se detalla la parametrizacin necesaria para realizar diferentes tipos de interfases ALE. Se pueden distinguir tres tipos de interfases:

1. Interfase ALE estndar.

2. Interfase ALE no estndar.

3. Interfase ALE-BAPI.

2. Interfase ALE estndar

Se entiende por interfase ALE estndar aquella en la que SAP dispone de un mensaje ALE estndar para los datos que se desean replicar entre los sistemas implicados. Por ejemplo, en el caso de que se desee replicar datos maestros referentes a clientes utilizaremos el mensaje ALE estndar DEBMAS.

Para parametrizar una interfase de este tipo los pasos a seguir son los siguientes.

2.1. Tipo de mensaje ALE

Primeramente es necesario definir qu tipo de mensaje ALE es acorde con la informacin que se desea replicar. Para ello utilizaremos la transaccin WE60 (Documentacin para tipos IDOC). En esta transaccin se obtiene informacin detallada de qu campos se replicarn con el tipo base IDOC correspondiente.

Conjuntamente con el equipo funcional se selecciona un tipo base IDOC a utilizar. No es posible utilizar un tipo de base IDOC estndar que no est liberado para la versin en la que se est trabajando. Este tipo base est ligado a un tipo de mensaje ALE. Esta informacin se encuentra en la transaccin WE82. El tipo de mensaje ALE tambin se encuentra en la transaccin WE81, en ella se definen nicamente los tipos de mensaje.

2.2. Preparar sistemas lgicos

Una vez conocidos los sistemas entre los que va a replicar la informacin se preparan los sistemas lgicos. Un sistema lgico es solamente una etiqueta identificativa de cada entorno. Cada mandante ha de disponer de un sistema lgico, ya que en caso contrario no es posible la parametrizacin de una interfase ALE.

Para realizar este tipo de parametrizacin se utiliza la transaccin SALE. En ella podemos asignar un sistema lgico al mandante en el que estamos trabajando. Tambin es necesario nombrar todos los sitemas lgicos a los que vamos a enviar datos desde nuestro sistema emisor. (Tabla TBDLS).

2.3. Creacin de destinos RFC

La comunicacin entre los sistemas implicados se realiza mediante conexiones RFC tipo 3. El nombre del destino RFC ha de coincidir con el nombre del sistema lgico asociado al mandante en el que estamos realizando la parametrizacin. De esta forma, el sistema es capaz de generar de forma automtica la puerta lgica para el proceso IDOC y los acuerdos de interlocutor. En caso contrario se debera realizar de forma manual. La creacin de destinos RFC se realiza mediante la transaccin SM59.

2.4. Creacin del escenario ALE

El siguiente paso es la creacin de un modelo de distribucin. En l se indica el tipo de mensaje ALE empleado, el sistema emisor y el receptor y los filtros ALE a utilizar. Este punto de la parametrizacin se realiza mediante la transaccin BD64. Con esta misma transaccin se generan acuerdos de interlocutor en el sistema emisor, se distribuye el escenario al sistema receptor y se generan los acuerdos de interlocutor en el mismo receptor.

Cada mensaje ALE estndar dispone de unos filtros estndar. En caso de ser necesario es posible crear nuevos filtros para un tipo de mensaje.

2.5. Pruebas unitarias

Para confirmar la correcta parametrizacin del escenario ALE es conveniente realizar una serie de pruebas unitarias. Para ello se utiliza el envo bajo peticin. Mediante esta tcnica se realiza la replica de datos de manera manual.

En que casos la ejecucin bajo esta tcnica es recomendable:

En una carga inicial de datos maestros a un sistema virgen.

En el caso de que se aada un objeto nuevo a replicar en el modelo de distribucin, deber realizarse una carga inicial para este objeto en los entornos destino ya que los punteros de modificacin slo recogen el mantenimiento a partir del momento en que se ha realizado una carga previa de ese objeto. Estos objetos nuevos podran haberse mantenido en un periodo anterior.)

Adems en algn momento podra darse el caso de que se quisiera hacer una nueva carga de datos.

Mediante la transaccin BALE se accede al envo de datos maestros. De esta forma generamos un IDOC en el sistema emisor con el dato seleccionado y se replica en el sistema emisor. Una parametrizacin correcta viene indicada por los status del IDOC.

STATUSDescripcin

01Idoc creado.

03Transferencia de datos a puerta OK.

26Error de sintaxis en IDOC ( Salida ).

29Error en servicio ALE.

30IDOC listo p. envo ( Servicio ALE ).

50Idoc creado.

51No se ha contabilizado documento de aplicacin.

52Documento de aplicacin contabilizado de forma incompleta.

53Documento de aplicacin contabilizado.

60Error de sintaxis en IDOC (Entrada).

63Error al traspasar IDOC a la aplicacin.

64IDOC listo p. traspaso a la aplicacin.

65Error en servicio ALE.

2.6. Parametrizacin especfica

Existe la posibilidad que el mensaje ALE estndar requiera de parametrizacin especfica, como por ejemplo la parametrizacin de sociedades globales, divisiones globales o la distribucin de informacin mediante clases de objetos.

Al ser este tipo de parametrizacin especfica de cada mensaje no es posible realizar una descripcin detallada de la misma. Aun as, la parametrizacin referente a ALE esta presente en la transaccin SALE.

2.7. Replica de la informacin

Se pueden diferenciar dos procesos o tcnicas diferentes a la hora de replicar la informacin.

Punteros de modificacin.

Bajo peticin. (Pruebas unitarias).

Punteros de modificacin. Utilizando esta tcnica la replica de la informacin se produce de una manera automatizada de manera diaria. Esto se consigue mediante la planificacin de jobs que se ejecutan cada da.

Esta tcnica consiste en que desde el sistema emisor se ejecuta un programa que realiza la replica de la informacin. Este programa realiza una evaluacin de los punteros de modificacin, en los cuales queda grabada cualquier modificacin que se haya producido durante el da. La ejecucin de este programa se realizar en fondo a travs de un job. Durante la ejecucin de dicho programa se crearn los IDOCs que sern enviados automticamente al sistema destino. Dentro de estos IDOCs encontraremos registradas las modificaciones que se ha producido en el sistema origen y que son susceptibles a ser replicadas. . El programa ABAP encargado de recoger los punteros de modificacin, a partir de los cuales generar los IDOCs es el RBDMIDOC.

Es necesario realizar la activacin de los punteros de modificacin generales y la activacin especfica para cada mensaje. Las transacciones son la BD61 y BD50 respectivamente.

3. Interfase ALE NO estndarSe entiende por interfase ALE no estndar aquella en la que SAP no disponemos de un mensaje ALE estndar para los datos que se desean replicar entre los sistemas implicados.

Para parametrizar una interfase de este tipo los pasos a seguir son los siguientes.

3.1. Tipo de mensaje ALE

Primeramente es necesario definir qu informacin se desea replicar entre los sistemas implicados y como se desea jerarquizar este informacin. Es decir, un mensaje ALE se compone de un tipo base IDOC, y ste de segmentos. Los segmentos no son ms que estructuras en el diccionario de datos en los que definimos los campos (elementos de datos) a replicar. Es necesario indicar qu segmento actuar de cabecera y cuales vendrn subordinados a ste. Esta parte es responsabilidad nica del equipo funcional.

Para crear el mensaje ALE se utiliza la transaccin WE81, en la que se indica nicamente el nombre del mensaje ALE no estndar. Ejemplo: ZORDER.

3.2. Desarrollo de segmentos

La nomenclatura a seguir para el desarrollo de segmentos es: Z1P...... y seguidamente el nombre de la tabla cuyos campos va a contener el segmento.

La transaccin utilizada para la creacin de segmentos es la WE31. Es necesario indicar los campos que se desean replicar y sus elementos de datos. En versiones antiguas es necesario que los elementos de datos sean tipo CHAR. Los nombres de los campos pueden ser arbitrarios, pero es aconsejable seguir la nomenclatura estndar de SAP.

Una vez construidos los segmentos es necesario pasar a su liberacin.

3.3. Desarrollo tipo IDOC

Una vez se han creado los segmentos es necesario establecer una jerarqua entre ellos. Para ello se crea un tipo base IDOC. La nomenclatura del tipo base es normalmente el nombre del mensaje seguido de 01. Ejemplo: ZORDER01.

Al crear el tipo base IDOC indicamos que segmento es la cabecera y cules son sus subordinados. Tambin es necesario indicar la cantidad mxima de segmentos que pueden secuenciarse. Esto es imprescindible si un segmento subordinado puede repetirse para un mismo segmento padre. Ejemplo: Para una persona P es posible ms de un registro del infotipo 6, o sea, ms de un segmento E1P0006. La transaccin utilizada es WE30.

El tipo base IDOC, al igual que los segmentos, es necesario liberarla.

3.4. Asignacin del tipo base IDOC al tipo de mensaje

Los segmentos ya estn relacionados con el tipo base IDOC, ahora falta relacionar el tipo base IDOC con el tipo de mensaje. Para ello se utiliza la transaccin WE82.

3.5. Creacin del mdulo de funcin outbound

La creacin del IDOC que replica la informacin se realiza mediante un mdulo de funcin de salida en el sistema emisor. A la hora de crear un mdulo de funcin no estndar de salida es recomendable tomar uno estndar como ejemplo. As identificaremos de forma rpida los mdulos de funciones ms tiles. Ejemplo:

IDOC_REDUCTION_SEGMENT_TEST ( Comprueba que un segmento est reducido.

IDOC_REDUCTION_FIELD_REDUCE ( Si el segmento est reducido, se verifican los campos a replicar.

ALE_MODEL_INFO_GET ( Obtiene la informacin sobre el escenario ALE detallada en la transaccin BD64.

READ_OBJECT_VALUE ( Lee el valor de los filtros ALE indicados en la transaccin BD64.

MASTER_IDOC_DISTRIBUTE ( Realiza la creacin del IDOC.

CHANGE_POINTERS_READ ( Lee los punteros de modificacin no procesados para el tipo de mensaje en cuestin.CHANGE_POINTERS_STATUS_WRITE ( Marca los punteros de modificacin como procesdos.

La idea bsica de un mdulo de funcin de salida es rellenar los segmentos del IDOC (estructuras de datos) para posteriormente crear el IDOC y distribuirlo al sistema receptor.3.6. Configuracin tipo de mensaje como reducible

En este punto de la parametrizacin, se ha de indicar al sistema qu mdulo de funcin se va a utilizar para la creacin del IDOC, es decir, el mdulo de funcin outbound. La transaccin utilizada es BD60. En la misma, se puede parametrizar el tipo de mensaje ALE como reducible. Un mensaje reducido utiliza el mismo tipo base IDOC del mensaje ALE que toma como patrn, pero utiliza nicamente los campos seleccionados.

3.7. Creacin del mdulo de funcin inbound

La integracin de la informacin en el sistema receptor se realiza mediante un mdulo de funcin de salida. A la hora de crear un mdulo de funcin no estndar de entrada es necesario mover la informacin que contiene el idoc en estructuras intermedias para informar al mdulo de funcin o BAPI que realiza la integracin en el sistema receptor. A a es necesario marcar el status del IDOC, dependiendo del cdigo de retorno recibido. La interfase de este mdulo de funcin es igual siempre.

3.8. Asignacin de mdulo de funcin a tipo de mensaje y tipo base IDOC

Una vez creado el mdulo de funcin inbound en el sistema receptor de la informacin, mediante la transaccin WE57 se relaciona el tipo de mensaje ALE, su tipo base IDOC, el tipo de mensaje y el mdulo de funcin que va a utilizar para integrar la informacin en el sistema.

3.9. Cdigo de operacin de entrada

El cdigo de operacin de entrada es una etiqueta a la que se le asigna un mdulo de funcin y un tipo de mensaje. El cdigo de operacin de entrada va asociado al mensaje ALE, de manera que al generar los acuerdos de interlocutor de forma automtica, el sistema utiliza el cdigo de operacin indicado para cada tipo de mensaje. En caso de desear utilizar otro cdigo de operacin se pueden modificar los acuerdos de interlocutor manualmente.

Este cdigo de operacin es el que se utiliza en los acuerdos de interlocutor para indicar que el mensaje ALE utiliza un mdulo de funcin inbound determinado.

3.10. Preparar sistemas lgicos

Una vez conocidos los sistemas entre los que va a replicar la informacin se preparan los sistemas lgicos. Un sistema lgico es solamente una etiqueta identificativa de cada entorno. Cada mandante ha de disponer de un sistema lgico, ya que en caso contrario no es posible la parametrizacin de una interfase ALE.

Para realizar este tipo de parametrizacin se utiliza la transaccin SALE. En ella podemos asignar un sistema lgico al mandante en el que estamos trabajando. Tambin es necesario nombrar todos los sitemas lgicos a los que vamos a enviar datos desde nuestro sistema emisor. (Tabla TBDLS).

3.11. Creacin de destinos RFC

La comunicacin entre los sistemas implicados se realiza mediante conexiones RFC tipo 3. El nombre del destino RFC ha de coincidir con el nombre del sistema lgico asociado al mandante en el que estamos realizando la parametrizacin. De esta forma, el sistema es capaz de generar de forma automtica la puerta lgica para el proceso IDOC y los acuerdos de interlocutor. En caso contrario se debera realizar de forma manual. Se realiza mediante la transaccin SM59.

3.12. Creacin del escenario ALE

El siguiente paso es la creacin de un modelo de distribucin. En l se indica el tipo de mensaje ALE empleado, el sistema emisor y el receptor y los filtros ALE a utilizar. Este punto de la parametrizacin se realiza mediante la transaccin BD64. Con esta misma transaccin se generan acuerdos de interlocutor en el sistema emisor, se distribuye el escenario al sistema receptor y se generan los acuerdos de interlocutor en el mismo receptor.

Cada mensaje ALE estndar dispone de unos filtros estndar. En caso de ser necesario es posible crear nuevos filtros para un tipo de mensaje.

3.13. Pruebas unitarias

Para confirmar la correcta parametrizacin del escenario ALE es conveniente realizar una serie de pruebas unitarias. Para ello se utiliza el envo bajo peticin. Mediante esta tcnica se realiza la replica de datos de manera manual.

En que casos la ejecucin bajo esta tcnica es recomendable:

En una carga inicial de datos maestros a un sistema virgen.

En el caso de que se aada un objeto nuevo a replicar en el modelo de distribucin, deber realizarse una carga inicial para este objeto en los entornos destino ya que los punteros de modificacin slo recogen el mantenimiento a partir del momento en que se ha realizado una carga previa de ese objeto. Estos objetos nuevos podran haberse mantenido en un periodo anterior.)

Adems en algn momento podra darse el caso de que se quisiera hacer una nueva carga de datos.

Mediante la transaccin BALE se accede al envo de datos maestros. De esta forma generamos un IDOC en el sistema emisor con el dato seleccionado y se replica en el sistema emisor. Una parametrizacin correcta viene indicada por los status del IDOC.

STATUSDescripcin

01Idoc creado.

03Transferencia de datos a puerta OK.

26Error de sintaxis en IDOC ( Salida ).

29Error en servicio ALE.

30IDOC listo p. envo ( Servicio ALE ).

50Idoc creado.

51No se ha contabilizado documento de aplicacin.

52Documento de aplicacin contabilizado de forma incompleta.

53Documento de aplicacin contabilizado.

60Error de sintaxis en IDOC (Entrada).

63Error al traspasar IDOC a la aplicacin.

64IDOC listo p. traspaso a la aplicacin.

65Error en servicio ALE.

3.14. Replica de la informacin

Se pueden diferenciar dos procesos o tcnicas diferentes a la hora de replicar la informacin.

Punteros de modificacin.

Bajo peticin. (Pruebas unitarias).

Punteros de modificacin. Utilizando esta tcnica la replica de la informacin se produce de una manera automatizada de manera diaria. Esto se consigue mediante la planificacin de jobs que se ejecutan cada da.

Esta tcnica consiste en que desde el sistema emisor se ejecuta un programa que realiza la replica de la informacin. Este programa realiza una evaluacin de los punteros de modificacin, en los cuales queda grabada cualquier modificacin que se haya producido durante el da. La ejecucin de este programa se realizar en fondo a travs de un job. Durante la ejecucin de dicho programa se crearn los IDOCs que sern enviados automticamente al sistema destino. Dentro de estos IDOCs encontraremos registradas las modificaciones que se ha producido en el sistema origen y que son susceptibles a ser replicadas. . El programa ABAP encargado de recoger los punteros de modificacin, a partir de los cuales generar los IDOCs es el RBDMIDOC.

Es necesario realizar la activacin de los punteros de modificacin generales y la activacin especfica para cada mensaje. Las transacciones son la BD61 y BD50 respectivamente.

4. Interfase ALE-BAPI

Se denomina interfase ALE-BAPI aquella en la que disponemos de un business object, con un mtodo el cual tiene asociado una BAPI. nicamente con esta informacin, el sistema genera una interfase ALE completa.

4.1. Generacin de la interfase ALE

La interfase ALE se genera mediante la transaccin BDBG. Para ello, es necesario una BAPI asociada a un mtodo de un business object objeto. Esta BAPI debe de disponer de un parmetro export o tables de retorno como requisito indispensable para que sea posible generar la interfase. Este aspecto es necesario indicarlo en la transaccin SWO1 en el botn de parmetros posicionndose en el mtodo al cual se ha asociado la BAPI creada o estndar.

Si la BAPI utilizada no es estndar se necesita crear un business object como copia del business object estndar. En ocasiones no es posible crear un subtipo de ste porque a la hora de liberar el objeto hijo no sera posible si el objeto padre no est liberado. En caso de no ser as, es ms conveniente la creacin de un subtipo. De esta manera se crea un mtodo nuevo en el business object copiado. A este mtodo le asociamos la BAPI creada para la lgica de proceso. Este mtodo se implementa y se libera. El objeto tambin deber implementarse y liberarse. En caso de que la BAPI utilizada sea estndar y ya est incluido en un mtodo de un business object estndar, esta parte de parametrizacin no sera necesaria.

La interfase ALE generada a partir de la transaccin BDBG contiene: tipo base IDOC, mensaje ALE, segmentos, mdulo de funcin de entrada y salida. Adems vincula el tipo base IDOC con el tipo de mensaje. Los mdulos de funcin se crean en el sistema donde se ejecuta la transaccin BDBG, por lo que si se desea establecer una interfase ALE entre dos sistemas SAP es necesario copiar el mdulo de funcin de entrada en el sistema receptor, as como el tipo de mensaje ALE, segmentos, etc. De esta forma, es ms conveniente ejecutar la transaccin BDBG en el sistema receptor tambin.

Los segmentos generados depender de los campos clave del objeto creado (ZISUPARTNE). Todos los campos clave se crearn en el segmento de cabecera del tipo base IDOC, excepto si este campo clave es un parmetro de la bapi (import o tables) declarada como una estructura. De esta forma se generar un segmento hijo con todos los campos de esta estructura. Asimismo, es necesario indicar los parmetros import, export y tables de la BAPI en los parmetros del mtodo al cual est asociada la BAPI.Tanto el tipo de base IDOC como los segmentos generados de forma automtica es necesario liberarlos mediante las transacciones WE30 y WE31 respectivamente.

4.2. Asignacin de mdulo de funcin a tipo de mensaje y tipo base IDOC

Mediante la transaccin WE57 se relaciona el tipo de mensaje ALE, su tipo base IDOC y el mdulo de funcin que va a utilizar para integrar la informacin en el sistema.

Se asigna el tipo de mensaje ALE al mdulo de funciones BAPI_IDOC_INPUT1. Este tipo de parametrizacin la realiza la transaccin BDBG de forma automtica.

4.3. Cdigo de operacin de entrada

Ahora ya podemos definir un cdigo de entrada para procesar los IDOCs de entrada. Transaccin WE42. Se asigna el mensaje ZISUACCOUNT (que est ligado al tipo base ZISUACCOUNT01) al mdulo de funciones BAPI_IDOC_INPUT1, mediante el cdigo de operacin BAPI.

Esta parametrizacin es dependiente de mandante por lo que hay que realizarla en el mandante donde se va a montar el escenario.

Para ligar el cdigo de operacin de entrada con el mdulo de funcin de entrada generado en la interfase es necesario una entrada en la tabla TBDBA. La BAPI_IDOC_INPUT1 chequea la existencia de esta entrada, para obtener el mdulo de funcin outbound o inbound relacionado con cada tipo de mensaje.

4.4. Preparar sistemas lgicos

Una vez conocidos los sistemas entre los que va a replicar la informacin se preparan los sistemas lgicos. Un sistema lgico es solamente una etiqueta identificativa de cada entorno. Cada mandante ha de disponer de un sistema lgico, ya que en caso contrario no es posible la parametrizacin de una interfase ALE.

Para realizar este tipo de parametrizacin se utiliza la transaccin SALE. En ella podemos asignar un sistema lgico al mandante en el que estamos trabajando. Tambin es necesario nombrar todos los sitemas lgicos a los que vamos a enviar datos desde nuestro sistema emisor. (Tabla TBDLS).

4.5. Creacin de destinos RFC

La comunicacin entre los sistemas implicados se realiza mediante conexiones RFC tipo 3. El nombre del destino RFC ha de coincidir con el nombre del sistema lgico asociado al mandante en el que estamos realizando la parametrizacin. De esta forma, el sistema es capaz de generar de forma automtica la puerta lgica para el proceso IDOC y los acuerdos de interlocutor. En caso contrario se debera realizar de forma manual. Se realiza mediante la transaccin SM59.

4.6. Creacin del escenario ALE

El siguiente paso es la creacin de un modelo de distribucin. En l se indica el tipo de mensaje ALE empleado, el sistema emisor y el receptor y los filtros ALE a utilizar. Este punto de la parametrizacin se realiza mediante la transaccin BD64. Con esta misma transaccin se generan acuerdos de interlocutor en el sistema emisor, se distribuye el escenario al sistema receptor y se generan los acuerdos de interlocutor en el mismo receptor.

Cada mensaje ALE estndar dispone de unos filtros estndar. En caso de ser necesario es posible crear nuevos filtros para un tipo de mensaje.

4.7. Pruebas unitarias

Para confirmar la correcta parametrizacin del escenario ALE es conveniente realizar una serie de pruebas unitarias. Para ello se utiliza el envo bajo peticin. Mediante esta tcnica se realiza la replica de datos de manera manual.

En que casos la ejecucin bajo esta tcnica es recomendable:

En una carga inicial de datos maestros a un sistema virgen.

En el caso de que se aada un objeto nuevo a replicar en el modelo de distribucin, deber realizarse una carga inicial para este objeto en los entornos destino ya que los punteros de modificacin slo recogen el mantenimiento a partir del momento en que se ha realizado una carga previa de ese objeto. Estos objetos nuevos podran haberse mantenido en un periodo anterior.)

Adems en algn momento podra darse el caso de que se quisiera hacer una nueva carga de datos.

Mediante la transaccin BALE se accede al envo de datos maestros. De esta forma generamos un IDOC en el sistema emisor con el dato seleccionado y se replica en el sistema emisor. Una parametrizacin correcta viene indicada por los status del IDOC.

STATUSDescripcin

01Idoc creado.

03Transferencia de datos a puerta OK.

26Error de sintaxis en IDOC ( Salida ).

29Error en servicio ALE.

30IDOC listo p. envo ( Servicio ALE ).

50Idoc creado.

51No se ha contabilizado documento de aplicacin.

52Documento de aplicacin contabilizado de forma incompleta.

53Documento de aplicacin contabilizado.

60Error de sintaxis en IDOC (Entrada).

63Error al traspasar IDOC a la aplicacin.

64IDOC listo p. traspaso a la aplicacin.

65Error en servicio ALE.

4.8. Replica de la informacin

Se pueden diferenciar dos procesos o tcnicas diferentes a la hora de replicar la informacin.

Punteros de modificacin.

Bajo peticin. (Pruebas unitarias).

Punteros de modificacin. Utilizando esta tcnica la replica de la informacin se produce de una manera automatizada de manera diaria. Esto se consigue mediante la planificacin de jobs que se ejecutan cada da.

Esta tcnica consiste en que desde el sistema emisor se ejecuta un programa que realiza la replica de la informacin. Este programa realiza una evaluacin de los punteros de modificacin, en los cuales queda grabada cualquier modificacin que se haya producido durante el da. La ejecucin de este programa se realizar en fondo a travs de un job. Durante la ejecucin de dicho programa se crearn los IDOCs que sern enviados automticamente al sistema destino. Dentro de estos IDOCs encontraremos registradas las modificaciones que se ha producido en el sistema origen y que son susceptibles a ser replicadas. . El programa ABAP encargado de recoger los punteros de modificacin, a partir de los cuales generar los IDOCs es el RBDMIDOC.

Es necesario realizar la activacin de los punteros de modificacin generales y la activacin especfica para cada mensaje. Las transacciones son la BD61 y BD50 respectivamente.

ANEXO 1. Filtros ALE no estndar

Un tipo de mensaje ALE estndar dispone de una serie de filtros estndar. Estos filtros marcan la informacin que se replica entre los sistemas. En caso de que exista la necesidad de realizar un filtrado de la informacin y no se disponga de un filtro estndar para ello, es posible la creacin de filtros ALE no estndar. Tambin es posible filtrar la informacin que se replica eliminando segmentos del tipo base IDOC mediante filtros.

La creacin de filtros ALE no estndar se realiza mediante la transaccin BD95.

Posteriormente es necesario indicar que el filtro no estndar va a ser utilizado por un determinado tipo de mensaje ALE. Transaccin BD59.

ANEXO 2. Reglas de conversinDentro de la parametrizacin especfica de cada mensaje ALE, cabe la posibilidad de realizar reglas de conversin. Estas reglas se aplican sobre campos de los segmentos del tipo base IDOC, convirtiendo sus valores utilizando expresiones lgicas. Ejemplo: Es posible cambiar el campo BUKRS cuando su valor sea igual a 0102 al valor 0044. Se realiza mediante la transaccin SALE.

ANEXO 3. Herramienta Test.

Este tipo de herramienta estndar permite simular la entrada de un IDOC al sistema. Es til en caso de interfases ALE con sistemas no SAP, ya que se pueden realizar pruebas unitarias sin necesidad de disponer del sistema no SAP.

Esta herramienta est disponible en la transaccin WE19.

ANEXO 4. Reduccin de mensajesLa transaccin utilizada es la BD60, donde se parametriza el tipo de mensaje ALE como reducible. Un mensaje reducido utiliza el mismo tipo base IDOC del mensaje ALE que toma como patrn, pero utiliza nicamente los campos seleccionados.

Para indicar los campos que deseamos seleccionar, se utiliza la transaccin BD53. En ella se crea el mensaje reducido.

ANEXO 5. Comunicacin con un sistema NO SAP

En caso de que en la interfase se vea implicado un sistema NO SAP, es necesario utilizar un destino RFC tipo TCP/IP. Destinos del tipo T son enlaces con programas externos que utilizan la RFC API para recibir "Remote Function Calls". Es necesario introducir el nombre host y el nombre de la va de acceso del programa a iniciar. Con la seleccin del lugar del programa (explcito, servidor, usuario) es posible especificar el canal de comunicacin.

ANEXO 6. Objetos de modificacin

Los objetos de modificacin son los objetos que parametrizamos para que sean susceptibles de generar punteros de modificacin a la hora de producirse un cambio en su valor. Es decir, cuando cambie el valor de ciertos campos que afectan al objeto se generar un puntero de modificacin del tipo de mensaje ALE creado. Normalmente se utiliza para tipos de mensajes ALE no estndar. La transaccin utilizada es BD52.

ANEXO 7. Ampliacin

Si se desea replicar ms informacin de la que se dispone en un mensaje estndar, es posible realizar un ampliacin del mensaje. sta ir asociada al tipo de base IDOC estndar, al mensaje estndar pero contendr un segmento desarrollado no estndar conteniendo la informacin que se desea replicar. La ampliacin se crea con la transaccin WE30.

Para asociarla al tipo base IDOC y tipo de mensaje estndar se utiliza la transaccin WE82.

Tambin es necesario indicar el uso de la ampliacin en los acuerdos de interlocutor. Esta indicacin se realiza de forma manual. Transaccin WE20.

28

_989682591.doc