HTML5 Application Repository

O repositório separa o lugar onde os arquivos de UI ficam armazenados daquilo que os entrega:

1. Um desenvolvedor constrói um app SAPUI5, normalmente no SAP Business Application Studio, e o empacota em uma multitarget application.
2. Na implantação, o HTML5 application deployer envia os arquivos estáticos do app para uma instância de serviço do plano app-host.
3. Um application router vinculado a uma instância app-runtime recupera esses arquivos em tempo de execução, autentica o usuário e encaminha as chamadas de dados aos back-ends por meio de destinations.
4. A SAP recomenda o application router gerenciado pela SAP, que não precisa de runtime próprio; um router autogerenciado se destina a casos avançados, como extensões do router.

Como os arquivos ficam desacoplados do router, uma nova versão do app entra no ar sem reiniciar nada, e o serviço mantém versões e faz cache do conteúdo. O HTML5 Application Repository é armazenamento e entrega de arquivos de UI, não um runtime para lógica de negócio.

Quando um subaccount assina o SAP Build Work Zone, um content provider HTML5 Apps aparece automaticamente no Channel Manager. Ele reflete os apps implantados no repositório desse subaccount. Para exibir um app em um site:

1. Descreva-o no manifest.json: um app ID único, um nome de business service (sap.cloud.service) e um inbound com semantic object e action.
2. Implante-o no mesmo subaccount da assinatura do SAP Build Work Zone.
3. Atualize o content provider HTML5 Apps no Channel Manager.
4. Adicione o app no Content Explorer, depois atribua-o a grupos, catálogos e roles, e as roles a um site.

Um erro frequente é pular o passo 3 e não entender por que uma nova versão não aparece. O HTML5 Application Repository entrega os arquivos, enquanto o SAP Build Work Zone decide quem vê o tile.

Pontos fortes

• Atualizações sem indisponibilidade: o conteúdo muda sem reiniciar o application router.
• Entrega serverless: com o application router gerenciado, uma UI não precisa de nenhuma instância de aplicação em execução.
• Compartilhamento e versionamento: apps públicos podem ser consumidos por routers de outros spaces, e o conteúdo pode ser explorado por versão.

Onde ele para

• Somente conteúdo estático. Serviços OData, lógica de negócio e dados ficam em outro lugar, por exemplo em CAP, RAP ou no SAP S/4HANA.
• Limites documentados. A SAP documenta 100 MB por instância app-host e limites de taxa por subaccount para implantações e requisições em tempo de execução.
• Sem dados pessoais. Como o conteúdo pode ser compartilhado, a SAP desaconselha armazenar dados pessoais nele.
• Escopo de subaccount. A integração com o Work Zone espera os apps no mesmo subaccount da assinatura.

O HTML5 Application Repository responde onde os arquivos SAPUI5 ficam no SAP BTP, não como funciona o app por trás deles.

A SAP agora também oferece o Application Frontend service, que hospeda e entrega aplicações de front-end como um ponto de entrada único, com CLI própria, UI no cockpit e várias versões ativas. A SAP o posiciona para apps novos, standalone e single-tenant que não se conectam a outras aplicações, e observa que o uso produtivo exige uma licença do SAP Build.

A SAP afirma que equipes cujas necessidades são atendidas pelo HTML5 Application Repository e pelo application router podem continuar a usá-los. Apps implantados com o Application Frontend service também podem ser adicionados ao SAP Build Work Zone, edições standard e advanced, seja manualmente como URL apps, seja por meio de uma configuração de Common Data Model.