SAP Integration Suite: Introducción a Graph

Hace aproximadamente un año, en Julio de 2023, se liberó la nueva funcionalidad de Graph para SAP Integration Suite. Esta funcionalidad ha pasado un poco inadvertida por lo que en este artículo describimos en qué consiste Graph, que valor aporta y cuáles son sus pros y contras.

¿Comenzamos?

La funcionalidad de Graph es un complemento al servicio de API Management de SAP Integration Suite. Mediante API Management, es posible transformar y exponer APIs de forma segura, gestionando su ciclo de vida y controlando su consumo. Con Graph, además, es posible conectar los datos de forma semántica construyendo un grafo de datos de negocio (business data graph) y exponerlo para ser consumido a través de un API unificado (OData o GraphQL).

Por ejemplo, en la siguiente imagen podemos ver diferentes entidades de negocio relacionadas entre sí. Algunas de las relaciones ya existen en el backend, y otras son añadidas por Graph (las señaladas en negrita). Con una única llamada al API unificada de Graph podríamos obtener todos estos datos:

Desde un punto de vista de estrategia de SAP, el objetivo de Graph es exponer todos los datos de negocio de los backend SAP relacionados entre sí y con un punto de acceso único para facilitar su consumo. Para ello, se han definido diferentes tipos de “entidades” como se muestra a continuación.

Entidades en Graph

Un grafo de datos de negocio está formado por nodos (entidades de datos, como objetos de negocio o datos maestros), atributos (campos de estas entidades) y relaciones (asociaciones entre las entidades). Existen tres tipos de entidades en Graph que se detallan a continuación:

1. Mirrored Entities

Graph crea automáticamente entidades espejo, que son proyecciones de las entidades de los backends definidos en el landscape (sistemas SAP u otras fuentes de datos como aplicaciones CAP):

En el SAP Business Accelerator Hub (https://api.sap.com/graph) se pueden explorar las entidades disponibles de forma estándar para S/4HANA (sap.s4), SAP HCM (sap.hcm) y SAP Sales Cloud (sap.c4c):

El valor de Graph para este tipo de entidades son fundamentalmente las relaciones adicionales que aporta; por ejemplo, para un pedido de ventas (Sales Order) existen relaciones adicionales con organización de ventas (_SalesOrgnization), canal de distribución (_DistributionChannel) interlocutor comercial “soldToParty” (_SoldToParty), etc., identificadas en la definición de la entidad con el prefijo “_”:

(Fuente: SAP Business Accelerator Hub)

Visto de una forma más práctica, podemos ejecutar la siguiente query OData para recuperar el listado de pedidos con datos adicionales de la organización de ventas e interlocutor comercial de cada pedido utilizando para ello el parámetro “$expand” sobre las relaciones adicionales anteriormente citadas:

https://sandbox.api.sap.com/sapgraph/sap.s4/A_SalesOrder?$top=5&$select=SalesOrder,SalesOrderType&$expand=_SoldToParty($select=CustomerFullName),_SalesOrganization($select=CompanyCode,SalesOrganizationCurrency)

(Fuente: T4S)

A partir de la potencia del protocolo OData y estas relaciones adicionales de Graph, es posible construir consultas más complejas con expresiones anidadas. Por ejemplo, a la anterior consulta podemos añadirle la consulta de la información de las posiciones de cada pedido expandiendo el material asociado a cada posición:

https://sandbox.api.sap.com/sapgraph/sap.s4/A_SalesOrder?$top=5&$select=SalesOrder,SalesOrderType&$expand=_SoldToParty($select=CustomerFullName),_SalesOrganization($select=CompanyCode,SalesOrganizationCurrency),to_Item($select=SalesOrderItem,SalesOrderItemText,Material,RequestedQuantity;$expand=_Material($select=Product,ProductType;$expand=to_Description))

(Fuente: T4S)

2. Unified Entities

Adicionalmente a las entidades espejo anteriores, existen entidades unificadas en el namespace sap.graph que han sido creadas por expertos de SAP siguiendo el modelo SAP One Domain Model. Estas entidades unifican conceptos de negocio semánticamente similares de los diferentes sistemas SAP (S/4HANA, SAP HCM y SAP Sales Cloud).

El valor de Graph para estas entidades es poder consultar objetos de negocio o datos maestros con datos recuperados de diferentes backends de forma transparente, como la entidad “ContactPerson” que recupera información de S/4HANA y SAP Sales Cloud:

Aunque también se pueden recuperar datos de un determinado backend de forma explícita; siguiendo con el ejemplo de la entidad “ContactPerson”, dispone de asociaciones con la entidad “ContactCollection” de SAP Sales Cloud y la entidad A_BusinessPartner de S/4HANA:

(Fuente: SAP Business Accelerator Hub)

Visto de una forma más práctica, podemos ejecutar la siguiente query OData para recuperar datos de personas de contacto obteniendo información de la entidad unificada y de las entidades espejo relacionadas de cada sistema, S/4HANA (a través de la asociación _s4) y SAP Sales Cloud (a través de la asociación _c4c):

https://sandbox.api.sap.com/sapgraph/sap.graph/ContactPerson?$top=100&$select=id,displayId,firstName,lastName,title&$expand=_title($select=name),_c4c($select=ContactID,Phone,Mobile,Fax,Email,FormattedPostalAddressDescription),_s4($select=BusinessPartner,BusinessPartnerCategory,BusinessPartnerGrouping,BusinessPartnerName)

(Fuente: T4S)

3. Custom Entities

Existe un último tipo de entidades, las entidades a medida o custom. Como siempre sucede en SAP, el estándar no cubre el 100% de los casos de uso de los clientes, por lo que es necesario poder crear ampliaciones o adaptaciones. En el caso de Graph, mediante las entidades custom es posible crear nuevas entidades con nuevos atributos y relaciones a partir de otras entidades.

A continuación, os mostramos los pros y los contras que encontramos en Graph:

PROS:

• Simplifica el modo de acceso a la información a los desarrolladores, a través de un API unificado.
• Minimiza el número de llamadas entre la aplicación y Graph para recuperar los datos necesarios por la aplicación.
• Permite la creación de entidades a medida o custom sin alterar las APIs estándar de los backend.
• En las entidades unificadas, el mapeo de claves entre diferentes sistemas (key mapping) es transparente para el desarrollador.

CONTRAS:

• Es un servicio intermedio adicional en la arquitectura lo que supone un potencial punto de error más en las comunicaciones y que incrementa el tiempo de latencia.
• Al estar creadas las relaciones adicionales en Graph y no en el backend, aumenta el número de llamadas entre Graph y los backend. Este aumento dependerá del grafo modelado y las queries que se implementen, pero puede afectar negativamente al tiempo de respuesta y por tanto al rendimiento de las aplicaciones.
• Requiere esfuerzo adicional de configuración para exponer las APIs en Graph.
• Requiere licenciamiento de SAP Integration Suite.

Como conclusión, es una idea ambiciosa de SAP por el hecho de crear entidades unificadas para diferentes backend (S/4HANA, SAP HCM, SAP Sales Cloud), pero al ser un servicio separado de los backend pierde parte de las ventajas que tienen protocolos como GraphQL y OData cuando se implementan sobre ellos, sobre todo desde un punto de vista de rendimiento y optimización del número de llamadas a las APIs de estos backend.

¿Quieres saber más de SAP Integration Suite o estás pensando en migrar a esta plataforma? Conctacta con nosotros aquí.