Responsable: Departamento de Sistemas



Descargar 58.23 Kb.
Fecha de conversión11.01.2017
Tamaño58.23 Kb.

Titulo:


Doc. Interfaces - Idocs

Módulo: BC

Responsable:

Departamento de Sistemas

Descripción:

Documentación Interfaces - Idocs


Autor: Iván Escudero

Fecha Creación: 22/06/2010

Modificado: 11/01/2017

Versión: 1.0






Interfaces

-Idocs-

Índice de Contenidos


1Idocs 3

2Definición de la Estructura de Idocs, Segmentos de control, datos y Estado 4

3Creación de un Nuevo Tipo de Idoc en SAP 5

3.1Creación de los Elementos de Datos 5

3.2Creación de Segmentos 5

3.3Creación del Tipo Base del Idoc 6

3.4Liberación del Tipo de Segmento y Tipo Básico del Idoc 6

4Extensión de un Idoc 6

4.1Configuración del Procesamiento Outbound 7

4.2Configuración del Procesamiento Inbound 7

5Creación de un Nuevo Tipo de Mensaje en SAP 7

6Relación entre un Tipo de Mensaje y un Tipo de Idoc 8

7Creación de Destinos RFC, Puertos y Sistemas Lógicos 9

7.1Definición de Destinos RFC 9

7.2Definición de Puerta 9

7.3Definición de Sistemas Lógicos 10

8Creación de los Acuerdos de Interlocutores 11

9Creación de un Idoc de Salida 12

9.1Creación de Idocs desde un Programa ABAP 12

9.2Creación de Idocs Utilizando Punteros de Modificación (Change Pointers) 13

9.3Creación de Idocs desde Mensajes de Logística 13

10Creación de un Idoc de Entrada 14

10.1Definición del mensaje 14

10.2Relación entre el Tipo de Mensaje y el Tipo de Idoc 14

10.3Relación entre el Módulo de Función y el Tipo de Mensaje 14

10.4Definición de Código de Operación 15

10.5Asignar Métodos de Entrada 15

10.6Asignar Métodos de Entrada 15

10.7Definición de la Puerta 15

10.8Definición del Módulo de Función 15



1Idocs

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; podría haber Idocs que todavía no se hayan enviado.
Un Idoc 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. Este registro es muy importante ya que es necesario para saber, entro 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.
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.

2Definició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:
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 control está definida por la estructura del DDIC EDI_DC40.

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).


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. 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).


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. Los datos de los registros de datos 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).





3Creación de un Nuevo Tipo de Idoc en SAP

3.1Creación de los Elementos de Datos


Deben crearse los elementos de datos necesarios para la definición de los segmentos. Los segmentos no admiten cualquier tipo dato. Los tipos aceptados son los siguientes:


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.2Creación de Segmentos


Los segmentos son creados por medio del Editor de Segmentos:

Transacción: WE31.


Pasos a seguir:

  1. Ejecutar la transacción WE31. Ingresar el nombre del tipo de segmento (debe comenzar con Z) y seleccionar la opción Crear (F5).

  2. Entrar una descripción breve y los valores para los distintos campos. Este paso completa la definición del segmento.

  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.3Creación del Tipo Base del 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


Pasos a seguir:

  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).

  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. 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.

  4. Para ingresar más segmentos, repetir el procedimiento del punto c. 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.

  5. Guardar el tipo base de IDoc.



3.4Liberación del Tipo de Segmento y Tipo Básico del 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 checkbox 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.



4Extensió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


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.

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.1Configuración del 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 estándar SAP. En caso de serlo, habrá que insertar el código necesario para manejar las extensiones en una userexit. 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.2Configuración del 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 estándar SAP. En caso de serlo, habrá que insertar el código necesario para manejar las extensiones en una userexit. 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.




5Creación de un Nuevo Tipo de Mensaje en SAP

Transacción: WE81

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.



6Relación entre un Tipo de Mensaje y un Tipo de Idoc

Transacción: WE82

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.



7Creación de Destinos RFC, Puertos y Sistemas Lógicos

7.1Definición de Destinos RFC


Transacción: SM59

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.



