Mejores Prácticas para SAP¶

Introducción¶

Hay una serie de cuestiones y consideraciones únicas 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 de IDoc y los formatos de fecha.

Terminología¶

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

Terminología de SAP¶

• SAP: Cuando nos referimos a SAP, nos referimos a una versión de SAP que sea compatible con Harmony Design Studio SAP Connector. El componente esencial que requiere Design Studio SAP Connector es una versión de SAP que utiliza el SAP Java Connector (SAP JCo). Esto incluye ECC versión 6 o posterior y SAP S/4HANA en las instalaciones.
• 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 pedidos de cliente. Originalmente utilizado para intercambiar datos entre sistemas SAP, IDocs también se puede 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 SOAP o REST es que BAPI tiene un solo método y es específico para un objeto. Por ejemplo, hay 60 BAPI relacionados únicamente con el objeto de cliente de SAP. Los BAPI son entregados y mantenidos 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 las actualizaciones de SAP. Algunas RFC son estándar y las proporciona SAP. Los RFC personalizados también se pueden crear para admitir integraciones y deben ser mantenidos por el cliente de SAP.

Terminología de Jitterbit¶

• Conector SAP: El conector SAP de Harmony Design Studio utiliza SAP Java Connector (SAP JCo) para trabajar con objetos de SAP y es compatible con ECC versión 6 o posterior, y SAP S/4HANA local. SAP Connector se puede usar de forma inmediata para las comunicaciones entrantes de SAP desde Harmony a SAP mediante RFC, BAPI o IDoc.
• Oyente 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 de SAP Connector escuchando y recibiendo SAP-IDocs salientes. Usando el protocolo RFC transaccional (tRFC), los IDocs se envían en un lote sin un orden definido. Usando 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 SAP¶

Como práctica recomendada, al actualizar datos en SAP, suele ser preferible usar un BAPI o RFC que usar un IDoc. La razón principal de esto es que 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 falla un IDoc, se requiere la acción del usuario para volver a procesar 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 gestionar una única actualización de registro. Un escenario de actualización masiva puede requerir el uso de un IDoc.
• Se puede usar un IDoc para capturar datos modificados, mientras que BAPI y RFC no pueden manejar consultas basadas en marcas de tiempo.
• Puede haber una funcionalidad que un IDoc pueda invocar que no esté disponible mediante un BAPI o RFC.

Estructura IDOC¶

La estructura de un IDOC es plana. Aunque el XML se ve como si fuera jerárquico, los nodos repetidos en realidad no están anidados dentro de los nodos principales.

En la estructura de ejemplo a continuación, 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 del país), el formato de datos para las API de SAP es yyyy-mm-dd.

Patrones de Integración¶

Esta sección presenta patrones de integración comunes que se pueden usar para interactuar con los 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 SoldTo y BillTo, con un cliente diferente como ShipTo.
• Un cliente podría ser un SoldTo con muchos otros clientes como ShipTos (un caso común donde 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 para las funciones de los clientes y los socios.

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 construir la relación. Como BillTo contiene la dirección de facturación, con frecuencia la definición del cliente del extremo necesita direcciones principales 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 solo IDoc de SAP da como resultado una modificación tanto de una cuenta como de 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 se creen datos de clientes de SAP en un extremo de destino, y que cualquier cambio en los datos de clientes en ese punto extremo 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 mismo SAP para manejar las funciones del socio. Este ejemplo muestra el traslado de 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 las BAPI y las 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 contener todos los datos o solo los cambios. Por lo general, obtener todos los datos es 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 desencadenar miles de IDocs a la vez, cuyo procesamiento puede exceder el 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 de 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, SAP Event Listener instanciará varios subprocesos y creará varias 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 alcanzar el extremo final de destino, la carga útil de IDoc no se entrega al destino final y se pierde.

Procesamiento de Almacenamiento y Envío¶

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

En la siguiente cadena de operación de ejemplo:

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

2. La segunda operación tiene una programación rápida (como cada minuto) y escanea el directorio de archivos en busca de archivos para procesar. Cuando se encuentran archivos, los archivos se repiten 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 el ciclo se repite hasta que se agota. Si hay una falla técnica durante el proceso, el archivo no se elimina y se vuelve a procesar por segunda vez.

   Nota

   De forma predeterminada, los archivos temporales se almacenan durante 24 horas antes de eliminarse. Esto es configurable 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 al 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 en los directorios temporales se procesarán hasta que se agoten. Si existe un requisito de que se debe garantizar 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 adicional de falla. 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.

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

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

En el ejemplo anterior, observando la tercera operación (3. Mat-Get Details), 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

• Búsqueda de funciones de cliente y socio

• Uso de SAP Function Builder para modelar una llamada API

• Manejo de convenciones BAPI

• Recuperación de valores de un IDoc

• Resolución de problemas de confirmaciones de BAPI

Manejo de Fechas de Finalización Vacías¶

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

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

Búsqueda de Funciones de Cliente y Socio¶

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

Por ejemplo, al crear un pedido de ventas, en SAP GUI puede ver un nombre como Soldado a parte o la función de socio equivalente específica del idioma SP, pero la API de SAP usa la abreviatura alemana AG como se muestra en la primera columna.:

Uso de SAP Function Builder para Modelar una Llamada API¶

Al asignar datos en una transformación mediante un objetivo BAPI o RFC, es útil probar los valores exactos que busca SAP, 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 usar 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 se asignan en el encabezado (ORDER_HEADER_IN) se repiten en el *_INX carpeta. Para decirle a SAP que tiene la intención de completar los campos del encabezado, inserte un "X" como valor de 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 "X" insertado; en su lugar, recibe el mismo número de artículo que se usa en el campo ORDER_ITEMS_IN:

Manejo de Funciones de Socios con Carpetas Adicionales¶

En esta sección, debemos pasar SoldTo, ShipTo y BillTo. Hemos agregado carpetas adicionales para mapearlas y hemos predeterminado las funciones de los socios (AG, WE, RE):

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

Una alternativa a la adición de nuevas carpetas es utilizar el SetInstances() función sin carpetas adicionales:

En la condición raíz, crearíamos una serie de arreglos dentro de un PartnersArray y ajústelo a la 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 que 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, insertaríamos una vez más 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().

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

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 el Jitterbit FindValue() función. Esta función hará un ciclo a través de la 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 de BAPI¶

En algunos escenarios, puede encontrar que, aunque la ejecución de una BAPI parece ser exitosa, la transacción esperada no está confirmada en 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 de BAPI es diferente a É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 un BAPI personalizado, le recomendamos que cambie el BAPI para que devuelva un Éxito.