Mejores Prácticas para SAP¶

Introducción¶

Hay una serie de cuestiones y consideraciones únicas para los proyectos de integración de SAP, particularmente 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 de IDoc y los formatos de fecha.

Terminología¶

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

Terminología SAP¶

• SAP: Cuando nos referimos a SAP, nos referimos a una versión de SAP que es compatible con Harmony Design Studio SAP Connector. El componente esencial que requiere Design Studio SAP Connector es una versión de SAP que utilice 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). Hay IDOC para objetos de datos maestros, como clientes y proveedores, así como para objetos transaccionales como, por ejemplo, pedidos de cliente. Los IDOC, que originalmente se utilizaban para intercambiar datos entre sistemas SAP, también se pueden utilizar para la integración con 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 método único y es específica de un objeto. Por ejemplo, hay 60 BAPI relacionadas únicamente con el objeto de cliente de SAP. Las BAPI son entregadas y mantenidas por SAP.
• RFC: Una RFC (llamada de función remota) es lo mismo que una BAPI, excepto que una RFC puede mantenerse o no en todas las actualizaciones de SAP. Algunos RFC son estándar y los proporciona SAP. También se pueden crear RFC personalizados para admitir integraciones y el cliente de SAP debe mantenerlos.

Terminología de Jitterbit¶

• Conector SAP: El conector SAP de Harmony Design Studio utiliza Conector Java SAP (SAP JCo) para trabajar con objetos de SAP y es compatible con ECC versión 6 o posterior, y SAP S/4HANA local. El conector SAP se puede utilizar de forma inmediata para comunicaciones entrantes de SAP desde Harmony a SAP mediante RFC, BAPI o IDoc.
• Escucha de eventos de SAP: Jitterbit SAP Event Listener es una aplicación que se instala y 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. Utilizando el protocolo RFC transaccional (tRFC), los IDOC se envían en lote sin un orden definido. Utilizando el protocolo RFC en cola (qRFC), SAP Event Listener responde a SAP después de recibir cada IDoc, indicando a SAP que envíe el siguiente IDoc en la transacción.

Actualización de Datos de SAP¶

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

• Una actualización exitosa a menudo tiene ID de registro en la respuesta, que se pueden usar 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 devuelve es un código que indica que se recibió; no hay indicios de éxito o fracaso. Los IDOC se procesan en SAP de forma asíncrona. Si un IDoc falla, se requiere la acción del usuario para reprocesar el IDoc.

Hay ciertos escenarios en los que es preferible un IDOC:

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

Estructura 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 siguiente, todos los segmentos del padre IDOC están en el mismo subnivel. La información del encabezado está al mismo nivel que la información del artículo:

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 (o una combinación de) funciones de socio, 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 ShipTos (un caso común en el que un cliente de franquicia tiene muchas ubicaciones)

Al utilizar el objeto de cliente de SAP en proyectos de integración, es esencial tener un conocimiento profundo de los requisitos de integración tanto para los clientes como para las funciones del socio.

Con una carga inicial de datos, en general, los clientes SoldTo deben cargarse primero, ya que los otros clientes dependen de que SoldTo exista en el extremo de destino para poder construir 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 tiene que actualizar el cliente SoldTo con la dirección BillTo en el extremo.

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

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 del cliente de SAP se creen en un extremo de destino y que cualquier cambio en los datos del cliente 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 el propio SAP para manejar las funciones del socio. Este ejemplo muestra cómo mover cuentas de Salesforce a SAP y maneja la gestión de funciones de socios:

Captura de Datos Modificados para Objetos de Datos Maestros¶

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

Los IDOC 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 se necesitan para una inserción. Sin embargo, las actualizaciones masivas de datos pueden activar miles de IDOC a la vez, cuyo procesamiento puede exceder 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. SAP Event Listener recibe un IDoc.
2. SAP Event Listener mueve la carga útil a la cola de operación de 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 IDOC a la vez, SAP Event Listener creará instancias de múltiples subprocesos y creará múltiples llamadas simultáneas. Si la llamada es para actualizar un extremo con límites de inicio de sesión, como Salesforce, entonces el volumen de llamadas puede exceder los límites de inicio de sesión.
• Si no se puede acceder al extremo de destino, 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 IDOC se escribe en un archivo temporal.

