Object Page

Um object page é adequado sempre que a tarefa gira em torno de um único business object: alterar uma ordem de venda e seus itens, criar um pedido de compra como draft, liberar uma fatura bloqueada ou comparar um draft com a versão salva. O floorplan atende desde poucos campos até objetos complexos com muitas seções e tabelas relacionadas.

Dois critérios de decisão ajudam:

• Se os usuários precisam de contexto primeiro, como o status do objeto, os indicadores-chave e os itens relacionados, o object page padrão é adequado.
• Se os usuários apenas inserem dados e não precisam de cabeçalho nem de navegação por seções, o form entry object page, uma variação que oculta ambos, é mais enxuto.

Exemplo: um comprador da Alder Manufacturing abre um pedido de compra da Bright Freight, confere os fatos do cabeçalho e depois edita dois itens. Um object page é adequado quando a pergunta é "e quanto a este objeto específico?"

Um object page é formado por cinco áreas, de cima para baixo:

1. Título do cabeçalho: o título e o subtítulo do objeto, uma imagem opcional, o status de edição quando existe um draft e uma barra de ferramentas com ações como Edit, Delete, Related Apps e Share.
2. Header facets: fatos-chave como pares rótulo-valor ou pequenos elementos visuais, como um micro chart ou uma avaliação. A SAP recomenda no máximo cinco pares rótulo-valor.
3. Barra de navegação: âncoras que levam a cada seção em uma única página com rolagem, ou abas que mostram uma seção por vez.
4. Área de conteúdo: seções e subseções com formulários, tabelas de itens relacionados, gráficos ou componentes reutilizáveis.
5. Barra de ferramentas do rodapé: no modo de edição, Save ou Create, as ações determinantes e o botão de mensagens.

Selecionar uma linha em uma tabela de itens abre um subobject page para a entidade filha, com botões de paginação para navegar entre os itens. Cada área de um object page responde a uma pergunta: o que é isto, o que importa, onde está, como concluo.

No ABAP CDS, todos esses facets são escritos como entradas @UI.facet com um tipo, como uma referência a field group ou uma coleção, e um propósito que separa os header facets das seções padrão. Somente dois níveis de collection facets são renderizados. A escolha entre âncoras e abas é uma configuração do manifest.json, sectionLayout, com Page como padrão no OData V4. A estrutura do object page é, portanto, definida quase inteiramente em UI.Facets.

Com um serviço habilitado para draft, o object page cria um draft assim que o usuário começa a editar ou criar. O draft é salvo em segundo plano enquanto o usuário trabalha, o que gera quatro comportamentos:

• o trabalho não salvo sobrevive a uma interrupção ou a uma falha, e o usuário pode retomá-lo depois;
• o draft funciona como bloqueio, de modo que outros usuários veem que o objeto está sendo editado;
• validações e controle de campos são executados durante a edição, não apenas no final;
• Save transforma o draft na versão ativa.

O SAP Fiori elements para OData V4 distingue drafts exclusivos, pertencentes a um único usuário, de drafts colaborativos, que vários usuários podem editar juntos; a SAP documenta drafts colaborativos apenas para serviços baseados em RAP. RAP e CAP oferecem tratamento de draft no lado do serviço. Sem draft, nada chega ao back-end até que o usuário salve, e a SAP recomenda apps sem draft apenas para fluxos simples. O suporte a draft é a decisão de serviço que mais influencia a experiência de edição em um object page.

Sim. As opções dependem de quem é o dono do app:

• Seu próprio app: extension points adicionam seções e subseções customizadas, header facets, elementos de formulário, ações e colunas de tabela; componentes reutilizáveis podem ser colocados em seções; com OData V4, building blocks e custom pages do flexible programming model cobrem lacunas maiores.
• Um app entregue pela SAP: adaptation projects (SAP Fiori tools) ou adaptação por key user, sem modificar o código da SAP.

No SAP S/4HANA Cloud Public Edition, os caminhos disponíveis seguem os modelos de extensibilidade da SAP nesse ambiente; consulte a documentação de extensibilidade da sua release.

Seções customizadas têm um custo de desempenho. O OData V4 oferece request groups e lazy loading para object pages; no OData V2, o lazy loading precisa ser ativado para cada seção customizada. Um teste prático: se a maioria das seções é customizada, uma custom page ou SAPUI5 freestyle pode ser mais honesto do que um object page fortemente estendido.

1. Seções demais em uma única página com rolagem. Agrupe seções ou mude para abas, o que a SAP recomenda para grid tables.
2. Cabeçalhos sobrecarregados. Mais do que alguns poucos fatos no cabeçalho transformam o cabeçalho em um segundo formulário.
3. Aninhamento profundo de facets. Collection facets abaixo do segundo nível são ignorados, e um collection facet que envolve um único reference facet pode ser renderizado de forma incorreta; use o reference facet diretamente.
4. Vírgulas nos títulos das seções. O SAP Fiori elements usa vírgulas como delimitadores ao agrupar mensagens, então evite-as nos títulos de seções e subseções.
5. Edição sem draft. Os usuários perdem a possibilidade de retomar o trabalho e a informação de bloqueio.

Quando uma seção não aparece, verifique nesta ordem: a anotação UI.Facets nos metadados do serviço, o nível do facet, o qualificador do target, qualquer condição UI.Hidden e um arquivo de anotação local que possa substituir o UI.Facets do back-end. A maioria dos defeitos de object page são problemas de estrutura de facets, não bugs de renderização.