OpenUI5

A SAP entrega o framework UI5 em duas distribuições. O OpenUI5 é a distribuição open source; o SAPUI5 é a integrada aos produtos SAP, como o SAP BTP e a plataforma ABAP. A principal diferença é a licença, não o modelo de programação.

Três fatos decorrem dessa origem comum:

1. Mesmo núcleo. O runtime, o data binding, o roteamento e as bibliotecas de controles mais comuns, por exemplo sap.m, sap.ui.layout e sap.ui.unified, são idênticos nas duas distribuições.
2. Mesmos nomes técnicos. Nomes de controles, nomes de bibliotecas e APIs coincidem, então o código escrito para o OpenUI5 continua funcionando quando o runtime é trocado para o SAPUI5.
3. Versões alinhadas. As duas distribuições seguem a mesma linha de releases, embora a SAP observe que os números de versão podem diferir no nível de patch. O diálogo de informações técnicas (Ctrl+Alt+Shift+P) mostra qual versão o app realmente carregou.

O SAPUI5 é, portanto, um superconjunto: tudo o que há no OpenUI5 mais bibliotecas adicionais específicas da SAP. O OpenUI5 é o subconjunto open source do SAPUI5, não um framework separado.

Uma comparação das listas de bibliotecas publicadas para a release 1.154 mostra que toda biblioteca do OpenUI5 também faz parte do SAPUI5, enquanto o SAPUI5 acrescenta várias dezenas de outras. As lacunas que mais pesam em projetos SAP:

O OpenUI5 ainda contém um conjunto amplo: sap.m, sap.f, o object page layout em sap.uxap, sap.ui.table, os controles orientados a metadados em sap.ui.mdc, as bibliotecas de flexibilidade sap.ui.fl e sap.ui.rta, integration cards e a biblioteca do tema SAP Horizon. A lista muda entre releases, então verifique-a para a versão-alvo. O OpenUI5 cobre os blocos de construção de um app web completo, mas não as camadas da SAP que geram ou hospedam apps SAP Fiori.

Use este critério de decisão: se o app depende do runtime de um produto SAP ou de uma biblioteca exclusiva da SAP, use o SAPUI5; caso contrário, o OpenUI5 é uma escolha válida.

O OpenUI5 é adequado quando:

• o app roda fora dos produtos SAP, por exemplo um portal web público ou uma ferramenta interna sobre um back-end não SAP;
• o próprio projeto é open source, como uma ferramenta UI5, um exemplo ou uma biblioteca de controles customizados, e não pode depender de código licenciado pela SAP;
• uma equipe está aprendendo UI5 e quer um runtime e uma documentação disponíveis gratuitamente.

O SAPUI5 é adequado quando:

• o app roda no SAP Fiori Launchpad ou no SAP Build Work Zone, que carregam o runtime do SAPUI5 de qualquer forma;
• o app usa SAP Fiori elements, smart controls ou gráficos da SAP;
• o app é entregue na plataforma ABAP ou no SAP BTP, onde o SAPUI5 faz parte do produto.

Para a Alder Manufacturing, uma página de autocadastro de fornecedores para a Cedar Office Supply em um servidor web não SAP é candidata ao OpenUI5; um list report de pedidos de compra no launchpad não é. O OpenUI5 é a escolha certa quando a independência do licenciamento de produtos SAP pesa mais do que as bibliotecas específicas da SAP.

• Sem floorplans gerados. Sem o SAP Fiori elements, list reports e object pages precisam ser construídos à mão com controles padrão, então o perfil de esforço é o do SAPUI5 freestyle, não o do desenvolvimento orientado a anotações.
• Sem runtime de launchpad próprio. Apps que devem rodar no SAP Fiori Launchpad rodam no runtime SAPUI5 do launchpad, não no OpenUI5. Na prática, um app OpenUI5 que passa para um landscape SAP se torna um app SAPUI5.
• A persistência da flexibilidade é externa. As bibliotecas de flexibilidade estão incluídas, mas armazenar alterações de key users e de usuários finais em produção exige um back-end: o layered repository de um sistema ABAP ou serviços do SAP BTP. Os conectores de armazenamento no navegador servem para testes.
• Modelo de suporte. Bugs e pedidos de funcionalidade do OpenUI5 são registrados publicamente como issues no GitHub; se um contrato de suporte SAP cobre determinado uso do OpenUI5 depende dos termos desse contrato.

Esses limites decorrem da própria divisão: o OpenUI5 é o framework, enquanto o SAPUI5 acrescenta o que os próprios produtos da SAP precisam.

1. Começar no OpenUI5 e descobrir uma dependência tarde demais. Um projeto que mais adiante precisa de smart controls, SAP Fiori elements ou exportação para planilha tem de migrar para o SAPUI5. Correção: liste as bibliotecas necessárias antes de escolher a distribuição.
2. Igualar OpenUI5 a conformidade com o SAP Fiori. Os controles do OpenUI5 seguem o design SAP Fiori, mas layout, navegação e textos decidem se um app segue as SAP Fiori Design Guidelines. Correção: revise o app em relação às diretrizes, não apenas os controles.
3. Misturar distribuições em um mesmo landscape. Fazer o bootstrap de alguns apps a partir da content delivery network do OpenUI5 e de outros a partir da do SAPUI5 dificulta comparações de versão e troubleshooting. Correção: use uma distribuição por app e documente-a.
4. Ignorar diferenças no nível de patch. Os números de versão do OpenUI5 e do SAPUI5 podem divergir no nível de patch. Correção: verifique o diálogo de informações técnicas quando um bug aparece em uma distribuição e não na outra.

A maioria dos problemas com o OpenUI5 são decisões de escopo tomadas cedo demais, não defeitos do framework.