Saltar al contenido

Mejores prácticas para SAP

Introducción

Existen varios problemas y consideraciones exclusivos para los proyectos de integración de SAP, en particular para las integraciones bidireccionales. Esta página presenta información relevante para todas las integraciones de SAP, patrones de integración comunes para SAP y sus consideraciones de diseño, y tutoriales específicos de SAP.

Información básica

Esta sección cubre la terminología de SAP y Jitterbit, la actualización de datos de SAP, la estructura IDoc y los formatos de fecha.

Terminología

Esta sección define la terminología específica de SAP relacionada con Jitterbit Design Studio y su conector SAP.

Terminología SAP

  • SAP: Cuando nos referimos a SAP, nos referimos a una versión de SAP que sea compatible con el conector SAP de Jitterbit Design Studio. El componente esencial que requiere el Design Studio SAP Connector es una versión de SAP que utilice el SAP Java Connector (SAP JCo). Esto incluye ECC versión 6 o posterior y SAP S/4HANA de inquilino único.
  • IDoc: Un documento intermedio (IDoc) es un archivo de texto con un formato predefinido similar a un documento de intercambio electrónico de datos (EDI). Existen IDocs para objetos de datos maestros, como clientes y proveedores, así como para objetos transaccionales como pedidos de venta. Los IDocs, que originalmente se utilizaban para intercambiar datos entre sistemas SAP, también se pueden utilizar para la integración de externo. Tenga en cuenta que un IDoc utiliza abreviaturas alemanas dentro del documento.
  • BAPI: Una interfaz de programación de aplicaciones empresariales (BAPI) es una API (similar a una API SOAP o REST) y utiliza una construcción de solicitud y respuesta para comunicarse con SAP. Una diferencia principal con respecto a SOAP o REST es que una BAPI tiene un único método y es específica de un objeto. Por ejemplo, hay 60 BAPI relacionadas únicamente con el objeto de cliente de SAP. SAP proporciona y mantiene las BAPI.
  • RFC: Una RFC (llamada de función remota) es lo mismo que una BAPI, excepto que una RFC puede o no mantenerse en las actualizaciones de SAP. Algunas RFC son estándar y las proporciona SAP. También se pueden crear RFC personalizadas para admitir integraciones y el cliente de SAP debe mantenerlas.

Terminología de Jitterbit

  • Conector SAP: El conector SAP de Jitterbit Design Studio utiliza SAP Java Connector (SAP JCo) para trabajar con objetos SAP y es compatible con la versión 6 o posterior de ECC y SAP S/4HANA local. El conector SAP se puede utilizar de manera inmediata para comunicaciones entrantes de SAP desde Harmony a SAP mediante RFC, BAPI o IDocs.
  • Escucha de eventos de SAP: El escucha de eventos SAP Jitterbit es una aplicación que se instala y se ejecuta como un servicio en un servidor Windows o Linux. Amplía la funcionalidad del conector SAP al escuchar y recibir IDocs salientes de SAP. Mediante el protocolo RFC transaccional (tRFC), los IDocs se envían en un lote sin un orden definido. Mediante el protocolo RFC en cola (qRFC), el escucha de eventos SAP responde a SAP después de recibir cada IDoc, lo que le indica a SAP que envíe el siguiente IDoc en la transacción.

Actualización de datos SAP

Como práctica recomendada, al actualizar datos en SAP, suele ser preferible utilizar una BAPI o RFC en lugar de un IDoc. La razón principal es que las BAPI y las RFC devuelven una respuesta que se puede utilizar en el proyecto de integración:

  • Una actualización exitosa a menudo tiene identificadores de registros en la respuesta, que pueden usarse para actualizar la aplicación de origen.
  • Si se devuelve un error, se puede incorporar a los procesos de manejo de errores.

En comparación, cuando se envía un IDoc, el único acuse de recibo que se envía es un código que indica que se recibió; no hay ninguna indicación de éxito o fracaso. Los IDoc se procesan en SAP de forma asincrónica. Si un IDoc falla, se requiere la acción del usuario para volver a procesarlo.

Existen ciertos escenarios en los que es preferible un IDoc:

  • Un IDoc puede contener varios registros, mientras que las BAPI y las RFC normalmente solo pueden gestionar una única actualización de registro. En un escenario de actualización masiva, es posible que se requiera el uso de un IDoc.
  • Se puede utilizar un IDoc para capturar datos modificados, mientras que las BAPI y las RFC no pueden manejar consultas basadas en marcas de tiempo.
  • Puede haber una funcionalidad que un IDoc pueda invocar que no esté disponible mediante una BAPI o RFC.