7.2Definición de Puerta


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 puertas. En otras palabras, una puerta es un nombre lógico para un dispositivo de entrada/salida. Los programas se comunican con un puerta 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 puerta, y es esta puerta el que designa realmente al medio. Esto permite definir las características de las puertas individualmente y usar una puerta en múltiples Acuerdos de interlocutores. Los cambios en una puerta se reflejarán automáticamente en todos los acuerdos que lo estén utilizando.

Al menos una puerta debe existir para cada sistema externo.

Los tipos de puertos más comunes son los siguientes:


  1. 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.


  1. 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.


  1. 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.



  1. XML-HTTP

En vez de definir el nombre del archivo XML, se especifica un destino RFC.


  1. IP Abap

En estos tipos de puerta se puede definir un módulo de funciones Z, copia del módulo de funciones estandar OWN_FUNCTION, con el cual se puede escribir el Idoc de la forma que queramos. Así podemos construir ficheros planos, CSV,… a partir del Idoc.

7.3Definición de Sistemas Lógicos


Un sistema lógico es un nombre que le asignaremos a cualquier sistema externo con el que vayamos a crear interfaces. Por ejemplo, si vamos a crear interfaces con un AS400 podemos crear un sistema lógico llamado AS400 y después asignarle las interfaces con las que vayamos a trabajar.
Transacción BD54.

8Creación de los Acuerdos de Interlocutores

Transacción: WE20


Un interlocutor ALE es un sistema SAP remoto, un sistema lógico o un interlocutor (cliente, proveedor,…) 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.
Los 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.

  • Puerta 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.


9Creació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.



9.1Creació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.

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.



9.2Creació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 report 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:




  • Activar los punteros de modificación en forma global: BD61

  • Activar los punteros de modificación para nuestro tipo de mensaje: BD50

  • Definir los campos relevantes para la generación de punteros de modificación. BD52

  • Relacionar el tipo de mensaje con el módulo de función. BD60

  • Programar un job con el report RBDMIDOC para crear los Idocs.



9.3Creación de Idocs desde Mensajes 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 formularios.

La tabla utilizada para esto es la NAST. Esta tabla guarda recordatorios escritos por aplicaciones. Estos recordatorios son llamados Mensajes.

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.




10Creación de un Idoc de Entrada

Para la configuración del proceso de entrada hay que seguir los siguientes pasos:




  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 un nuevo Código de Operación.

  5. Asignar métodos de entrada.

  6. Definir o modificar un acuerdo de interlocutor.

  7. Definir Puerta.

  8. Definir Módulo de Función.



10.1Definición del mensaje


Transacción: WE81

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).



10.2Relación entre el Tipo de Mensaje y el Tipo de Idoc


Transacción: WE82

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).



10.3Relación entre el Módulo de Función y el Tipo de Mensaje


Transacción: WE57

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.



10.4Definición de Código de Operación


Transacción: WE42

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.



10.5Asignar 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.



10.6Asignar Métodos de Entrada


Transacción: WE20.

10.7Definición de la Puerta


Transacción: WE21.

10.8Definición del 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.

  4. Completar los parámetros de retorno.

  5. Si existen otros IDocs, volver al paso b. Si no, ir al paso f.

  6. Retornar del módulo de función. Los resultados de la ejecución son pasados a la capa ALE.




Pág. /

Catálogo: 2012
2012 -> Los acabados, características y precios mencionados en esta documentación se refieren a la gama ofrecida en Alemania. Reservados todos los derechos de modificación y error
2012 -> República de Colombia
2012 -> Ncea spanish level 1 90911 Demonstrate understanding of a variety of Spanish texts on areas of most immediate relevance
2012 -> Índice declaración de Responsabilidad
2012 -> Arquitectura y paisaje en marruecos tánger med: Ciudad Instantánea ud aranguren + ud gallegos ets arquitectura madrid
2012 -> Instructivo para el llenado del pedimento
2012 -> Pliego de absolución de consultas proceso por competencia mayor n° cma-0020-2012-ofp/petroperu segunda convocatoria
2012 -> Hijos del No Reconocido
2012 -> Barcelona 28-3 marzo disney on ice pasaporte a la aventura. Hasta 3 marzo. Un jardin singular. Ceramica de iznik. Siglo XVI
2012 -> Metabolic alterations in employees of a company of industrial eaters Barquisimeto, Lara state Venezuela


Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©bazica.org 2019
enviar mensaje

    Página principal