Interrupción de la API de SAP

Gestión de la arquitectura API de SAP

Si la gestión de la arquitectura API no encaja exactamente en el esquema ERP proporcionado por SAP, existen considerables limitaciones y restricciones para los clientes SAP existentes. Especialmente alarmante es el hecho de que muchos usuarios y socios hayan tenido que recurrir a interfaces no documentadas que SAP toleró durante mucho tiempo en el pasado por falta de alternativas. Ahora, su uso supone de repente un incumplimiento de contrato y destruye modelos de negocio que funcionan.

Open Data Infrastructure Scorecard (ODI) ha analizado críticamente la disposición de los proveedores de software en la nube a conceder a sus clientes libre acceso a los datos de su propia empresa. Tradicionalmente, SAP sale muy mal parada en este tipo de evaluaciones, ya que la empresa erige cada vez más barreras propietarias, bloqueando el acceso directo a las bases de datos y, en concreto, las interfaces de alto rendimiento para la extracción de datos por parte de terceros proveedores.

ODI-Scorecard confirma implacablemente esta imagen, ya que SAP prohíbe la ruta directa desde S/4 a almacenes de datos externos como Microsoft Fabric, y bloquea la eficaz interfaz ODP (Operational Data Provisioning) para la extracción masiva de datos por parte de la competencia. Esta política de arquitectura restrictiva obliga de facto a los clientes a utilizar las costosas herramientas de integración propias de SAP, lo que se opone diametralmente a la idea básica de una infraestructura de datos abierta y cimenta una dura dependencia del proveedor.

Doctrina API para SAP BTP, SAP BDC y SAP Integration Suite

Para los clientes actuales de SAP, esta doctrina restrictiva de las API significa que deben extremar las precauciones al utilizar la Business Technology Platform (SAP BTP), la Business Data Cloud (SAP BDC o, como dice la asociación de usuarios DSAG, Business Data Complexity) y la SAP Integration Suite. El bloqueo de la extracción masiva directa de datos a lagos de datos externos obliga a los usuarios a recurrir a las soluciones SAP BDC o Datasphere, lo que da la impresión de que SAP ha erigido una barrera aduanera cerrada para el flujo de datos digitales.

Aunque SAP posiciona la BDC como un ecosistema de datos abiertos con tecnología de copia cero a través de socios como Databricks, la letra pequeña de las condiciones generales revela enormes trampas, ya que el uso de las API de SAP para la extracción de datos en software que no sea de SAP está explícitamente prohibido a menos que esto se haya documentado expresamente como una función de la API (véase también SAP Digital Access). Al planificar la arquitectura en el BTP, los clientes deben prestar una atención meticulosa para orquestar sólo las interfaces aprobadas, lo que aumenta drásticamente el esfuerzo de desarrollo para los procesos personalizados de extremo a extremo y ralentiza enormemente la tan necesaria agilidad empresarial (véase también el concepto SAP Clean Core).

Una mirada crítica a las licencias y condiciones de licencia de SAP API y SAP BDC revela un modelo comercial altamente tóxico a expensas de los clientes existentes. El modelo de acceso digital establecido por SAP ya ha garantizado durante años que la creación indirecta de documentos por parte de sistemas de terceros tenga que pagarse muy cara, lo que ahora amenaza con escalar por completo con la nueva política de API en la era de la IA, cuando los agentes autónomos de IA lean y escriban datos en masa.

Uso razonable de la complejidad de los datos empresariales (SAP BDC)

La asociación de usuarios DSAG teme una comercialización progresiva y reclama modelos transparentes de uso justo para el acceso a las API, ya que, de lo contrario, los costes de la transformación digital aumentarán desmesuradamente. Las condiciones de uso de SAP Business Data Cloud (BDC) también contienen restricciones contractuales flagrantes, como límites estrictos de solo 2.000 llamadas a la API de OData por gigabyte de memoria de cálculo al mes, que pueden dar lugar a tarifas adicionales incalculables cada vez que se supera este límite.

Además, SAP clasifica importantes servicios de BDC Connect en el denominado Grupo 2 de servicios de capacidad, en virtud del cual el Grupo se reserva el derecho de cancelar estos servicios sin sustitución con un plazo de seis meses, lo que destruye cualquier seguridad de inversión a largo plazo para el usuario en el ámbito de la infraestructura de datos.

En vista de estos inconvenientes, los clientes actuales de SAP deben evaluar urgentemente alternativas independientes para la gestión de API y la integración de datos. En lugar de depender ciegamente de SAP BDC y SAP Integration Suite, los proveedores independientes de plataformas de integración como servicio (iPaaS), como Boomi, ofrecen opciones alternativas cruciales para gestionar las API de forma flexible, rentable y sin las limitaciones de los desarrollos abap propietarios.

Boomi y JiVS: alternativas a SAP BTP y BDC