Estructura de IDoc

La estructura de un IDoc es plana. Aunque el XML parece jerárquico, los nodos repetidos en realidad no están anidados dentro de los nodos principales.

En la estructura de ejemplo que se muestra a continuación, todos los segmentos del nodo principal IDOC están en el mismo subnivel. La información del encabezado está en el mismo nivel que la información del elemento:

attachment

Formatos de fecha

Aunque SAP puede mostrar fechas en su GUI en diferentes formatos (siguiendo las convenciones de cada país), el formato de datos para las APIs de SAP es yyyy-mm-dd.

Patrones de integración

Esta sección presenta patrones de integración comunes que se pueden utilizar para interactuar con datos de SAP.

Integración de datos maestros de clientes

En SAP, un cliente puede ser una de las funciones de socio (o una combinación de ellas), como SoldTo, ShipTo y BillTo. Por ejemplo:

  • Un cliente podría ser su propio SoldTo, ShipTo y BillTo.
  • Un cliente podría ser un SoldTo y un BillTo, con un cliente diferente como ShipTo.
  • Un cliente podría ser un Vendido y muchos otros clientes podrían ser los Enviadores (un caso común en el que un cliente de franquicia tiene muchas sucursales)

Al utilizar el objeto de cliente de SAP en proyectos de integración, es esencial tener una comprensión profunda de los requisitos de integración tanto para los clientes como para las funciones de los socios.

En general, con una carga inicial de datos, los clientes SoldTo deben cargarse primero, ya que los demás clientes dependen de que SoldTo exista en el extremo de destino para generar la relación. Como BillTo contiene la dirección de facturación, con frecuencia la definición del cliente del extremo necesita direcciones principal y de envío, y la integración debe actualizar el cliente SoldTo con la dirección BillTo en el extremo.

En el siguiente ejemplo, un único IDoc de SAP genera una actualización tanto en una cuenta como en una cuenta secundaria de un objeto personalizado en Salesforce:

adjunto

Integraciones bidireccionales

Los proyectos de integración bidireccional son aquellos en los que los datos fluyen hacia y desde cada extremo. Por ejemplo, es posible que necesite que los datos de clientes de SAP se creen en un extremo de destino y que cualquier cambio en los datos de clientes en ese extremo de destino se refleje en las funciones de clientes y socios en SAP.

Como las reglas de validación de datos de creación de objetos de SAP son más estrictas que las de otros extremos, esto requiere un trabajo personalizado tanto en el extremo como en SAP para gestionar las funciones de los socios. Este ejemplo muestra cómo trasladar cuentas de Salesforce a SAP y cómo gestionar la función de los socios:

adjunto

Captura de datos modificados para objetos de datos maestros

En general, los IDocs se utilizan para capturar datos modificados en SAP, ya que las BAPI y las RFC no pueden manejar consultas basadas en marcas de tiempo.

Los IDocs se pueden configurar para que se generen utilizando punteros de cambio asociados con un objeto, y se pueden generar para que contengan todos los datos o solo los cambios. Obtener todos los datos suele ser una mejor opción, ya que puede haber relaciones en los datos que sean necesarias para una actualización. Sin embargo, las actualizaciones masivas de datos pueden activar miles de IDocs a la vez, cuyo procesamiento puede superar los límites de inicio de sesión u otros límites en el extremo de destino.

Procesamiento directo

El procesamiento directo sigue este flujo de datos:

  1. El oyente de eventos de SAP recibe un IDoc.
  2. El SAP Event Listener mueve la carga útil a la cola de operación Jitterbit.
  3. La operación recibe el IDoc.
  4. Los datos IDoc se cargan en el extremo de destino.

Aunque el procesamiento es directo, considere estos efectos del procesamiento directo:

  • Si se envían miles de IDocs a la vez, el SAP Event Listener creará varias instancias de subprocesos y varias llamadas simultáneas. Si la llamada es para actualizar un extremo con límites de inicio de sesión, como Salesforce, el volumen de llamadas puede superar los límites de inicio de sesión.
  • Si el extremo de destino no es accesible, la carga útil IDoc no se entrega al destino final y se pierde.