En la cadena de operación de ejemplo siguiente:

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

2. La segunda operación se realiza en 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 recorre en bucle y cada archivo pasa a la siguiente operación.

3. Cuando se ejecuta la última operación de la cadena, se elimina el archivo y el bucle se repite hasta que se agota. Si hay una falla técnica durante el proceso, el archivo no se elimina y se reprocesa por segunda vez.

   Nota

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

Cuando se ejecutan operaciones en un ambiente de múltiples agentes, el Agente 1 puede recibir un IDOC y almacenarlo localmente, pero la programación puede seleccionar el Agente 2, que no encontrará archivos para procesar. No será hasta que el programador llame al Agente 1 que se procesarán sus archivos.

Tenga en cuenta que todos los archivos de los directorios temporales se procesarán hasta que se agoten. Si existe el requisito de que se deba garantizar que los IDOC 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 adicional de falla. Los clústeres de Agente se utilizan para conmutación por error y 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.

Extracción de una Identificación para Obtener Datos Adicionales¶

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

En el ejemplo anterior, al observar la tercera operación (3. Mat-Obtener detalles), se lee el IDOC para recuperar el ID del material, que luego se usa para llamar a un RFC personalizado. Esta captura de pantalla muestra la transformación extrayendo el ID del material:

Tutoriales Específicos de SAP¶

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

• Manejo de fechas de finalización vacías

• Encontrar funciones de clientes y socios

• Uso de SAP Function Builder para modelar una llamada API

• Manejo de convenciones BAPI

• Recuperar valores de un IDoc

• Solución de problemas de confirmaciones BAPI

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 manejar:

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 más detalles, consulte las funciones de 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 ventas, en la GUI de SAP es posible que vea un nombre como Sold-To Party o la función de socio equivalente específica del idioma SP, pero la API de SAP utiliza la abreviatura alemana AG como se muestra en la primera columna.:

Uso de SAP Function Builder 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 busca, 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 de SAP SE37 para acceder al Generador de funciones de SAP para modelar una llamada BAPI o RFC. Para ver un ejemplo completo, consulte Parte 2: Modelado de la consulta en la instancia de SAP en Guía para usar RFC_READ_TABLE para consultar tablas de SAP.

Manejo de Convenciones BAPI¶

Ciertos BAPI, como BAPI_SALESORDER_CREATEFROMDAT2 — tener 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:

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

Manejo de Funciones de Socios con Carpetas Adicionales¶

En esta sección, debemos pasar SoldTo, ShipTo y BillTo. Agregamos carpetas adicionales para mapearlas y establecimos los roles de socio predeterminados (AG, WE, RE):

Manejo de Funciones de Socios con el SetInstances Función¶

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

En la condición raíz, crearíamos una serie de matrices dentro de un PartnersArray y configúrelo en 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 condición de carpeta bajo ORDER_PARTNERS, para establecer las instancias usaríamos:

$instanceReference = GetInstance();
True

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

Manejo de Números de Línea Incrementales¶

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

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

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

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

Recuperar 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í:

En E1EDP03, queremos el DATUM valor donde IDDAT == 107 (o 108) para las fechas de inicio y finalización respectivamente. Una función útil para esto es el Jitterbit. FindValue() función. Esta función recorrerá el IDDAT valores, encuentre 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, aunque la ejecución de una BAPI parezca exitosa, la transacción esperada no está comprometida con SAP.

Esto puede ocurrir si una BAPI devuelve un tipo de respuesta diferente a S (Éxito). El conector SAP de Jitterbit, de forma 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 no es É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:

Si está utilizando una BAPI personalizada, le recomendamos cambiar la BAPI para devolver un Success.