Manual para la creacion de IDOCs 1 Qué es un Idoc? 2 Definición de la estructura de Idocs, segmentos de control, datos y estado. 3 Creación de un nuevo tipo de IDoc en SAP. 3.1 – Creación de los elementos de datos 3.2 – Creación de Segmentos 3.3 – Creación del Tipo Base de IDoc 3.4 – Liberación del Tipo de Segmento y Tipo Básico de IDoc 3.5 – Transporte de Segmentos y Tipo Base de IDocs 4 Extensión de un IDoc. 4.1 Configuración el procesamiento Outbound 4.2 Configuración el procesamiento Inbound 5 Creación de destinos RFC, puertos y sistemas lógicos. 5.1 Definición de Destinos RFC 5.2 Definición de puerta. 5.3 Definición de sistemas lógicos 5.3.1 Asignar sistema lógico a mandante 6 Creación de los acuerdos de interlocutores. 7 Creación de un nuevo tipo de Mensaje en SAP. 8 Relación entre un tipo de Mensaje y un Tipo de IDoc 9 Creación de un modelo de distribución. 10 (G) Creación de un Idoc de salida 10.1 Creación de Idocs desde un programa ABAP 10.2 Creación de Idocs utilizando Punteros de Modificación (Change Pointers) 10.2.1 Activación de punteros de modificación en forma global 10.2.2 Activación de punteros de modificación por Tipo de Mensaje 10.2.3 Definición de campos relevantes para la generación de Punteros de Modificación 10.2.4 Relación entre el Tipo de Mensaje y el Módulo de Función 10.2.5 Crear un módulo de función para leer los punteros de modificación y crear los Idocs. 10.3 Creación de Idocs desde un Mensaje de Logística 11 Creación de un Idoc de entrada 11.1 Configuración de Workflow 11.1.1 Crear un nuevo Objeto de Aplicación Idoc 11.1.2 Crear una nueva tarea basada en el Objeto de Aplicación Idoc 11.2 - Configuración de la Interfaz de entrada 11.2.1 Transacción: WE81 11.2.2 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipos de mensajes 11.2.3 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP -> Desarrollo -> Tipo IDoc / Mensaje 11.2.4 Definición de Código de Operación 11.2.5 Definición de Módulo de Función
Manual para la creación de Idocs
El objetivo de este documento es servir de guía para la creación de interfaces entre dos sistemas R/3 o entre un R/3 y un legacy, utilizando Idocs.
1 - Qué es un Idoc?
Los IDoc permiten intercambiar información entre distintos sistemas. Se lo puede ver como un archivo de texto plano, con registros. Un Idoc es por ejemplo los datos de un proveedor , o una oferta. Contiene una cabecera y posiciones, pero todos los datos pertenecen a la misma entidad. O sea, para transmitir datos de más de un proveedor, haría falta más de un IDoc. Los IDocs se crean y luego se envían. Este envío se realiza en un segundo paso; o sea que podría haber IDOCs que todavía no se hayan enviado. Un Idoc, como se mencionó más arriba, está formato por dos bloques: Un registro de Control. Una tabla con los datos del IDOC . El registro de control contiene toda la información administrativa del IDOC, como el origen y el destinatario, y qué tipo de IDOC es. Sería algo así como el sobre que acompaña a cualquier carta. Este registro es muy importante ya que es necesario para saber, entre otras cosas, cuál será el destinatario del IDOC. La tabla SAP donde se guardan es la EDIDC. Los registros de datos se guardan en la tabla EDID4 en un campo de 1000 caracteres. Para saber interpretar esa cadena, el registro cuenta con un campo que informa cuál es la estructura con la que se deben interpretar los datos. El nombre de dicha estructura existe en SAP y se la puede ver desde la transacción SE11. Desde la transacción WE30 se puede ver el formato de los Idocs. Por ejemplo, para el Idoc MATMAS01, el formato es el siguiente: MATMAS01
Maestro material
E1MARAM
Maestro material datos generales (MARA)
E1MAKTM
Maestro material - textos breves (MAKT)
E1MARCM
Maestro material segmento C (MARC)
E1MARDM
Maestro material almacén/segmento lotes (MARD)
E1MARMM
Maestro material unidades de medida (MARM)
E1MEANM
Maestro mat. números art. europeos (MEAN)
E1MBEWM
Maestro material valoración stocks (MBEW)
E1MLGNM
Maestro mat. datos por núm.almacén (MLGN)
E1MVKEM
Maestro material datos de ventas (MVKE)
E1MLANM
Maestro material clasif. impuestos (MLAN)
E1MTXHM
Maestro material texto explicativo cabecera
E1MTXLM
Maestro material texto explicativo línea
Cada uno de los nombres que acá se muestran son estructuras que se pueden ver desde la SE11.
O sea que por ejemplo, para un registro de datos que tiene estructura E1MARAM, para saber cuál es el formato con el que hay que interpretarlos, se puede ir a la transacción SE11 y ver qué campos componen a esa estructura. Dado que la cadena de 1000 caracteres está formada por los datos de un campo atrás del otro, es solo cuestión de saber en qué posición de la cadena se encuentra cada campo. Generalmente, varios registros de estado se adjuntan a un IDOC. El sistema automáticamente asigna registros de estado durante todo el proceso, a medida que el IDOC va alcanzando diversos puntos de control. Contienen información de estado, tal como código de estado, fecha y hora en que el punto de control es alcanzado. Estos registros de estado existen solamente en SAP y no son almacenados en el archivo de salida. La estructura de los registros de estado está definida por la estructura del DDIC EDI_DS40. La tabla es EDIDS.
2 - Definición de la estructura de Idocs, segmentos de control, datos y estado. La estructura de un IDoc consiste de varios segmentos, y los segmentos consisten de una secuencia de campos. La estructura de un tipo de IDoc define la sintaxis de los datos al especificar la organización de los segmentos, atributos de los segmentos y formatos de cada uno de sus campos. En ejecución, un IDoc consiste de la siguiente secuencia de tres tipos de registros: a – Un único registro de Control Contiene toda la información de control del IDoc, incluyendo el número de IDoc, emisor y receptor, otra información de control tal como el tipo de mensaje que representa y el tipo de de IDoc. La estructura del registro de control es idéntica para todos los IDocs y está definida por SAP. Son automáticamente creados e insertados por el sistema en tiempo de ejecución. La estructura del registro de contol está definida por la estructura del DDIC EDI_DC40: Cantidad de campos: 36 Total longitudes de campo: 524
Componente
Tipo
Long.
CHAR TABNAM EDI4TABNAM 10 MANDT
CLNT 3
DOCNUM
CHAR EDI4DOCNUC 16
EDI4MANDT
CHAR DOCREL EDI4DOCREL 4 STATUS DIRECT
CHAR EDI4STATUS 2 CHAR 1
CHAR OUTMOD EDI4OUTMOD 1 EXPRSS TEST
CHAR EDI4EXPRSS 1 CHAR 1
CHAR IDOCTYP EDI4IDOCTP 30
Tipo
Texto breve
Nombre de la estructura de tabla Mandante Número del IDOC Release SAP del IDOC Status del IDOC EDI4DIRECT
Sentido
Modo de salida Sustitución en Entrada EDI4TEST
Indicador test
Nombre del tipo base
CIMTYP
CHAR EDI4CIMTYP 30
Ampliación (definida por los clientes)
MESTYP
CHAR EDI4MESTYP 30
Tipo de mensaje
CHAR MESCOD EDI4MESCOD 3
Variante de mensajes
MESFCT
CHAR EDI4MESFCT 3
Función de mensaje
STD
CHAR EDI4STD 1
Estándar EDI, indicador
CHAR STDVRS EDI4STDVRS 6 STDMES
CHAR EDI4STDMES 6
Estándar EDI, versión y release Tipo de mensajes EDI
CHAR SNDPRT EDI4SNDPRT 2
Tipo de interlocutor EDI del remitente
SNDPFC
CHAR EDI4SNDPFC 2
Función interlocutor EDI del remitente
SNDPRN
CHAR EDI4SNDPRN 10
SNDPOR
CHAR 10
EDI4SNDPOR
Puerta remitente (System, subsystem externo
Los datos del registro de control se almacenan en la tabla SAP EDIDC. La clave de esta tabla es el mandante (MANDT) y número de Idoc (DOCNUM). b – Uno o más registros de Datos Un IDoc puede contener múltiples registros de datos, según haya sido definida la estructura del Tipo de IDoc. En ejecución, los segmentos son convertidos por el sistema a registros de datos. Un registro de datos contiene información de la aplicación (maestro de proveedores, petición de oferta, oferta, pedidos, etc.). La estructura de los registros de datos está definida por la estructura del DDIC EDI_DD40: Estructura de campo
Cantidad de campos: 7 Total longitudes de campo: 1063 Componente
Tipo
Long.
Tipo
Texto breve
_______________________________________________________________________ SEGNAM
CHAR 30
EDI4SEGNAM
Segmento (nombre externo)
MANDT
CLNT 3
EDI4MANDT
Mandante
DOCNUM
CHAR 16
EDI4DOCNUC
Número del IDOC
SEGNUM
CHAR 6
EDI4SEGNUC
Número de segmento
PSGNUM
NUMC 6
EDI4PSGNUC
Número del segmento padre superior
HLEVEL
CHAR 2
EDI4HLEVEC
Nivel de jerarquía de segmento SAP
SDATA
LCHR 1000
EDI4SDATA
Datos de la aplicación
La sección de datos es una cadena de 1000 bytes, y es el lugar donde los datos realmente residen. La sección de datos es mapeada en ejecución a un tipo de segmento, según haya sido definida la estructura del tipo de IDoc, a fin de interpretar la estructura de los datos en esta cadena. Los datos de los registros de datos se almacenan en la tabla SAP EDID4. La clave de la tabla es el mandante (MANDT), el número de IDoc (DOCNUM), y el número de segmento (SEGNUM). c – Uno o más registros de Estado Generalmente, varios registros de estado se adjuntan a un IDoc. El sistema automáticamente asigna registros de estado durante todo el proceso, a medida que el IDoc va alcanzando diversos puntos de control. Contienen información de estado, tal como código de estado, fecha y hora en que el punto de control es alcanzado. Estos registros de estado existen solamente en SAP y no son almacenados en el archivo de salida. La estructura de los registros de estado está definida por la estructura del DDIC EDI_DS40. Estructura de campo Cantidad de campos: 24 Total longitudes de campo: 562 Componente
Tipo
TABNAM
CHAR 10
Long. Tipo
Texto breve
EDI4TABNAM
Nombre de la estructura de tabla
MANDT
CLNT 3
EDI4MANDT Mandante
DOCNUM
CHAR 16
EDI4DOCNUC Número del IDOC
LOGDAT
DATS 8
EDI4LOGDAT
Fecha de la información de status
LOGTIM
TIMS 6
EDI4LOGTIM
Hora de la información de status
STATUS
CHAR 2
EDI4STATUS
Status del IDOC
STAMQU
CHAR 3
EDI4STAMQU
Cualificador para mensaje en registro de status
STAMID
CHAR 20
STAMNO
NUMC 3
EDI4STAMNO
EDI4STAMID
Número de mensaje en mensaje de status
Nro. de mensaje para mensaje de status: Clase mensaje
STATYP
CHAR 1
EDI4STATYP
Tipo de mensaje (A, W, E, S, I) en el mensaje de status
STAPA1
CHAR 50
STAPA2
CHAR 50
STAPA3
CHAR 50
STAPA4
CHAR 50
EDI4STAPA1 EDI4STAPA2
Primer parámetro de un mensaje en registro de status Segundo parámetro de un mensaje en registro de status
EDI4STAPA3
Tercer parámetro de un mensaje en registro de status
EDI4STAPA4
STATXT
Cuarto parámetro de un mensaje en registro de status
CHAR 70
EDI4STATXT Texto para status
UNAME
CHAR 12
EDI4UNAME
Nombre del usuario
REPID
CHAR 30
EDI4REPID
Programa
ROUTID
CHAR 30
EDI4ROUTID
Subrutina (rutina, módulo de funciones)
SEGNUM
CHAR 6
EDI4SEGNUC
Número de segmento
SEGFLD
CHAR 30
EDI4SEGFLD
Campo de segmento
REFINT
CHAR 14
EDI4REFINT
Fichero de transmisión (EDI Interchange)
REFGRP
CHAR 14
EDI4REFGRP
Grupo de mensajes (EDI Message Group)
REFMES
CHAR 14
EDI4REFMES
Mensaje (Mensaje EDI)
ARCKEY
CHAR 70
EDI4ARCKEY
Clave del archivo de mensajes externo
Los datos de los registros de estado se almacenan en la tabla SAP EDIDS. La clave de la tabla es el mandante (MANDT), número de Idoc (DOCNUM), fecha (LOGDAT), hora (LOGTIM), y un contador de registro (COUNTR).
3 - Creación de un nuevo tipo de IDoc en SAP.
Para la creación de un nuevo tipo de IDoc en SAP debe seguirse una secuencia de 5 pasos: 3.1 – Creación de los elementos de datos Deben crearse los elementos de datos necesarios para la definición de los segmentos. La necesidad de crear elementos de datos debería ser mínima dado que los datos ya existen en SAP y por lo tanto están representados por sus propios elementos de datos. Sin embargo, los segmentos no admiten cualquier tipo dato y por lo tanto deberán definirse nuevos elementos en caso que los existentes no sean de alguno de los siguientes tipos: Tipo de Datos
Descripción
CHAR
String de caracteres
CLNT
Cliente
CUKY
Campo moneda, referenciado por campos CURR
DATS
Campo fecha (YYYYMMDD), almacenado como char(8)
LANG
Clave de idioma
NUMC
Campo carácter con dígitos solamente
TIMS
Campo fecha (HHMMSS), almacenado como char(6)
3.2 – Creación de Segmentos Los segmentos son creados por medio del Editor de Segmentos: Transacción: WE31. Camino lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Segmentos IDoc. Pasos: 3.2.1 - Ejecutar la transacción WE31. Ingresar el nombre del tipo de segmento (debe comenzar con Z1) y seleccionar la opción Crear (F5). 3.2.2 – Entrar una descripción breve y los valores para los distintos campos. Este paso completa la definición del segmento. El sistema automáticamente asigna un nombre a la definición del segmento, basado en el nombre del tipo de segmento. Ej.: si el tipo de segmento es Z1WKDET, la definición del segmento será Z2WKDET. 3.2.3 – Guardar las entradas. Volver a la pantalla anterior y repetir el mismo procedimiento para todos los segmentos que se necesiten crear para el tipo de IDoc. 3.3 – Creación del Tipo Base de IDoc Una vez creados todos los segmentos, el siguiente paso es crear el Tipo Base de IDoc. Los tipos base de IDocs se crean con el Editor de IDocs: Transacción: WE30 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipos IDoc. Pasos: 3.3.1 – Ejecutar la transacción WE30. Ingresar el nombre del tipo base de IDoc (debe comenzar con Z). Seleccionar la opción Tipo base y Crear (F5). 3.3.2 – En la siguiente pantalla, seleccionar la opción Crear nuevo e ingresar una descripción para el tipo base de IDoc. Presionar Continuar. 3.3.3 – Posicionar el cursor sobre el nombre del IDoc y seleccionar Crear (Shift+F6). Ingresar a continuación el tipo de segmento y sus atributos. Al presionar Enter, el sistema transfiere el nombre del tipo de segmento al editor de IDoc. 3.3.4 – Para ingresar más segmentos, repetir el procedimiento del punto 3.3. Luego de haber creado el primer segmento, debe indicarse para los restantes el nivel (mismo nivel o nivel hijo) en el cual se quiere insertar el nuevo segmento. 3.3.5 – Guardar el tipo base de IDoc. 3.4 – Liberación del Tipo de Segmento y Tipo Básico de IDoc Una vez terminada la definición de la estructura del IDoc y sus segmentos, ambos objetos deben ser liberados a fin de que se encuentren disponibles para su transporte a los sistemas de testing y producción. Primero deben liberarse los segmentos y después el tipo base de IDoc. Para liberar un segmento, ejecutar la transacción WE31. Ingresar el tipo de segmento y seleccionar Tratar, Liberar. El sistema automáticamente completa el check box en el bloque de definiciones del segmento. Para liberar un tipo base de IDoc, ejecutar la transacción WE30. Ingresar el tipo base de IDoc y seleccionar Tratar, Liberar. Una vez que el segmento / tipo base de IDoc es liberado, ya no pueden ser modificados. En caso de ser necesario introducir modificaciones debe cancelarse la liberación. Los pasos para cancelar la liberación son los mismos a los indicados para la liberación. 3.5 – Transporte de Segmentos y Tipo Base de IDocs Las modificaciones a los tipos base de IDocs y segmentos son automáticamente registradas en una orden de transporte. Luego de transportados los objetos, los mismos pueden volverse a transportar manualmente desde el editor de segmentos / IDoc seleccionando: Segmento Transportar. Al transportarse un segmento se transportan automáticamente todas sus definiciones y documentación. Sin embargo, al transportarse un tipo base de IDoc no se transportan automáticamente todos sus segmentos.
4 - Extensión de un IDoc. 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 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipos IDoc. 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. Introducir los nombres de la personas responsables así como una breve descripción del nuevo tipo de ampliación a crear. Seleccionar Continuar. 1 - 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. 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 IDoc 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. 4.1 - Configuración el procesamiento 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 estandar 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. 4.2 - Configuración el procesamiento 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 estandar 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.
5 - Creación de destinos RFC, puertos y sistemas lógicos. 5.1 - Definición de Destinos RFC Transacción: SM59 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Gestión Destino RFC. Dependiendo del sistema destino, la conexión RFC será de distinto tipo. En general, para envió de Idocs, se crean conexiones del tipo TCP/IP, especificando el nombre del servidor destino y el puerto TCP destino. 5.2 - Definición de puerta. (A lo largo de este documento se usará la palabra Puerto o Puerta, indistintamente) Transacción: WE21 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Gestión Descripción Puerta. Para una descripción detallada, buscar en SAP Library: Port Definition: Configuring Ports 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. En vez de definir el medio de comunicación directamente en el Acuerdo de Interlocutor (Partner Profile), se asigna un número de puerto, y es este puerto el que designa realmente al medio. Esto 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 reflejarán automáticamente en todos los acuerdos que lo estén utilizando. Al menos un puerto debe existir para cada sistema externo. La siguiente figura muestra cómo los Idocs son enviados a dos sistemas vía tres puertos. 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 via RFC sincrónico que el archivo ha sido transferido, que está localizado en un deteminado 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 distrubución ALE. El nombre del puerto se puede definir a mano o dejar que SAP lo elija. Además del puerto, hay que definir el destino RFC. 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. 5.3 - Definición de sistemas lógicos Transacción: BD54 Camino Lógico: Desde la transacción SALE, seleccionar Preparar sistemas receptores y de envío Preparar sistemas lógicos Nombrar sistema lógico. Asignar sistema lógico a mandante Cuando el sistema lógico es un R/3, se lo debe asignar a un mandante. Transacción: SCC4 Camino Lógico: Desde la transacción SALE, seleccionar Preparar sistemas receptores y de envío Preparar sistemas lógicos Asignar sistema lógico a un mandante. Hacer doble click sobre el mandante que al que se desea asignar, y posteriormente completar con el nombre del sistema lógico.
6 - Creación de los acuerdos de interlocutores.
Transacción: WE20 Camino Lógico: Desde la transacción WEDI, seleccionar Menú SAP Gestión Acuerdo de Interlocutores EDI 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 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.
7 - Creación de un nuevo tipo de Mensaje en SAP. Transacción: WE81
Camino Lógico: Desde el área de menú EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipos de Mensajes En este paso se asigna un tipo de mensaje a los contenidos de datos a ser transferidos en el IDoc. Los mensajes de usuario deben ser nombrados comenzando con Z.
8 - Relación entre un tipo de Mensaje y un Tipo de IDoc
Transacción: WE82 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipo Mensaje/IDoc En este paso se asigna el tipo de mensaje creado en el paso anterior a un tipo de IDoc. Esta asociación no sólo sirve a fin de documentar el mensaje en que está basado cada tipo de IDoc, sino que además verifica esta asociación el momento en que el IDoc es generado. Creación de un 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 quienes 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, 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. Puede 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.
9 - Pasos para crear un Modelo de Distribución:
Transacción: BD64 Camino Lógico: Desde la transacción SALE, seleccionar Aplication Link Enabling (ALE) Modelar e implementar modelos empresariales Actualizar modelos de Distribución y Distribuir Vistas -Ir a la transacción BD64 -Pasar al modo modificación -Presionar el botón Crear Modelo Vista (Ctrl+F4) Aparecerá la siguiente ventana: -Completar el texto breve y el nombre técnico para el modelo de distribución y presionar continuar. -Seleccionar el registro recién creado y presionar el botón Insertar Tipo Mensaje (CTRL+F7) Aparecerá la siguiente ventana: -Completar el campo Emisor con el nombre del Sistema lógico que transmitirá el mensaje. -Completar el campo Destinatario con el nombre del Sistema lógico que recibirá el mensaje. -Completar el campo Tipo de mensaje con el mensaje que se transmitirá entre estos sistemas lógicos. Importante No se puede mantener un tipo de mensaje entre el mismo emisor y receptor en más de un modelo de distribución. 10,- Creación de un Idoc de salida Existen tres formas de creación de Idocs: Desde un programa ABAP (desarrollo Z). Desde un puntero de modificación (Change Pointer). Desde mensajes de logística. Observación: Los pasos para: Crear de un nuevo tipo de IDoc en SAP. Extender un Idoc. Crear sistemas lógicos, puertos y destinos RFC. Crear acuerdos de interlocutores. Crear un nuevo tipo de Mensaje en SAP. Relacionar un tipo de Mensaje con un tipo base de Idoc. Crear de un modelo de distribución. fueron explicados más arriba, por lo cual solamente se procederá a explicar los mínimos pasos necesarios para crear un Idoc. 10.1 - Creación de Idocs desde un 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. 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+8 = 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. *--- 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. 10.2 - Creación de Idocs utilizando Punteros de Modificación (Change Pointers) Toda 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. Los pasos a seguir para la creación de un Idoc de salida utilizando Punteros de Modificación son los siguientes: 10.2.1 - Activar los punteros de modificación en forma global. 10.2.2 - Activar los punteros de modificación para nuestro tipo de mensaje. 10.2.3 - Definir los campos relevantes para la generación de punteros de modificación. 10.2.4. - Relacionar el tipo de mensaje con el módulo de función. 10.2.5 - Crear un módulo de función para leer los punteros de modificación y crear los Idocs. 10.2.1 - Activación de punteros de modificación en forma global Transacción: BD61 Camino Lógico: Desde la configuración de ALE en el IMG (transacción SALE), seleccionar Modelar e Implementar procesos empresariales Configurar distribución de datos maestros Configurar reproducción de datos modificados Activación general de puntero de modificación. Marcar el Flag: Puntero modificación general activado y grabar. 10.2.2 - Activación de punteros de modificación por Tipo de Mensaje Transacción: BD50 Camino Lógico: Desde la configuración de ALE en el IMG (transacción SALE), seleccionar Modelar e Implementar procesos empresariales Configurar distribución de datos maestros Configurar reproducción de datos modificados Activar puntero modificación por tipo mensaje. Agregar una entrada para el mensaje deseado, y marcarla como activa. 10.2.3 - Definición de campos relevantes para la generación de Punteros de Modificación Transacción: BD52 Camino Lógico: Herramientas ALE Desarrollo ALE IDoc Servicio de Modificaciones Actualizar campos relevantes para modificación Ingresar entradas para los campos sobre los cuales se quieran crear Punteros 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 10.2.4 - Relación entre el Tipo de Mensaje y el Módulo de Función
Transacción: BD60 Camino Lógico: Herramientas ALE Desarrollo ALE IDoc Filtrado de datos Actualizar filtrado mediante clases. 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 estandar 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. 10.2.5 - 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: 123456789-
Leer los punteros de modificación generados usando la función CHANGE_POINTERS_READ. Analizar los punteros de modificación para determinar cuáles documentos son válidos. Determinar la clave del documento de aplicación del paso 2. Seleccionar datos de aplicación de la base de datos, usando la clave de objeto identificada en el paso 3. Completar la información del registro de control del IDoc. Completar una tabla interna de estructura EDIDD con registros de datos para todos los segmentos. Llamar al servicio de la capa ALE (MASTER_IDOC_DISTRIBUTE) para crear los datos en la base de datos. Actualizar el estado de los punteros de modificación 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. 10.3 - 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á la 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.
11 - Creación de un Idoc de entrada
La configuración de la interfaz de entrada incluye una sección de Configuración de Workflow para el manejo de excepciones. Podemos dividir esta tarea en dos partes: 11.1 - Configuración de Workflow. 11.2 - Configuración de la Interfaz de entrada. 11.1 - Configuración de Workflow La configuración de workflow es necesaria para el manejo de excepciones en el proceso de entrada. Los pasos que deben llevarse a cabo son: 1 – Crear un nuevo Objeto de Aplicación IDoc en el Business Object Builder con eventos de triggering y de finalización. 2 – Crear una nueva tarea basada en el objeto de aplicación Idoc. 3 – Crear el link de los eventos. 11.1.1 - Crear un nuevo Objeto de Aplicación Idoc Transacción: SWO1 Camino Lógico: Herramientas SAP Business Workflow Desarrollo Herramientas def. Business Object Builder 1 – Seleccionar el botón Buscar (ctrl.+F) y expandir las opciones de selección seleccionando el botón Selecciones (todas). Ingresar IDOCAPPL en el campo Tipo super y Ejecutar. 2 – Seleccionar cualquier objeto y seleccionar Business Objects Copiar. El objeto seleccionado debe tener los eventos INPUTERROROCCURRED e INPUTFINISHED. 3 – Asignar un nombre al Tipo de Objeto y al programa 4 – Hacer doble clic sobre la nueva entrada creada. Seleccionar el ícono de Datos básicos y Modificar. Modificar el nombre y descripción del objeto de manera que coincidan con los del IDoc. Generar y liberar el Tipo de objeto. 11.1.2 - Crear una nueva tarea basada en el Objeto de Aplicación Idoc Observación: Si al ejecutar este paso, llega a aparecer el mensaje: el problema es el siguiente: Las tareas y papeles, así como las definiciones workflow necesitan un ID, unívoco para todo el sistema y el mandante. De esta manera es posible realizar un transporte de estos objeltos de un sistema a otro, en todo momento y sin restricciones. Desde el punto de vista técnico, esta uniformidad se realiza mediante un "número prefijo". Para cada sistema y cada mandante puede definirse un número prefijo propio. Esto se realiza en la tabla T78NR. Falta entrada para sistema NNN, mandante XXX
La transacción es la OOW4. Una tarea de workflow define los atributos de la tarea que debe ser ejecutada cuando ocurre un error de aplicación. Una tarea apunta a un método a ser ejecutado y a un evento de triggering que comienza la tarea. La mejor opción para definir una nueva tarea es copiar una existente, tal como ORDERS_ERROR (TS00008046). 1 – Ejecutar la transacción PFTC_COP. Transacción: PFTC_COP Camino Lógico: Herramientas SAP Business Workflow Desarrollo Herramientas def. Tareas/Grupos de Tareas Copiar Seleccionar Tarea estándar para el tipo de tarea e ingresar algún número de tarea (ej: 74508518) como tarea. Seleccionar el ícono Copiar. 2 – Ingresar una abreviatura y nombre para la tarea. Presionar Enter. Esto debería copiar la tarea. Tomar nota del número creado (ejemplo: 90000001). Ejemplo de Sigla y Denominación: Sigla: ZQOTE_ERROR Denominación: ZQOTE Error de Entrada 3 – Ejecutar la transacción PFTC_CHG. Transacción: PFTC_COP Camino Lógico: Herramientas SAP Business Workflow Desarrollo Herramientas def. Tareas/Grupos de Tareas Modificar Seleccionar Tarea estándar como tipo de tarea, y el número de tarea del paso 2 en el campo Tarea. Seleccionar Modificar. 4 – Reemplazar el campo Tipo de Objeto con el Objeto de aplicación IDoc creado más arriba, ZIDOCZQOTE. 5 – El siguiente paso es modificar el evento de Triggering. Seleccionar la solapa Event. Desencadenantes. Borrar el/los eventos existentes y crear otro basado en el Tipo de Objeto: Tipo de Objeto: ZIDOCZQOTE Evento: INPUTERROROCCURRED 6 – Debe ahora definirse el link de datos entre el evento de triggering y la tarea. Seleccionar la línea correspondiente al evento de triggering y presionar el ícono Defin. Flujo datos. Aceptar los valores propuestos para los campos Expresión y Excepción. 7 – Activar el link 8 – Definir ahora el evento de terminación. Seleccionar la solapa Event. Finalizadores. Borrar el eventos existente y crear otro basado en el Tipo de Objeto: Tipo de Objeto: ZIDOCZQOTE Evento: INPUTFINISHED Elemento: WIOBJECT_ID (la única opción disponible) 9 – Definir la tarea como Tarea General de modo tal que pueda ser ejecutada por todos. Seleccionar Datos adicionales Asign. Responsable Actualizar. Seleccionar la opción Tarea General y grabar. 11.2 - Configuración de la Interfaz de entrada Luego de definir la configuración de workflow, deben llevarse a cabo los siguientes pasos para la configuración del proceso de entrada: 1 - Definir un nuevo tipo de mensaje. 2 - Relacionar el tipo de mensaje al tipo de IDoc. 3 - Asignar el módulo de función al tipo de mensaje lógico y Idoc. 4 - Definir los atributos para el módulo de función de entrada. 5 - Definir un nuevo Código de Operación. 6 - Asignar métodos de entrada. 7 - Definir o modificar un acuerdo de interlocutor . 8 - Definir Puerta. 9 - Definir Módulo de Función. 11.2.1 - Definición de mensaje Transacción: WE81 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Tipos de mensajes En este paso se asigna un tipo de mensaje a los contenidos del IDoc y se le da una descripción corta. Definir un tipo de mensaje. Por ejemplo: ZQUOTE (Oferta). Ver detalles del procedimiento más arriba en este mismo documento: Creación de un nuevo Tipo de Mensaje Relación entre el tipo de mensaje y el tipo de Idoc Transacción: WE82 11.2.2 - Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP -> Desarrollo -> Tipo IDoc / Mensaje En este paso se asigna el tipo de mensaje creado en el paso anterior al tipo de IDoc. Para este ejemplo, relacionar el tipo de mensaje (ej: ZQUOTE) con el tipo base de IDoc ( ej: ZQUOTE01). Ver detalles del procedimiento más arriba en este mismo documento: Relación entre un Tipo de Mensaje y un Tipo Base de IDoc. Relación entre el módulo de función y el tipo de mensaje Transacción: WE57 11.2.3 - Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Desarrollo Mensaje / Obj.Apl. Esta configuración establece un link entre el módulo de funciones, variante de mensaje (tipo de mensaje, variante lógica de mensaje y función lógica de mensaje). Observación: En el caso de mensajes de salida, esta relación es establecida en el acuerdo de interlocutor. Para mensajes de entrada, no existe entrada para el tipo de IDoc en el acuerdo de interlocutor, por lo que esta configuración es usada para establecer un tipo de IDoc, mensaje y business object válidos para el módulo de función. 1 – Crear un módulo de función (o sea una función). No es recomendable crearla de cero. Copiarla de alguna existente, ya que los parámetros de la función son estándar. Por ejemplo, copiar el módulo de función IDOC_INPUT_ORDERS a Z_IDOC_INPUT_ZQUOTE, y asignarlo a algún grupo de funciones Z. 2 – Crear una nueva entrada en la transacción WE57. Los valores de Módulo, Tipo Base, Tipo Mensaje y Tipo Objeto mostrados a continuación son de ejemplo, pero el Tipo y Sentido se deben respetar. Módulo: Tipo: Tipo Base: Tipo Mensaje: ZQUOTE
Z_IDOC_INPUT_ZQUOTE F (módulo de función) ZQUOTE01
Tipo Objeto:
ZIDOCZQOTE
Sentido:
2 (Salida)
font size = "4">Definir atributos del Módulo de Función Transacción: BD51 Camino Lógico: Herramientas => ALE Desarrollo ALE => IDoc => Proceso de Entrada => Módulo de Funciones => Actualizar atributos Crear una nueva entrada, con el siguiente detalle: Módulo de función de entrada: Z_IDOC_INPUT_ZQUOTE Tipo de Entrada: 2 (Entrada indiv. Con bloqueo de IDoc en transacción CALL) Diálogo posible: X El flag de diálogo posible indica si el IDoc puede ser procesado en modo de diálogo luego de un error. Si esta opción está seteada, el usuario puede reprocesar el juego de datos en modo visible. 11.2.4 - Definición de Código de Operación Transacción: WE42 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Desarrollo Parametrizaciones Entrada Cód. operación proceso de entrada En este paso se asigna el código de operación de proceso al módulo de función creado para el proceso de entrada. El código de operación de proceso es un medio indirecto de identificar al módulo de función. Definir el código de operación (Ej: ZQUOT), según el siguiente detalle: Descripción:
Oferta
Módulo de Función:
Z_IDOC_INPUT_ZQOTE
Cantidad máxima de repeticiones:
2
Marcar el flag Proceso con servicio ALE Marcar el flag Procesamiento c. Módulo de funciones Asignar métodos de entrada Transacción: BD67 Este paso crea un link entre el código de proceso definido en el paso previo y el módulo de función. Además, se definen parámetros adicionales que la componente de workflow utiliza para manejo de errores, así como programación avanzada de workflow. Definición de Acuerdo de Interlocutor Transacción: WE20 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Menú SAP Gestión Acuerdo entre interlocutores EDI. Crear un Acuerdo de Interlocutor con la siguiente información: Nro. Interlocutor EDI: Tipo de Interlocutor EDI: Tipo de Autor: Autor:
Poner el nombre del sistema lógico que se haya creado. LS (sistema lógico) US (Usuario) (el Id del usuario que lo está creando.)
Presionar Grabar. Adicionar parámetro de entrada con la siguiente información: Opciones de Salida: Tipo de interlocutor EDI:
LS
Función interlocutor EDI:
LS
Tipo de mensaje:
ZQUOTE
Cód. Oper.:
"Valor de Ejemplo
ZQUOT
"Valor de Ejemplo
Verif. Sintax.: Lanzamiento inmediato:
X
Definición de Puerta Transacción: WE21 Camino Lógico: Desde el área de menú de EDI (transacción WEDI), seleccionar Gestión Descripción Puerta Se crea una puerta, (Ejempo EDI_ZQOT02) de tipo fichero, para definir el destino físico del IDOC una vez generado y transmitido a la puerta de salida. Datos de la puerta de fichero: 1. Directorio físico: 2. Fichero de salida:
X ZQUOTE02
"Valor de Ejemplo
11.2.5 - Definición de Módulo de Función Un módulo de función de entrada de Idocs tiene la siguiente secuencia de pasos. 1 – Leer la información del registro de control. Verificar la información de control (tipo de mensaje). Si el tipo de mensaje es incorrecto, generar una excepción. 2 - Leer los datos para un IDoc. 3 – Procesar cada registro de datos. 5 – Completar los parámetros de retorno. 6 – Si existen otros IDocs, volver al paso 2. Si no, ir al paso 7. 7 – Retornar del módulo de función. Los resultados de la ejecución son pasados a la capa ALE. En general, los módulos de funciones que reciben Idocs tienen los siguientes parámetros:
Import parameters
Reference field
Opt Y/N
INPUT_METHOD
BDWFAP_PAR-INPUTMETHD
N
MASS_PROCESSING
BDWFAP_PAR-MASS_PROC
N
Export Parameters
Reference field
Opt Y/N
WORKFLOW_RESULT
BDWFAP_PAR-RESULT
N
APPLICATION_VARIABLE
BDWFAP_PAR-APPL_VAR
N
IN_UPDATE_TASK
BDWFAP_PAR-UPDATETASK
N
CALL_TRANSACTION_DONE
BDWFAP_PAR-CALLTRANS
N
Table Parameters
Reference field
IDOC_CONTRL
EDIDC
IDOC_DATA
EDIDD
IDOC_STATUS
BDIDOCSTAT
RETURN_VARIABLES
BDWFRETVAR
SERIALIZATION_INFO
BDI_SER
Optional Y/N
Exceptions WRONG_FUNCTION_CALLED A continuación se detalla genéricamente el código de procesamiento de Idocs de entrada, donde se puede ver que realiza los pasos mencionados más arriba. * DECLARACION DE DATOS DATA: C_SEGNAM(10) TYPE C VALUE 'Z1INVRV'. *RECORRE EL/LOS IDOC/S DE CABECERA LOOP AT IDOC_CONTRL. * RECORRE LOS SEGMENTOS DE DATOS PARA CADA UNA DE LAS * CABECERAS DE IDOCS (REGISTROS DE CONTROL) LOOP AT IDOC_DATA WHERE DOCNUM = IDOC_CONTRL-DOCNUM. * *
SEGUN EL SEGMENTO, GUARDA LOS DATOS EN UNA DETERMINADA ESTRUCTURA Y LO PROCESA. CASE IDOC_DATA-SEGNAM. WHEN C_SEGNAM. IT_Z1INVRV = IDOC_DATA-SDATA. PERFORM F_PROCESAR_XXXX ... ... ... WHEN C_XXXXXX. IT_XXXXXXX = IDOC_DATA-SDATA. PERFORM F_PROCESAR_NNNN ENDCASE. ENDLOOP."LOOP AT IDOC_DATA
*
GUARDA EL RESULTADO DE LA EJECUCION PARA EL IDOC ACTUAL PERFORM UPDATE_IDOC_STATUS.
ENDLOOP."LOOP AT IDOC_CONTRL. ************************************************************************ * FORMS ************************************************************************ FORM F_PROCESAR_XXXX * Acá insertar la lógica necesaria para el procesamiento del registro ENDFORM. *---------------------------------------------------------------------* * FORM UPDATE_IDOC_STATUS * *---------------------------------------------------------------------* * ........ * *---------------------------------------------------------------------*
FORM UPDATE_IDOC_STATUS. *--- Now we check the CALL TRANSACTION return code and set IDOC status CLEAR IDOC_STATUS. IF RETURN_CODE = 0. WORKFLOW_RESULT = '0'. IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM. IDOC_STATUS-STATUS = '53'. IDOC_STATUS-UNAME = SY-UNAME. IDOC_STATUS-REPID = SY-REPID. IDOC_STATUS-MSGTY = SY-MSGTY. IDOC_STATUS-MSGID = SY-MSGID. IDOC_STATUS-MSGNO = SY-MSGNO. IDOC_STATUS-MSGV1 = SY-MSGV1. IDOC_STATUS-MSGV2 = SY-MSGV2. IDOC_STATUS-MSGV3 = SY-MSGV3. IDOC_STATUS-MSGV4 = SY-MSGV4. RETURN_VARIABLES-WF_PARAM = 'Processed_IDOCs'. RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM. APPEND RETURN_VARIABLES. ELSE. WORKFLOW_RESULT = '99999'. IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM. IDOC_STATUS-STATUS = '51'. IDOC_STATUS-UNAME = SY-UNAME. IDOC_STATUS-REPID = SY-REPID. IDOC_STATUS-MSGTY = SY-MSGTY. IDOC_STATUS-MSGID = SY-MSGID. IDOC_STATUS-MSGNO = SY-MSGNO. IDOC_STATUS-MSGV1 = SY-MSGV1. IDOC_STATUS-MSGV2 = SY-MSGV2. IDOC_STATUS-MSGV3 = SY-MSGV3. IDOC_STATUS-MSGV4 = SY-MSGV4. RETURN_VARIABLES-WF_PARAM = 'ERROR_IDOCS'. RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM. APPEND RETURN_VARIABLES. ENDIF. APPEND IDOC_STATUS. ENDFORM." UPDATE_IDOC_STATUS
