OpenUI5

SAP distribuye el framework UI5 en dos entregas. OpenUI5 es la open source; SAPUI5 es la que está integrada en productos SAP como SAP BTP y la plataforma ABAP. La diferencia principal es la licencia, no el modelo de programación.

De ese origen común se derivan tres hechos:

1. Mismo núcleo. El runtime, el data binding, el enrutamiento y las bibliotecas de controles más comunes, por ejemplo sap.m, sap.ui.layout y sap.ui.unified, son idénticos en ambas entregas.
2. Mismos nombres técnicos. Los nombres de controles, los nombres de bibliotecas y las API coinciden, de modo que el código escrito para OpenUI5 sigue funcionando cuando el runtime se cambia a SAPUI5.
3. Versiones alineadas. Ambas entregas siguen la misma línea de releases, aunque SAP advierte que los números de versión pueden diferir a nivel de parche. El diálogo de información técnica (Ctrl+Alt+Shift+P) muestra qué versión cargó realmente una aplicación.

SAPUI5 es, por tanto, un superconjunto: todo lo que contiene OpenUI5 más bibliotecas adicionales específicas de SAP. OpenUI5 es el subconjunto open source de SAPUI5, no un framework distinto.

Una comparación de las listas de bibliotecas publicadas para la release 1.154 muestra que todas las bibliotecas de OpenUI5 forman parte también de SAPUI5, mientras que SAPUI5 añade varias decenas más. Las carencias que más pesan en los proyectos SAP:

OpenUI5 sigue conteniendo un conjunto amplio: sap.m, sap.f, el object page layout de sap.uxap, sap.ui.table, los controles basados en metadatos de sap.ui.mdc, las bibliotecas de flexibilidad sap.ui.fl y sap.ui.rta, las integration cards y la biblioteca del tema SAP Horizon. La lista cambia entre releases, así que compruébela para la versión que utilice. OpenUI5 cubre los componentes básicos de una aplicación web completa, pero no las capas de SAP que generan o alojan aplicaciones SAP Fiori.

Aplique este criterio de decisión: si la aplicación depende del runtime de un producto SAP o de una biblioteca exclusiva de SAP, utilice SAPUI5; en caso contrario, OpenUI5 es una opción válida.

OpenUI5 encaja cuando:

• la aplicación se ejecuta fuera de los productos SAP, por ejemplo un portal web público o una herramienta interna sobre un back-end que no es de SAP;
• el proyecto es en sí mismo open source, como una herramienta UI5, un ejemplo o una biblioteca de controles personalizados, y no debe depender de código con licencia de SAP;
• un equipo está aprendiendo UI5 y quiere un runtime y una documentación de libre acceso.

SAPUI5 encaja cuando:

• la aplicación se ejecuta en el SAP Fiori Launchpad o en SAP Build Work Zone, que de todos modos cargan el runtime de SAPUI5;
• la aplicación utiliza SAP Fiori elements, smart controls o los gráficos de SAP;
• la aplicación se entrega en la plataforma ABAP o en SAP BTP, donde SAPUI5 forma parte del producto.

Para Alder Manufacturing, una página de autorregistro de proveedores para Cedar Office Supply en un servidor web que no es de SAP es candidata a OpenUI5; un list report de pedidos de compra en el launchpad no lo es. OpenUI5 es la opción adecuada cuando la independencia respecto de las licencias de productos SAP importa más que las bibliotecas específicas de SAP.

• Sin floorplans generados. Sin SAP Fiori elements, los list reports y object pages deben construirse a mano con controles estándar, por lo que el perfil de esfuerzo corresponde al de SAPUI5 freestyle, no al desarrollo basado en anotaciones.
• Sin runtime de launchpad propio. Las aplicaciones que deben ejecutarse en el SAP Fiori Launchpad lo hacen sobre el runtime SAPUI5 del launchpad, no sobre OpenUI5. En la práctica, una aplicación OpenUI5 que pasa a un entorno SAP se convierte en una aplicación SAPUI5.
• La persistencia de la flexibilidad es externa. Las bibliotecas de flexibilidad están incluidas, pero almacenar de forma productiva los cambios de key users y usuarios finales requiere un back-end: el repositorio por capas de un sistema ABAP o servicios de SAP BTP. Los conectores de almacenamiento en el navegador están pensados para pruebas.
• Modelo de soporte. Los errores y las solicitudes de funciones de OpenUI5 se plantean públicamente como issues de GitHub; que un contrato de soporte de SAP cubra un uso concreto de OpenUI5 depende de sus condiciones.

Estos límites se derivan de la propia división: OpenUI5 es el framework, mientras que SAPUI5 añade encima lo que necesitan los propios productos de SAP.

1. Empezar con OpenUI5 y descubrir tarde una dependencia. Un proyecto que más adelante necesita smart controls, SAP Fiori elements o exportación a hoja de cálculo tiene que pasar a SAPUI5. Solución: enumere las bibliotecas necesarias antes de elegir la entrega.
2. Equiparar OpenUI5 con el cumplimiento de SAP Fiori. Los controles de OpenUI5 siguen el diseño SAP Fiori, pero son el layout, la navegación y la redacción los que determinan si una aplicación sigue las SAP Fiori Design Guidelines. Solución: revise la aplicación con respecto a las directrices, no solo los controles.
3. Mezclar entregas en un mismo entorno. Cargar algunas aplicaciones desde la red de distribución de contenidos de OpenUI5 y otras desde la de SAPUI5 dificulta la comparación de versiones y el diagnóstico de problemas. Solución: utilice una sola entrega por aplicación y documéntela.
4. Ignorar las diferencias a nivel de parche. Los números de versión de OpenUI5 y SAPUI5 pueden divergir a nivel de parche. Solución: consulte el diálogo de información técnica cuando un error aparezca en una entrega pero no en la otra.

La mayoría de los problemas con OpenUI5 son decisiones de alcance tomadas demasiado pronto, no defectos del framework.