Una guía para la integración de datos SAP

Hoy en día, SDI se utiliza en todas las soluciones Hana y los clientes lo dan por sentado. Con el siguiente paso evolutivo, quería unir la integración de datos y procesos de una forma que nunca se había hecho antes. Por fin, la tecnología había avanzado lo suficiente como para poder fusionar las dos categorías de productos. Pero esto chocaba con la estructura organizativa de SAP y no se asumió.

Hoy en día, el problema de la integración ha saltado a la palestra y el resultado no es precisamente convincente. Peor aún, veo que muchos clientes actuales de SAP resuelven por sí mismos este problema de integración de forma inteligente, es decir, que ya van más adelantados que la propia SAP. Estos clientes obtienen el toque final de la solución de código abierto que ofrece mi empresa.

A continuación, me gustaría hacer un recorrido mental por las ideas que tenían estos pioneros y por los aspectos en los que las hemos mejorado.

Integración de sistemas frente a integración de datos

Si se observa la cartera de productos de SAP, se distingue claramente entre integración de procesos e integración de datos. Por un lado, se quiere conectar el sistema ERP con otra aplicación, por otro, se quiere transferir contenidos de tablas de A a B. Si se pregunta a un desarrollador de aplicaciones, habla de "entidades" como el socio comercial. En la integración de datos, se va un nivel más allá, a las tablas. Esta separación no existe en el mundo del Big Data. Allí, todos los productos pueden tratar con objetos profundamente anidados y una tabla de base de datos no es más que un objeto particularmente simple. Esto nos lleva a la primera conclusión: olvidémonos de las herramientas de bases de datos y fijémonos mejor en los productos de Big Data.

Lote frente a tiempo real

Luego, hay herramientas que transfieren datos masivos en un proceso por lotes, y otras están construidas para el tiempo real. Esta separación tiene razones técnicas, pero desde un punto de vista puramente lógico, el tiempo real es un superconjunto de los dos. En batch, nunca se pueden transmitir datos a intervalos arbitrariamente cortos. Con un sistema en tiempo real, sin embargo, es posible el procesamiento por lotes. Parece como si en una fuente no pasara nada durante horas y de repente -durante un breve intervalo- se generaran muchos datos. Para ello, sin embargo, la herramienta en tiempo real debe ser capaz de manejar datos masivos, lo que nos lleva de nuevo a la cartera de Big Data.

Si observamos la solución desde el punto de vista de qué sistemas están vinculados con cuáles, en el pasado era más bien una relación de uno a uno. Los datos de SAP ERP van a SAP BW. Los datos de registro de tiempos acaban como reservas en el módulo SAP HCM. Y así es exactamente como están construidas las herramientas SAP. Aunque esta suposición no era necesariamente correcta en el pasado, hoy en día hay muchos sistemas consumidores conectados a cada sistema fuente, y la tendencia va en aumento. Por ejemplo, los datos de ERP van a SAP BW, a un lago de datos, a Ariba, a Salesforce y a otras innumerables aplicaciones empresariales inteligentes.

Esto significa que incluso con la orquestación de datos, como es habitual en todas las herramientas de SAP, no se llega muy lejos. Tiene más sentido que cada consumidor pueda servirse de los datos a su antojo, es decir, una coreografía de datos. En una configuración de este tipo, el director de orquesta ya no dicta quién tiene que hacer qué y cuándo, sino que existe un canal para cada objeto en el que los sistemas pueden publicar cambios y otros sistemas pueden consumir los cambios como consideren oportuno.

Por ejemplo, el ERP publicaría la última versión cada vez que se modificara la entrada de un interlocutor comercial y el BW la consumiría una vez al día de una sola vez. Otra aplicación, en cambio, escucha constantemente los cambios en este tema y puede integrarlos en su propia aplicación con una latencia del orden de milisegundos.

Apache Kafka

Si juntas todos estos pensamientos, inevitablemente acabas con Apache Kafka. Esta no es la única razón por la que Kafka es utilizado actualmente por todas las grandes empresas y se está consolidando cada vez más como un estándar. Si funciona para el mundo del Big Data, seguro que podemos hacer un buen uso de él para los datos operativos, ¿verdad?

En su núcleo, Apache Kafka consta de "temas" que representan el canal de datos. Cada uno de estos temas puede particionarse en sí mismo para permitir la paralelización de los datos masivos. Y cada mensaje de cambio tiene un esquema con los datos asociados. Así, en nuestro ejemplo, hay un esquema "socio comercial" con los datos maestros, como el nombre y los apellidos, y todas las direcciones del cliente están anidadas en él. Si se mira desde el punto de vista de la integración de datos, se trata de las tablas KNA1 de SAP ERP con los datos de direcciones ADRC asociados. En la integración de procesos, la estructura anidada se utiliza, por ejemplo, a través de SAP IDocs o Bapis.