Procesamiento de almacenamiento y reenvío

La alternativa al procesamiento directo es el procesamiento de almacenamiento y reenvío, donde la carga útil IDoc se escribe en un archivo temporal.

En la cadena de operación de ejemplo a continuación:

  1. La primera operación recibe un IDoc del SAP Event Listener y lo almacena localmente.

  2. La segunda operación se ejecuta con una programación rápida (por ejemplo, cada minuto) y escanea el directorio de archivos en busca de archivos para procesar. Cuando se encuentran archivos, se los recorre en bucle y cada archivo se pasa a la siguiente operación.

  3. Cuando se ejecuta la última operación de la cadena, se elimina el archivo y se repite el bucle hasta agotarlo. Si se produce un fallo técnico durante el proceso, el archivo no se elimina y se vuelve a procesar una segunda vez.

    Nota

    De manera predeterminada, los archivos temporales se almacenan durante 24 horas antes de eliminarse. Esto se puede configurar para un período más largo si es necesario.

attachment

adjunto

Al ejecutar operaciones en un ambiente de múltiples agentes, es posible que Agent 1 reciba un IDoc y lo almacene localmente, pero el programador puede seleccionar Agent 2, que no encontrará archivos para procesar. Los archivos no se procesarán hasta que el programador llame a Agent 1.

Tenga en cuenta que todos los archivos en los directorios temporales se procesarán hasta que se agoten. Si existe un requisito que exige que se garantice que los IDocs se procesen en orden, utilice un recurso compartido, como un sitio FTP, un sistema de archivos local o una base de datos. Sin embargo, agregar almacenes de datos externos puede crear un punto de falla adicional. Los clústeres de Agente se utilizan para la conmutación por error y el balanceo de cargas, por lo que el uso de almacenes de datos externos que no estén configurados de manera similar puede socavar la solidez general del sistema.

Extraer un ID para obtener datos adicionales

Si el IDoc tiene un ID, se puede llamar a una BAPI para obtener datos adicionales:

attachment

adjunto

En el ejemplo anterior, si nos fijamos en la tercera operación (3. Mat-Get Details), se lee el IDoc para recuperar el ID del material, que luego se utiliza para llamar a una RFC personalizada. Esta captura de pantalla muestra la transformación que extrae el ID del material:

adjunto

Tutoriales específicas de SAP

Esta sección proporciona tutoriales específicas de SAP para estos temas:

Manejo de fechas de finalización vacías

Si no se completa una fecha de finalización en SAP (como puede ser el caso en un acuerdo "permanente"), SAP enviará 00000000 en un IDoc, que se puede capturar y gestionar:

result = FindValue("108", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);
If(result == "00000000",
  RunScript("<TAG>Scripts/WTOL</TAG>", "No End Date, using 12/31/4000");
  result="40001231"
);
GetUTCFormattedDateTime(result, "UTC", false);
// The year 4000 is the maximum date used by Salesforce

Para obtener más detalles, consulte las funciones Jitterbit FindValue(), RunScript(), y GetUTCFormattedDateTime().

Encontrar funciones de clientes y socios

Al buscar la función de cliente o socio adecuada en SAP, preste especial atención a las abreviaturas alemanas.

Por ejemplo, al crear un pedido de venta, en la GUI de SAP puede ver un nombre como Sold-To Party o la función de socio equivalente específica del idioma SP, pero la API de SAP utiliza en cambio la abreviatura alemana AG como se muestra en la primera columna:

Función del socio Idioma Nombre Función del socio específica del idioma
AG EN Parte a la que se vende SP
RE EN Parte a la que se debe facturar BP
RG ES Pagador PY
WE EN Parte destinataria SH

Uso del generador de funciones de SAP para modelar una llamada API

Al mapear datos en una transformación usando un objetivo BAPI o RFC, es útil probar los valores exactos que SAP está buscando, ya que lo que se ve en la GUI de SAP a menudo no es lo que se usa en la API de SAP.

Puede utilizar el código de transacción SAP SE37 para acceder al generador de funciones de SAP y modelar una llamada BAPI o RFC. Para ver un ejemplo completo, consulte Parte 2: Modelado de la consultar en la instancia SAP en Guía para usar RFC_READ_TABLE para consultar tablas SAP.

Manejo de convenciones BAPI

