ALE – IDOCS
ALE - IDOCS
Confidencial
Softtek 2009
Página 1 de 27
ALE – IDOCS Tabla de contenidos INTRODUCCIÓN INTRODUCCIÓ N – DEFINICIONES DEFINICIONES.......................................................................................................................3 .......................................................................................................................3 IDOCS............................................................................................................................................................................5 PROCESAMIENTO..............................................................................................................................................................5 SISTEMAS LÓGICOS..........................................................................................................................................................6 PUNTEROS DE MODIFICACIÓN:...........................................................................................................................................7 GENERACIÓN DE IDOCS DESDE PROGRAMA ABAP:..........................................................................................................9 MODELO DE DISTRIBUCIÓN. ...........................................................................................................................................11 CREACIÓN DE CONEXIONES RFC Y PUERTAS.....................................................................................................................12 ACUERDO DE INTERLOCUTORES. ......................................................................................................................................14 EXTENSIÓN DE IDOCS........................................................................................................................................... IDOCS...........................................................................................................................................16 16 3.1.CONCEPTO..............................................................................................................................................................16 3.2.CONFIGURACIÓN PROCESO OUTBOUND. ......................................................................................................................18 3.3.CONFIGURACIÓN PROCESO I NBOUND...........................................................................................................................19 CONFIGURACIÓN CONFIGURAC IÓN IDOCS Z ............................................................................................................................... ..19 4.1.CONCEPTO..............................................................................................................................................................19 4.2.CREACIÓN DE SEGMENTOS........................................................................................................................................19 4.3.CREACIÓN DE IDOC...............................................................................................................................................20 4.4.CREACIÓN DEL MENSAJE Z........................................................................................................................................21 4.5.ACUERDO DE I NTERLOCUTORES..................................................................................................................................23 4.6.EJECUCIÓN DEL IDOC............................................................................................................................................24 TRANSACCIONES....................................................................................................................................................26 5.1.IDOCS....................................................................................................................................................................26 5.2.PUNTEROS DE MODIFICACIÓN....................................................................................................................................26
Confidencial
Softtek 2009
Página 2 de 27
ALE – IDOCS Introducción – Definiciones ALE: Es la tecnología utilizada por SAP ERP para soportar Procesos de Negocios Distribuidos en aplicaciones y componentes separados dentro del Landscape de la Empresa. Utiliza los Escenarios de Negocio y los módulos de Funciones que permiten intercambiar datos desde/hacia otro SAP ERP sin la necesidad de realizar desarrollos.
Ejemplo de negocio Las empresas a nivel mundial, por lo general estructuran su negocio usando varios clientes en un sistema SAP, a menudo también utilizan varios sistemas SAP. Con frecuencia, estos son unidos por sistemas para aplicaciones específicas de otros proveedores.
Una oficina central, filiales y sucursales de ventas y distribución son, a menudo, sistemas separados técnicamente. Cada subsistema se comunica no sólo con los demás miembros del grupo de sistemas, sino también con Partners de negocios, tales como clientes, proveedores, bancos y autoridades públicas. En el ejemplo que se muestra arriba, los datos maestros para la totalidad de la red de la empresa se crean y se mantienen en la oficina central únicamente. Los nuevos datos maestros y los cambios a los datos existentes son enviados regularmente a los sistemas inferiores de las ramas de distribución y ventas y producción. El departamento central de compras requiere a los proveedores, las ramas de ventas y distribución reciben pedidos de los clientes y envía estos a producción para que se fabrique. La Comunicación debe ser electrónica a través de todos los procesos. ALE puede ser usado dentro de una empresa para la administración central de datos maestros y transaccionales (entre otros usos): los datos son creados y modificados en sólo uno de los sistemas de la red de la empresa. Los datos se distribuyen de este sistema de mantenimiento a los sistemas inferiores, los registros de datos se envían en forma electrónica a cada uno de los destinatarios. Un ejemplo típico de esto es la administración centralizada de datos maestros.
Confidencial
Softtek 2009
Página 3 de 27
ALE – IDOCS En el escenario anterior, todos los datos maestros de materiales se crean en la oficina central y son distribuidos desde allí hacia los sistemas de ventas, distribución y producción. Sin embargo, ventas y distribución sólo debe recibir los registros maestros de productos terminados, mientras que producción debería recibir, tanto los datos maestros de materiales de producto terminado como de materia prima. Al configurar el escenario ALE, por lo tanto, es importante prestar atención a la jerarquía de distribución y, también, tener en cuenta el hecho de que no cualquier destinatario recibe todos los datos. En un escenario diferente, los departamentos en el sistema destino, son responsables del mantenimiento de ciertas partes de un registro maestro. En este caso, el registro maestro no deberá ser transferido en su totalidad, o tiene que haber una garantía de que los valores modificados localmente no pueden sobrescribirse si los registros de datos se transfieren de nuevo.
EDI: Permite la comunicación de procesos de negocios entre aplicaciones SAP R/3 y sistemas externos. Se quiere comunicar electrónicamente no sólo al interior de la empresa, sino también con sus socios comerciales. De esta manera, los datos de una orden creada en su propio sistema, puede ser transferida electrónicamente a un proveedor, quien, a su vez, envía una confirmación de pedido, una confirmación de embarque y, finalmente, una factura.
Generalmente, el intercambio de datos con partes externas (es decir, socios de negocios, bancos, o agencias de gobierno etc.), se realiza mediante el Intercambio Electrónico de Datos (Electronic Data Interchange EDI), no con ALE. Un documento electrónico es enviado en un formato específico de SAP, desde un sistema SAP a un subsistema EDI, llamado convertidor. El subsistema convierte este documento a un documento EDI, y lo envía al proveedor.
IDOCS: Son documentos (finalmente archivos planos) con una estructura definida, es la estructura donde se van a guardar los datos a enviar a los sistema back-end en un escenario de integración ALE. Permiten intercambiar información entre distintos sistemas. Un IDOC es por ej. Los datos de un proveedor o una oferta.
IDOC -> ALE -> Sistema back-End(SAP) Confidencial
Softtek 2009
Página 4 de 27
ALE – IDOCS
Su estructura esta definida de la siguiente manera: Cabeceras (Segmento de Control) - EDIDC Numero de Idoc, Tipo de Mensaje, Nombre de Idoc asociado, datos de usuario, etc Segmentos (Segmento de Datos) - EDID4 Nombre del Segmento, información en campo SDATA (Char 1000 Caracteres) Status (Segmento de Estado) – EDIDS Historial con los distintos estados por los que fue pasando el IDOC en el sistema Se generan Mediante: Datos Maestros: Punteros de Modificación Envío Forzado a través de Programas Standards o Z Datos de Customizing: A partir de Modificaciones en la SPRO Datos Transaccionales Control de Mensajes (MM y SD) Workflow (Eventos) Programas Específicos (FI – Ej : Programa de Pagos) Desarrollo de programas (Z) Outbound - Función MASTER_IDOC_DISTRIBUTE Inbound - Función EDI_DATA_INCOMING
•
•
•
•
•
•
Resumiendo los IDOCS son documentos, que se generan a partir de ciertos cambios en objetos de negocio definidos, y que luego mediante la capa ALE, esta información contenida en el IDOC , será transferida a los sistemas definidos dentro del modelo ALE.
IDOCS Procesamiento El procesamiento de un IDOC puede ser de 2 tipos: • •
Outbound Inbound
Outbound: Son los IDOCS que son enviados desde el sistema destino hacia el sistema receptor, se crean a partir de punteros de modificación, mensajes o mediante programas Z. Un proceso Outbound incluye: • • • •
Creación de Documento/Objeto en SAP Creación IDOC relacionado con documento creado Identificación de Interlocutor y Puerta Transferencia de IDOC a Sistema Externo vía puerta
Inbound: Son los IDOCS que son recibidos el es sistema destino, es decir un mismo IDOC será de OUTBOUND en el sistema de origen y será de INBOUND en el sistema destino.
Confidencial
Softtek 2009
Página 5 de 27
ALE – IDOCS
Un procesamiento de Inbound Incluye: • • •
Identificación de Interlocutor y Puerta de Entrada Creaciónde IDOC en Sistema Contabilización del documento/Objeto en SAP a partir del IDOC de entrada
Los IDOCS tanto de Inbound como Outboud van pasando por distintos estados desde el momento de su creación hasta el envió a los sistema destino. El estado del IDOC forma parte de la estructura de información del mismo, en caso de error, el análisis del segmento de estado nos dará una clara idea del tipo de error ocurrido en el procesamiento del IDOC. Estado
Significado
01
IDOC creado
03
Transferencia de datos a puerta OK
30
IDoc listo para envío (servicio ALE)
12
Expedición OK
29
Error en servicio ALE
39
IDOC en sistema destino (servicio ALE)
40
Documento de aplicación no creado en sistema destino
41
Documento de aplicación creado en sistema destino
50
IDOC añadido
51
No se ha contabilizado documento de aplicación
53
Documento de aplicación contabilizado
62
Traspasar IDOC a aplicación
64
IDOC listo para traspaso a la aplicación
68
Error, sin tratamiento posterior
69
El IDOC se ha tratado
70
Original de un IDOC que se ha tratado
Sistemas Lógicos Son los distintos sistemas que se van a comunicar en un escenario de integración ALE-IDOC, los sistemas lógicos se dan de alta en la transacción BD54, el nombre de los sistemas lógicos los podemos obtener mediante la transacción SCC4, debemos dar de alta el sistema lógico del emisor y el del receptor.
Confidencial
Softtek 2009
Página 6 de 27
ALE – IDOCS BD54:
SCC4:
Punteros de Modificación: Cada vez que se crean o modifican datos maestros, tal como datos maestros de materiales, proveedores, etc., el sistema escribe "punteros de modificación" (change pointers) como registro de cada una de estas modificaciones para cada documento. El reporte estándar RBDMIDOC es ejecutado a fin de procesar todas las entradas en la tabla de punteros de modificación. Para generar los IDocs, este programa llama a un módulo de función especifico para cada mensaje. • • • • •
Activar los punteros de modificación en forma global. Activar los punteros de modificación para nuestro tipo de mensaje. Definir los campos relevantes para la generación de punteros de modificación. Relacionar el tipo de mensaje con el módulo de función. Crear un módulo de función para leer los punteros de modificación y crear los Idocs.
Activación de punteros de modificación en forma global Transacción: BD61 Marcar el Flag: Puntero modificación general activado y grabar.
Confidencial
Softtek 2009
Página 7 de 27
ALE – IDOCS
Activación de punteros de modificación por Tipo de Mensaje Transacción: BD50 Agregar una entrada para el mensaje deseado, y marcarla como activa.
Definición de campos relevantes para la generación de Punteros de Modificación Transacción: BD52 Ingresar entradas para los campos sobre los cuales se quieran crear Punteros de Modificación, por Ej utilizar un campo Z como puntero de modificación Primero completar el tipo de mensaje y presionar continuar. Luego se desplegará una pantalla para ingresar los campos: - Objeto de Modificación -Tabla -Campo
Relación entre el Tipo de Mensaje y el Módulo de Función Transacción: BD60 En este paso se relaciona el tipo de mensaje con el módulo de función desarrollado para analizar/procesar los punteros de modificación. Ejecutar la transacción BD60 e ingresar una entrada para el tipo de mensaje deseado, y el módulo de función que se utilizará para procesar ese Puntero de Modificación. En otras palabras, cuando se ejecute el programa estándar RBDMIDOC para procesar los Punteros de Modificación y se detecte que uno de los campos que se insertaron en el paso anterior (campos relevantes para la generación de Punteros de Modificación) se modificó, se invocará a la función que se está definiendo en este paso.
Confidencial
Softtek 2009
Página 8 de 27
ALE – IDOCS Crear un módulo de función para leer los punteros de modificación y crear los Idocs Esta función contiene la lógica para la generación de los IDocs a partir de punteros de modificación. Es invocada desde el programa RBDMIDOC, a partir de la configuración realizada en el punto anterior. La lógica del programa contiene los siguientes pasos: 1- Leer los punteros de modificación generados usando la función CHANGE_POINTERS_READ. 2- Analizar los punteros de modificación para determinar cuáles documentos son válidos. 3- Determinar la clave del documento de aplicación del paso 2. 4- Seleccionar datos de aplicación de la base de datos, usando la clave de objeto identificada en el paso 3. 5- Completar la información del registro de control del IDoc. 6- Completar una tabla interna de estructura EDIDD con registros de datos para todos los segmentos. 7- Llamar al servicio de la capa ALE (MASTER_IDOC_DISTRIBUTE) para crear los datos en la base de datos. 8- Actualizar el estado de los punteros de modificación 9- Ejecutar un COMMIT WORK. Generalmente se utiliza una función estándar, salvo que se esté extendiendo un Idoc. Igualmente, en caso de estar extendiendo, lo que se hace generalmente es copiar una función estándar y agregarle la lógica necesaria para que se considere el segmento extendido al momento de crear el Idoc, o implementar un USER-EXIT o BADI en la función estándar para cargar los segmentos de la ampliación.
Creación de Idocs desde un Mensaje de Logística El proceso lógico de generación de Idocs de salida desde Mensajes de Logística es el siguiente: Un programa ABAP (desarrollo Z) o transacción estándar crea un mensaje en la tabla NAST. El mensaje es procesado por el programa ABAP estándar RSNAST00, el cual lee el mensaje desde la tabla NAST, y llama al módulo de función adecuado para crear el Idoc, invocando a la función MASTERIDOC_DISTRIBUTE. El Idoc es enviado a su destinatario al ejecutar el programa RSEOUT00. Se puede usar el concepto de Mensajes R/3 para disparar la creación de Idocs de la misma manera que se dispara la impresión de SapScripts. La tabla utilizada para esto es la NAST. Esta tabla guarda recordatorios escritos por aplicaciones. Estos recordatorios son llamados Mensajes (messages). Cada vez que una aplicación ve la necesidad de pasar información a un sistema externo, un mensaje es escrito en la tabla NAST. Un controlador de mensajes (message handler) eventualmente chequeará las entradas en esta tabla y ejecutará l a acción apropiada. Un mensaje NAST de salida es guardado en un solo registro en la tabla NAST. El registro guarda toda la información que es necesaria para crear el Idoc. Esto incluye, entre otras cosas, una clave de objeto para identificar al objeto procesado, el emisor y receptor del mensaje.
Generación de IDOCS desde programa ABAP: Los pasos a seguir para la creación de un IDoc de salida desde un programa ABAP son los siguientes: 1- Seleccionar la información de la base de datos de acuerdo a los parámetros de selección ingresados.
Confidencial
Softtek 2009
Página 9 de 27
ALE – IDOCS 2- Completar la información correspondiente al registro de control. 3- Completar una tabla interna de tipo EDIDD con los registros de datos de los segmentos correspondientes. 4- Llamar al servicio de la capa ALE (MASTER_IDOC_DISTRIBUTE) para crear los IDOCs en la base de datos. 5- Ejecutar COMMIT WORK. 6- Enviar el Idoc invocando al programa RSEOUT00. A continuación se detalla un ejemplo con los pasos 2, 3,4 y 5 * DECLARACION DE DATOS DATA: c_message_type LIKE edidc-mestyp VALUE 'ZINVRV',"Tipo Mensa c_base_idoc_type LIKE edidc-idoctp VALUE 'ZINVRV01',"Tipo de Id c_invrev_segname(7) TYPE C VALUE 'Z1INVRV', "Nombre Seg c_rcvprn LIKE edidc-rcvprn VALUE 'SAPBCD',"Interloc. IDOC_CONTROL LIKE EDIDC, T_COMM_CONTROL LIKE EDIDC OCCURS 0 WITH HEADER LINE, IDOC_DATA LIKE EDIDD OCCURS 0 WITH HEADER LINE. * CAMPOS DE CONTROL DEL IDOC
idoc_control-doctyp = c_message_type."Tipo Mensaje idoc_control-mestyp = c_message_type."Tipo Mensaje idoc_control-idoctp = c_base_idoc_type."Tipo de Idoc idoc_control-serial = space. idoc_control-direct = '1'. idoc_control-serial = sy-datum. idoc_control-serial = sy-uzeit. idoc_control-rcvprn = c_rcvprn"Nro Interlocutor Desti idoc_control-rcvprt = 'LS'"Tipo interlocutor dest APPEND idoc_control. * CAMPOS DE DATOS DEL IDOC * Esta sección la repite una vez por cada registro de datos a insertar * en el IDoc. * Indica cuál es el tipo de segmento IDOC_DATA-SEGNAM = C_INVREV_SEGNAME."Nombre Segmento * Completa los datos de la estructura del segmento CLEAR Z1INVRV. Z1INVRV-CAMPO_01 = VALOR_01 ... ... ... Z1INVRV-CAMPO_NN = VALOR_NN * Mueve la estructura con los datos del segmento al único campo de datos IDOC_DATA-SDATA = Z1INVRV."Datos del Segmento * Inserta el registro actual a la tabla interna de datos del Idoc APPEND IDOC_DATA.
Confidencial
Softtek 2009
Página 10 de 27
ALE – IDOCS *--- Call the distribute function with the required parameters CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING MASTER_IDOC_CONTROL = IDOC_CONTROL TABLES COMMUNICATION_IDOC_CONTROL = T_COMM_CONTROL MASTER_IDOC_DATA = IDOC_DATA EXCEPTIONS ERROR_IN_IDOC_CONTROL =1 ERROR_WRITING_IDOC_STATUS =2 ERROR_IN_IDOC_DATA =3 SENDING_LOGICAL_SYSTEM_UNKNOWN = 4 OTHERS = 5.
if sy-subrc = 0. COMMIT WORK. endif. Una vez completados estos pasos, queda creado el Idoc. El mismo se guarda físicamente en las tablas EDIDC y EDID4. Se lo puede ver desde la transacción WE05. Para enviar el Idoc a su destinatario, se invoca al programa RSEOUT00.
Modelo de distribución. 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. El escenario de distribución es la referencia para determinar qué datos serán replicados y quiénes serán los emisores y 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, el cual lo podemos llamar el sistema líder. Solo uno de los sistemas es el sistema líder, pero puede ser seteado para cualquiera de los interlocutores en cualquier momento, aún si el escenario ya se encuentra activo. El modelo de distribución se define en la transacción BD64.
Confidencial
Softtek 2009
Página 11 de 27
ALE – IDOCS
Creación de conexiones RFC y Puertas. Destinos RFC: Transacción SM59 Se define como se va a realizar la conexión con el sistema destino para el envío de los IDOCS Dependiendo del sistema destino, la conexión RFC será de distinto tipo..
Confidencial
Softtek 2009
Página 12 de 27
ALE – IDOCS
En el detalle de la conexión RFC definimos los datos técnicos de la conexión con el sistema destino.
Confidencial
Softtek 2009
Página 13 de 27
ALE – IDOCS Puertas: Las puertas o puertos son básicamente los canales por donde los IDOCS circulan en su camino hacia los sistemas destino. Los puertos se configuran en la transacción WE21.
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. En otras palabras, un puerto es un nombre lógico para un dispositivo de entrada/salida. Los programas se comunican con un puerto a través de una interfaz estándar. Los tipos de puertos más comunes son los siguientes:
Ficheros (File Interface) : Permite intercambiar Idocs a través de archivos del sistema operativo. El sistema que envía el IDoc crea un archivo en el file system. Luego notifica al sistema receptor vía RFC sincrónico que el archivo ha sido transferido, que está localizado en un determinado directorio, y que tiene un determinado nombre. SAP recomienda no usar nombres de archivos estáticos, dado que el archivo es sobreescrito cada vez que el Idoc se envía. Se recomienda usar el módulo de funciones EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y nro. de Idoc.
RFC Transaccional : Se usa para escenarios de distribución ALE. El nombre del puerto se puede definir manualmente o dejar que SAP lo elija. Además del puerto, hay que definir el destino RFC, que se asocia al puerto.
Archivo 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 para que genere los nombres del archivo en forma dinámica.
XML-HTTP : En vez de definir el nombre del archivo XML, se especifica un destino RFC.
Acuerdo de interlocutores. Un interlocutor ALE es un sistema SAP remoto o un sistema legacy con el que se intercambian datos. El acuerdo de interlocutor especifica varias de las características de los datos que se intercambian incluyendo el modo de operación y la organización o persona responsable por el manejo de los errores. 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. Este
Confidencial
Softtek 2009
Página 14 de 27
ALE – IDOCS acuerdo es lo que se llama Acuerdo de Interlocutor, y es lo que le informa al receptor de la estructura de los datos enviados y cómo los contenidos deben ser interpretados. La 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 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. Mediante la transacción WE20 se crea el acuerdo de interlocutor con el sistema lógico.
Confidencial
Softtek 2009
Página 15 de 27
ALE – IDOCS
Extensión de IDOCS 3.1.
Concepto
Las ampliaciones de IDocs son componentes que se utilizan para extender tipos de IDoc base, ya existentes, de una forma predefinida. Estas extensiones sólo pueden ser realizadas por el cliente ya que los tipos de ampliación no son proporcionados por SAP. Para crear un tipo de ampliación: Transacción: WE30. En el editor de IDOC, elegir el componente Tipo de ampliación e introducir el nombre en el campo Objeto.
Seleccionar Objeto desarrollo Crear . En éste momento, la ventana de diálogo Crear un tipo de ampliación se mostrará por pantalla. Elegir una de las siguientes tres opciones: Crear nuevo. Crear como copia. Crear como sucesor.
Confidencial
Softtek 2009
Página 16 de 27
ALE – IDOCS
Introducir los nombres de la personas responsables así como una breve descripción del nuevo tipo de ampliación a crear. Seleccionar Continuar . Para añadir segmento ampliado a un segmento de referencia, colocar el cursor sobre el segmento de referencia siguiente a donde se pretenda añadir el nuevo segmento y seleccionar Crear . Aparecerá un mensaje indicando que los segmentos creados después de un segmento de referencia sólo pueden ser creados como segmentos hijos.
La secuencia en la cual aparecen los segmentos de referencia en el tipo de ampliación es irrelevante. Lo realmente importante es que dichos segmentos existan en el tipo de IDoc base que está siendo ampliado.
Una vez creada la ampliación la misma debe ser liberada
Confidencial
Softtek 2009
Página 17 de 27
ALE – IDOCS
Las ampliaciones de cliente realizadas utilizando tipos de ampliación pueden soportarse cuando el sistema se actualice a una nueva versión R/3. Los sucesores a tipos de I Doc base de versiones anteriores se combinan automáticamente con los tipos de ampliación que ya están siendo utilizados. No se requiere un mantenimiento manual. Los tipos de IDoc base implementados por el cliente y sus ampliaciones permanecen sin cambios en la actualización.
3.2.
Configuración proceso Outbound.
Por cada segmento extendido, tiene que haber una extensión en el código del módulo de función de outbound, que inserte los datos indicados en la extensión del segmento. El programa o función que genere el Idoc puede o no ser un estándar SAP. En caso de serlo, habrá que insertar el código necesario para manejar las extensiones en una User Exit. Para hacer esto usar la transacción CMOD. Si es un programa Z, solo habrá que actualizarlo para que considere la extensión. Por otro lado, habrá que actualizar los Acuerdos de Interlocutores que utilicen el Idoc extendido, especificando el nombre de la extensión creada.
Confidencial
Softtek 2009
Página 18 de 27
ALE – IDOCS 3.3.
Configuración proceso Inbound.
Por cada segmento extendido, tiene que haber una extensión en el código del módulo de función de inbound, que considere el tipo de segmento extendido recibido entre los datos para poder procesarlo. El programa o función que genere el Idoc puede o no ser un estándar SAP. En caso de serlo, habrá que insertar el código necesario para manejar las extensiones en una User Exit. Para hacer esto usar la transacción CMOD. Si es un programa Z, solo habrá que actualizarlo para que considere la extensión. Por otro lado, habrá que actualizar los Acuerdos de Interlocutores que utilicen el Idoc extendido, especificando el nombre de la extensión creada.
Configuración IDOCS Z 4.1. Concepto. Hay casos dependiendo de las necesidades o estructuras de información de los procesos de negocio, en los cuales los IDOCS estándar de SAP no nos van a servir. Esta problemática se soluciona mediante la creación de un IDOC Z.
4.2. Creación de Segmentos. Como primer paso debemos crear los segmentos que estarán contenidos en el IDOC Z. Lo segmentos se crean mediante el editor de segmentos, transacción WE31.
Aquí definimos el nombre del segmento a crear y la estructura de datos del mismo.
Confidencial
Softtek 2009
Página 19 de 27
ALE – IDOCS Creado el segmento y su estructura de datos debemos liberarlo para que el mismo pueda ser utilizado en la definición del IDOC Z.
4.3. Creación de IDOC. Con el segmento correctamente creado y liberado procedemos a la creación del IDOC, mediante la transacción WE30.
El IDOC puede ser creado haciendo referencia a uno ya existente o utilizar los segmentos creados en el paso anterior.
Confidencial
Softtek 2009
Página 20 de 27
ALE – IDOCS
Asignamos el segmento Z creado.
4.4. Creación del mensaje Z. Como vimos en capítulos anteriores todo IDOC estándar esta relacionado a un tipo de mensaje, por ejemplo el caso para la réplica de datos maestros de Proveedores se utiliza el mensaje CREMAS en cual esta relacionado al IDOC CREMAS01, el cual contiene la estructura de datos del proveedore.
Confidencial
Softtek 2009
Página 21 de 27
ALE – IDOCS En el caso de un IDOC Z tenemos que crear el correspondiente mensaje Z como se detalla a continuación, mediante la transacción WE81.
Agregamos el mensaje Z.
Ahora debemos enlazar el mensaje creado con IDOC creado en el paso anterior.
Establecemos la relación entre el tipo del IDOC creado, y el mensaje. Con esto ya tenemos creado el IDOC Z ahora debemos configurar ALE para el IDOC creado.
Confidencial
Softtek 2009
Página 22 de 27
ALE – IDOCS 4.5. Acuerdo de Interlocutores. Cabe aclarar que previo a la creación del cuerdo de interlocutores, deben crearse los Sistemas Lógicos, el modelo de distribución y la creación de conexión RFC y puertas. Estas configuraciones no difieren de las utilizadas en un IDOC estándar. Como vimos anteriormente el acuerdo de interlocutores se define mediante de la transacción WE20
Ahora solo resta agregar el mensaje y IDOC Z, creados en los pasos anteriores.
Confidencial
Softtek 2009
Página 23 de 27
ALE – IDOCS
4.6. Ejecución del IDOC El IDOC Z puede ser ejecutado desde cualquier aplicación ABAP, a través de la función MASTER_IDOC_DISTRIBUTE, a continuación se ejemplifica como se invocaría desde un programa ABAP. REPORT ZTEST_IDOC. data: lt_edidc like edidc occurs 0 with header line. data: lt_EDIDD like EDIDD occurs 0 with header line. data: wa_edidc type EDIDC. data: it_Header like ZINVHEADER01. "WE31 DATA: IT_DETAIL LIKE ZINVDETAIL01. "WE31 * Cargo los datos de control wa_edidc-mandt = sy-mandt. wa_edidc-doctyp = 'ZINVOICE' wa_edidc-direct = '1'.-> DIRECCIÓN OUTBOUND wa_edidc-rcvpor = 'FIINV'."->PUERTA DEL RECEPTOR
Confidencial
Softtek 2009
Página 24 de 27
ALE – IDOCS wa_edidc-rcvprt = 'LS'. wa_edidc-rcvprn = 'FINVOICE'.-> SISTEMA LÓGICO RECEPTOR wa_edidc-mestyp = 'ZINVOICE'.-> MENSAJE wa_edidc-idoctp = 'ZINVOICE01'.->TIPO DE IDOC it_Header-BLDAT = '12.02.2003'. it_Header-PAVAL = '133'. lt_edidd-segnum = 1. lt_edidd-segnam = 'ZINVHEADER01'.->SEGMENTO lt_edidd-mandt = sy-mandt. lt_edidd-sdata = IT_HEADER. APPEND lt_edidd. CLEAR lt_edidd. IT_DETAIL-SUBTOTAL = 123. IT_DETAIL-TOTALFAC = 123. IT_DETAIL-ZUONR = '1234'. IT_DETAIL-WRBRT = 123. IT_DETAIL-ZEILE = '12345'. lt_edidd-segnum = 2. lt_edidd-segnam = 'ZINVDETAIL01'. lt_edidd-mandt = sy-mandt. lt_edidd-sdata = IT_DETAIL. APPEND lt_edidd. CLEAR lt_edidd. BREAK-POINT. CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING MASTER_IDOC_CONTROL = wa_edidc * OBJ_TYPE = '' * CHNUM = '' TABLES COMMUNICATION_IDOC_CONTROL = lt_edidc MASTER_IDOC_DATA = LT_EDIDD * EXCEPTIONS * ERROR_IN_IDOC_CONTROL =1 * ERROR_WRITING_IDOC_STATUS =2 * ERROR_IN_IDOC_DATA =3 * SENDING_LOGICAL_SYSTEM_UNKNOWN =4 * OTHERS =5 . IF SY-SUBRC <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. Una vez ejecutado el programa deberíamos acceder a la transacción WE05 para ver el status del IDOC creado en el paso anterior.
Confidencial
Softtek 2009
Página 25 de 27
ALE – IDOCS
Transacciones. 5.1. Idocs A continuación se listan las principales transacciones para la configuración de IDOCS. Transacción
Función Opciones de customizing de ALE Mantenimiento de conexiones RFC Mantenimiento del Modelo de Distribución Generar perfiles de interlocutores Mantener acuerdo de Interlocutores Definición de puertas de Salida Editor de segmentos Descripción de campos de segmentos Herramienta para testeo de IDOCS Lista de IDOCS procesados Buscar IDOC en base de datos Monitor de status para mensajes ALE Disparar manejo de errores para IDOCS IDOC & EDI Basis
SALE SM59 BD64 WE82 WE21 WE20 WE30 WE60 WE19 WE05 WE09 BD87 BD73 WEDI
5.2. Punteros de Modificación Confidencial
Softtek 2009
Página 26 de 27
ALE – IDOCS A continuación se listan la principales transacciones para la administración de punteros de modificación. Transacción BD50 BD61 BD52 BD21
Confidencial
Función Activar puntero para un tipo de mensaje Activar puntero general Agregar campo a mensaje Generar IDOC a partir de puntero de modif.
Softtek 2009
Página 27 de 27