Boomi permite encaminar los datos a cualquier lago de datos en la nube, independientemente de la red, sin tener que someterse a la estricta hegemonía de datos de la empresa de Walldorf. Para la gestión de los datos históricos heredados y la preservación de la soberanía de los datos lejos de la costosa infraestructura SAP, plataformas como JiVS de Data Migration International también se están posicionando como una valiosa alternativa para gestionar el legado de la era ERP de forma legalmente conforme y aliviando permanentemente la carga del núcleo S/4.

No obstante, el problema fundamental sigue siendo que las herramientas externas también dependen de las API estrictamente reguladas por SAP, por lo que los proveedores alternativos deben buscar cada vez más formas creativas pero legalmente seguras de compensar la interfaz ODP bloqueada por SAP.

Clean Core como hoja de parra necesaria

No obstante, para que la gestión de las API de SAP en un entorno S/4 Cloud se organice estrictamente de acuerdo con la doctrina clean core de SAP, se requiere una reestructuración organizativa y técnica radical del Customer Centre of Expertise (CCoE) del cliente existente. El CCoE pasa de ser un administrador básico puramente operativo a una instancia de gobernanza estratégica que debe supervisar implacablemente cada llamada API y cada extensión BTP.

Como parte del estricto modelo de núcleo limpio, sólo las API de la lista blanca (nivel A) que se proporcionan a través de SAP Business Accelerator Hub y se orquestan a través de SAP Integration Suite se pueden utilizar para extensiones side-by-side en el BTP. Cualquier modificación directa o acceso de lectura no autorizado a las tablas internas de la base de datos (niveles C y D de núcleo limpio) está estrictamente prohibido.

Estas restricciones de núcleo limpio requieren el uso de herramientas de supervisión profesionales como SAP Cloud ALM para garantizar el cumplimiento de estos rígidos requisitos, así como el desarrollo de habilidades completamente nuevas en modelos de programación modernos como CAP (Cloud Application Programming Model) y RAP (RESTful Application Programming Model) con el fin de asignar la lógica crítica para el negocio en el BTP de una manera a prueba de futuro y compatible con la API.

Conclusión sobre la API de SAP

La recomendación urgente de la asociación de usuarios de habla alemana DSAG a sus miembros y a todos los clientes actuales de SAP es, por tanto, que no aborden la nueva política de SAP sin estar preparados y de forma acrítica. El grupo de interés exige a SAP definiciones claras sin demora, documentación completa y contractualmente vinculante de todas las API afectadas, así como periodos de transición realistas para que los modelos de integración existentes y altamente complejos no se derrumben de la noche a la mañana.

Se aconseja urgentemente a los actuales clientes de SAP que aseguren legalmente de inmediato las pruebas de concepto y los proyectos piloto de IA existentes y, en el caso de próximas ampliaciones de contrato, que se aseguren meticulosamente de que no se aceptan restricciones técnicas posteriores ni aumentos de costes ocultos por la puerta trasera del uso de la API.

En última instancia, el DSAG hace un llamamiento a la comunidad SAP para que defienda activamente su propia soberanía digital y exija a SAP una transparencia incondicional sobre el uso, el consumo y las consecuencias comerciales de la estrategia API, a fin de evitar que el grupo de software pierda toda su capacidad operativa de actuación en esta arriesgada fase de transformación.

Por ello, el DSAG reclama definiciones claras, una documentación completa de las API en cuestión y una seguridad de planificación fiable para clientes y socios, así como un mapeo en los contratos que permita una evaluación fiable de los casos de uso por parte del cliente. Las normativas correspondientes deben ser comprensibles y fáciles de entender. Además, no deben suponer un aumento de los costes para clientes y socios. „Con el telón de fondo de unas operaciones seguras y estables, también es importante para nosotros, como usuarios, disponer de total transparencia en cuanto a uso, consumo y consecuencias“, afirma Stefan Nogly, Director de Tecnología de DSAG.

Controlador: SAP API Policy

Desde el punto de vista del GASD, el diseño actual de la política de API plantea dudas. El alcance de las restricciones parece ir más allá del nivel técnico necesario. Para garantizar la capacidad de innovación y la seguridad de planificación de clientes y socios a largo plazo, estos puntos abiertos deben aclararse lo antes posible en cooperación entre SAP y DSAG.

Bien mirado, la actual estrategia de API de SAP se asemeja a un control estratégico sobre la soberanía absoluta de los datos que supone una enorme amenaza para la fuerza innovadora de los clientes existentes. Con la Política de API de SAP, que se endureció en abril de 2026, la empresa de software con sede en Walldorf está regulando rigurosamente las condiciones en las que los clientes y socios pueden transferir datos a sistemas de terceros. En el futuro, sólo se permitirán aquellas interfaces que estén explícitamente identificadas en el „SAP Business Accelerator Hub“ o en la documentación oficial del producto. El grupo de usuarios de SAP de habla alemana (DSAG) critica duramente esta medida en un reciente comunicado de prensa y denuncia la falta de carácter contractualmente vinculante de esta documentación, que supone una amenaza existencial para la seguridad jurídica y de planificación tecnológica de los usuarios.