Esto supone un trabajo extra para el único productor, pero facilita mucho las cosas para los numerosos consumidores. En un mundo en el que hay muchos consumidores para cada sector, esta es la forma más rentable en general.

Pero ahora no basta con entregar cada IDoc a Kafka, por ejemplo, y detrás de mí el diluvio. En todo caso, hay que movilizar todo su potencial. Una de esas oportunidades gira en torno a los cambios en la estructura: la muerte de cualquier solución de integración actual. Ni es viable adaptar todos los productores y consumidores de forma sincrónica, ni tiene sentido mantener varias versiones de la estructura al mismo tiempo. Por eso sigo el concepto de evolución del esquema, la capacidad de ampliar un esquema sin romper nada.

El caso más sencillo se explica fácilmente: supongamos que hay dos productores y diez consumidores de datos maestros de interlocutores comerciales. Uno de los productores, el sistema SAP, ha recibido hoy un campo Z adicional. El productor SAP lo inserta en el esquema oficial y le da un valor por defecto . A partir de ahora, el sistema SAP también puede enviar este campo.

El otro productor sigue utilizando la versión anterior del esquema durante los 20 minutos siguientes hasta que se resincroniza. El cambio al nuevo esquema no le despista, sin embargo, porque este campo no existe para él, así que no lo rellena, por lo que permanece en . No hay que cambiar nada en este productor, simplemente sigue funcionando como antes.

Si los consumidores reciben la nueva variante del esquema por primera vez, se utilizará para leer todos los mensajes a partir de ahora. Por lo tanto, el campo adicional está siempre presente. Si se lee un mensaje antiguo a través del nuevo esquema, el campo Z no está en los datos y, por tanto, . Tampoco en este caso hay complicaciones.

Los consumidores, a su vez, pueden decidir por sí mismos cómo manejar el nuevo campo. Un consumidor de aplicaciones sólo obtiene del esquema los campos que realmente necesita de todos modos, y el campo Z no tiene equivalente en la aplicación de destino por el momento. Un consumidor de lago de datos probablemente amplíe la estructura de destino con este campo adicional de forma automática para no perder nunca información.

La evolución del esquema permite así la adaptación sucesiva del esquema oficial a lo largo del tiempo. También hay casos en los que el productor desea enviar información técnica. Cada esquema dispone de una zona de extensión reservada a tal efecto.

En general, el esquema contiene alguna información más que puede ser interesante más adelante: ¿Cuál es el sistema de origen del mensaje? ¿Qué transformaciones han sufrido los datos? ¿Cómo se evalúa la calidad de los datos del registro?

Cola de mensajes frente al registro de transacciones de Kafka

El caso en el que un consumidor vio el campo adicional pero no pudo utilizarlo muestra otro problema sin resolver: ¿Cómo volver a obtener los datos ya cargados? Antes de la época de Kafka, se utilizaban colas de mensajes, y allí la única forma de volver a obtener todos los datos es que la fuente los produzca de nuevo. Sin embargo, esto significa que fluye a través de todos los consumidores, incluso los que no tienen ningún interés en ella. Si el siguiente consumidor se adapta, hay que volver a producir todos los datos. Qué horror. Por eso las colas de mensajes nunca se extendieron tanto como se esperaba en un principio.

Sin embargo, la premisa de nuestra solución era que el consumidor pudiera decidir qué leer y cuándo. En este caso, también debería tener la opción de poder volver a leer los datos que ya se han leído. En la práctica, este consumidor se modificaría a voluntad y, cuando se reiniciara, se le diría que por favor volviera a leer los datos de los últimos siete días. A diferencia de las colas de mensajes, Kafka no tira los datos inmediatamente, sino que está construido como una herramienta de Big Data para mantener los mensajes de cambio durante un tiempo o incluso para siempre.

Esta opción supone una inmensa ventaja para muchas otras situaciones. Por ejemplo, el desarrollador puede repetir las mismas pruebas tantas veces como desee y obtener los mismos datos de cambios. O un nuevo consumidor no empieza sin datos, sino que obtiene una gran cantidad de datos en la primera llamada.

Si usted también busca una solución asequible, abierta y orientada al futuro para la integración de sus diversas aplicaciones, puede encontrar inspiración en mi sitio web.