App freestyle SAPUI5

Um app freestyle SAPUI5 usa a estrutura padrão de aplicação SAPUI5, com todas as telas escritas pela equipe de desenvolvimento:

1. Component e app descriptor — o component inicia o app; o manifest.json declara fontes de dados, models, rotas e inbounds de navegação.
2. Views — normalmente XML views que posicionam controles SAPUI5, como tabelas, formulários e gráficos.
3. Controllers — código JavaScript ou TypeScript para eventos, feedback de validação, diálogos e navegação.
4. Models — models OData para dados do back-end, models JSON para estado local, resource models para textos.
5. Integração com o launchpad — um target mapping ou inbound torna o app acessível a partir de um tile ou link.

O SAP Fiori tools ainda gera o esqueleto do projeto, mas a SAP agora marca seus templates freestyle SAPUI5 como descontinuados e recomenda começar pela custom page do SAP Fiori elements para OData V4, que ainda deixa o conteúdo da página a cargo da equipe. Nada na UI é derivado de anotações, a menos que a equipe adicione building blocks deliberadamente. Um app freestyle SAPUI5 se define, portanto, por quem escreve a UI — a equipe — e não por qual framework o executa.

A orientação da SAP para desenvolvedores recomenda usar o SAP Fiori elements o máximo possível e código freestyle o quanto for necessário. O desenvolvimento freestyle é o ponto de partida certo quando pelo menos uma destas condições se aplica:

• a interação não corresponde a nenhum floorplan, por exemplo uma tela guiada de leitura de códigos ou um quadro de planejamento;
• o app precisa trabalhar com fontes de dados que não são serviços OData anotados, ou com sistemas externos;
• a equipe precisa de controle detalhado sobre renderização e desempenho;
• o design se afasta deliberadamente dos padrões standard para um grupo específico de usuários.

Exemplo: a Alder Manufacturing quer que a equipe do armazém confirme entregas da Bright Freight lendo os paletes em um tablet, com botões grandes e um fluxo de etapa única. Nenhum floorplan atende a essa interação, então uma página freestyle se justifica. Já uma lista de entregas em aberto para supervisores se encaixa em um list report. A decisão de construir um app freestyle SAPUI5 deve ser tomada por tela, não por projeto.

• Controle total do design: qualquer layout, interação ou visualização que os controles SAPUI5 consigam expressar é possível.
• Qualquer fonte de dados: o app pode combinar serviços OData, APIs REST e dados locais sem precisar de anotações.
• Mesma linguagem visual: como usa controles e temas SAPUI5, um app freestyle bem projetado se parece com o restante do SAP Fiori.
• Combinável: páginas freestyle e páginas do SAP Fiori elements podem conviver no mesmo app, e os building blocks do SAP Fiori elements para OData V4 podem ser combinados em layouts customizados.
• Extensível por terceiros: o SAPUI5 flexibility suporta a adaptação de apps freestyle, assim como de apps SAP Fiori elements, desde que o app defina o flag flexEnabled e use IDs de controle estáveis.

O app freestyle SAPUI5 é a opção que remove o teto do que a interface do usuário pode fazer.

• A responsabilidade fica com o cliente. A orientação da SAP atribui a manutenção e a responsabilidade pelo código dos apps freestyle principalmente ao cliente ou parceiro, em comparação com o SAP Fiori elements, em que o framework assume uma parte maior.
• Consistência é uma tarefa de design. A conformidade com o SAP Fiori é automática nos floorplans, mas precisa ser construída e revisada nas telas freestyle.
• A evolução do framework é manual. Novos recursos de floorplan chegam aos apps SAP Fiori elements pelo framework; os apps freestyle só mudam quando alguém os altera, inclusive quando o SAPUI5 descontinua APIs.
• As competências são específicas. A equipe precisa de conhecimento em desenvolvimento web e no framework SAPUI5, não apenas em OData e anotações.
• A lógica pode migrar para o navegador. Regras codificadas em um controller não protegem dados gravados por outros canais.

Esses limites são o preço da flexibilidade: um app freestyle SAPUI5 custa mais para se manter saudável ao longo de sua vida útil.

A SAP descreve três pontos de partida, e um único app pode combinar os três:

A opção do meio pertence ao flexible programming model, que permite aos desenvolvedores misturar building blocks orientados a metadados com código próprio. Para equipes que optam por freestyle por hábito, ela costuma ser o melhor meio-termo. Escolher entre freestyle e SAP Fiori elements raramente é tudo ou nada; o flexible programming model transforma isso em uma decisão página a página.

1. Escolher freestyle por hábito. Verifique os floorplans primeiro; construa freestyle apenas onde eles não se encaixam.
2. Nenhum responsável nomeado após o go-live. Uma reclamação frequente nas comunidades de profissionais são apps customizados que ninguém mantém depois que a equipe do projeto sai. Defina o responsável antes da implantação.
3. Desenvolver em uma versão do SAPUI5 mais nova que a de produção. Teste contra a versão do front-end server de destino.
4. Regras de negócio apenas no controller. Mantenha as validações também no serviço de back-end.
5. IDs de controle instáveis. O SAPUI5 flexibility identifica os controles por IDs estáveis, de modo que IDs gerados comprometem a adaptação por key users e tornam frágeis os testes automatizados.

A maioria dos problemas de apps freestyle SAPUI5 aparece meses após o go-live, e por isso a responsabilidade importa tanto quanto a qualidade do código.