SAP Fiori Elements

O SAP Fiori elements transfere decisões de UI do código para os metadados:

1. Um serviço OData expõe as entidades de negócio, por exemplo pedidos de compra e seus itens.
2. As anotações descrevem como a UI deve apresentá-las: UI.SelectionFields para campos de filtro, UI.LineItem para colunas de tabela, UI.HeaderInfo para títulos de objetos, UI.Facets para seções do object page.
3. O app descriptor (manifest.json) seleciona um template de floorplan para cada página e define opções como o carregamento inicial ou a edição em massa.
4. Em tempo de execução, o framework lê metadados, anotações e descriptor e constrói as páginas, incluindo barra de filtros, variantes, tabelas, formulários, mensagens e navegação.
5. Quando a página gerada não atende, os desenvolvedores adicionam extensões em vez de reescrever a página.

O trabalho principal do desenvolvedor está, portanto, no serviço e em suas anotações, não em JavaScript. O SAP Fiori elements transforma um serviço bem anotado em um app funcional, e um serviço mal anotado em um app ruim.

O OData V4 acrescenta building blocks e custom pages, para que os desenvolvedores possam combinar elementos padrão com seu próprio código SAPUI5 dentro do mesmo app. O list report combinado com o object page é a combinação clássica, frequentemente abreviada como LROP. Escolher um floorplan no SAP Fiori elements significa escolher um padrão de interação, não um template visual.

A SAP recomenda o SAP Fiori elements para OData V4 em novas aplicações e afirma que a variante OData V2 continua com suporte completo. Na prática, a escolha depende de três fatores:

• Back-end: service bindings RAP podem publicar um serviço de UI como OData V2 ou V4, e o CAP disponibiliza OData V4 por padrão. Serviços construídos na SEGW são tipicamente OData V2.
• Necessidades de extensão: building blocks e o flexible programming model estão disponíveis apenas com OData V4.
• Apps existentes: um app que funciona em V2 não precisa de migração para continuar rodando; as configurações diferem entre as duas variantes, por exemplo initialLoad no V4 versus loadDataOnAppLaunch no V2.

Para um novo app customizado sobre um back-end SAP S/4HANA ou SAP BTP atual, o OData V4 é a escolha padrão no SAP Fiori elements, e o V2 é a escolha pragmática quando o serviço já existe.

O SAP Fiori elements é adequado quando a tarefa segue um padrão: buscar em uma lista, abrir um objeto, editá-lo, executar ações. O framework entrega barras de filtro, gerenciamento de variantes, tabelas, drafts, mensagens, acessibilidade e suporte a tradução sem código customizado, e a SAP mantém esses recursos atualizados ao longo das releases do SAPUI5.

O SAPUI5 freestyle é adequado quando a própria interação é incomum: um quadro de planejamento, um fluxo guiado com leitor de código, um layout altamente visual ou dados de fontes que não são OData. O código freestyle dá controle total e responsabilidade total pela manutenção.

As próprias orientações da SAP tratam os dois como combináveis, e não excludentes: comece pelo SAP Fiori elements, use building blocks e escreva código freestyle apenas para as lacunas. Um teste de decisão útil é verificar se os stakeholders aceitam o layout do floorplan pelo menos nas telas principais. O SAP Fiori elements é a melhor escolha sempre que o requisito é um business object, e não uma interação sob medida.

As opções de extensão dependem de quem é o dono do app:

• Seu próprio app: extension points permitem que os desenvolvedores adicionem colunas, ações, seções, header facets e filtros customizados; com OData V4, o flexible programming model acrescenta building blocks e custom pages.
• Um app entregue pela SAP: adaptation projects, criados com o SAP Fiori tools, alteram ou estendem o app sem modificar o código da SAP; a adaptação por key user permite que key users reorganizem ou ocultem campos em tempo de execução.
• O lado dos dados: um novo campo geralmente começa no serviço e em suas anotações, não na UI.

A disponibilidade varia conforme a edição: no SAP S/4HANA Cloud Public Edition, verifique quais desses caminhos a SAP suporta para o app em questão. Toda extensão de um app SAP Fiori elements se torna código ou configuração que alguém precisa manter ao longo dos upgrades.

1. Brigar com o floorplan. Grandes volumes de código customizado para forçar um layout fora do padrão anulam o ganho de manutenção; nesse ponto, o SAPUI5 freestyle costuma ser mais honesto.
2. Tratá-lo como no-code. Anotações são código em outra forma; precisam de revisão, versionamento e testes.
3. Ignorar o tratamento de draft. Cenários de edição sem um serviço habilitado para draft perdem os comportamentos de retomada, bloqueio e validação que os usuários esperam.
4. Não examinar os valores padrão. Carregamento inicial, edição em massa e tipos de tabela têm valores padrão que podem carregar dados demais ou de menos; defina-os deliberadamente.
5. Anotar em dois lugares. As anotações podem ficar no CDS do back-end e em arquivos de anotação locais; os arquivos locais sobrepõem os metadados do serviço, e o último arquivo listado no manifest.json prevalece, então duplicidades tornam o comportamento difícil de rastrear.

A maioria dos problemas com o SAP Fiori elements são problemas de design de serviço e de anotações que só se tornam visíveis na UI.