Ciertas BAPI, como BAPI_SALESORDER_CREATEFROMDAT2 — tienen conjuntos de campos que requieren un manejo especial.

Como se muestra a continuación, los campos que están asignados en el encabezado (ORDER_HEADER_IN) se repiten en el *_INX carpeta. Para indicarle a SAP que desea completar los campos de encabezado, inserte un "X" como el valor del campo en cada uno de los campos que son una repetición de un campo de encabezado:

adjunto

Sin embargo, en el ORDER_ITEMS_INX sección, la ITM_NUMBER campo bajo ORDER_ITEMS_INX no tiene una "X" insertado; en su lugar, recibe el mismo número de artículo que se utiliza en el campo ORDER_ITEMS_IN:

adjunto

Manejo de funciones de socios con carpetas adicionales

En esta sección, debemos pasar SoldTo, ShipTo y BillTo. Hemos agregado carpetas adicionales para asignarlas y hemos establecido como predeterminados los roles de socio (AG, WE, RE):

attachment

Manejo de funciones de socio con elSetInstances función

Una alternativa para agregar nuevas carpetas es utilizar el SetInstances() Función sin carpetas adicionales:

attachment

En la condición raíz, crearíamos una serie de matrices dentro de una PartnersArray y configúrelo en el ORDER_PARTNERS usando:

SoldToParentArray = Array();
Set(SoldToParentArray, "AG", -1);
Set(SoldToParentArray, Order$Header$Sold_To_Customer_Number$, -1);

ShipToParentArray = Array();
Set(ShipToParentArray, "WE", -1);
Set(ShipToParentArray, Order$Lines$Line#1.Customer_Number$, -1); // new change

BillToParentArray = Array();
Set(BillToParentArray, "RE", -1);
Set(BillToParentArray, Order$Header$Bill_To_Customer_Number$, -1);

PartnersArray = Array();
Set(PartnersArray, SoldToParentArray, -1);
Set(PartnersArray, ShipToParentArray, -1);
Set(PartnersArray, BillToParentArray, -1);

SetInstances("ORDER_PARTNERS", PartnersArray);
True

En la carpeta condición bajo ORDER_PARTNERS para configurar las instancias utilizaríamos:

$instanceReference = GetInstance();
True

Para obtener más detalles, consulte las funciones Jitterbit Set(), GetInstance(), y SetInstances().

Manejo de números de línea incrementales

En la sección ORDER_SCHEDULES_IN, insertaríamos una vez más un "X" en los campos de datos.

adjunto

Para el campo SCHED_LINE SAP los incrementa en 10 (línea 10, línea 20, línea 30, etc.). Podemos utilizar una variable global contador en la condición bajo ORDER_SCHEDULES_IN para calcular el valor:

If(Length($ItemLineCounterS) == 0, $ItemLineCounterS = 0);
$ItemLineCounterS = $ItemLineCounterS + 10;
True

Para obtener más detalles, consulte la función Jitterbit Length().

Recuperación de valores de un IDoc

Aquí queremos obtener las fechas de inicio y finalización de un IDoc para crear un contrato. Los datos se encuentran aquí:

attachment

En E1EDP03, queremos el DATUM valor donde IDDAT == 107 (o 108) para las fechas de inicio y fin respectivamente. Una función útil para esto es Jitterbit FindValue() Función. Esta función recorrerá cíclicamente las IDDAT valores, encuentra el que tiene "107" y recuperar el DATUM campo:

result=FindValue("107", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);

Solución de problemas de confirmaciones BAPI

En algunos escenarios, es posible que, si bien la ejecución de una BAPI parece ser exitosa, la transacción esperada no está confirmada con SAP.

Esto puede ocurrir si una BAPI devuelve un tipo de respuesta que es distinto de S (Éxito). El conector SAP de Jitterbit, de manera predeterminada, emite una confirmación de transacción BAPI (en el mismo hilo) solo cuando una respuesta BAPI es Éxito. Sin embargo, no emite una confirmación de transacción si la respuesta BAPI es cualquier otra que no sea Éxito.

Por ejemplo, el tipo de respuesta puede ser I (Información), E(Error), o W(Advertencia). El tipo de respuesta se devuelve en el RETURN campo TIPO del nodo:

adjunto

Si está utilizando una BAPI personalizada, le recomendamos cambiarla para que devuelva un Éxito.