Overview Page (OVP)

Um overview page é adequado para monitoramento e tomada de decisão em uma área de trabalho, como compras ou vendas, quando as informações vêm de várias entidades e o usuário precisa de uma leitura rápida antes de agir em outro lugar.

Critérios de decisão:

• Um conjunto de dados que os usuários analisam em profundidade e sobre o qual depois agem: um analytical list page.
• Vários conjuntos de dados que um perfil percorre em busca de exceções e depois aprofunda: um overview page.
• Uma página inicial pessoal com todo o trabalho de um usuário: My Home, a página de entrada do launchpad no SAP S/4HANA.
• Uma busca em muitos objetos: um list report.

Exemplo: o responsável por compras da Alder Manufacturing abre um overview page com quatro cards: requisições de compra pendentes de aprovação, valor dos pedidos por fornecedor, entregas atrasadas da Bright Freight e links rápidos para os apps de compras. Cada card abre o app onde o trabalho acontece. O Procurement Overview Page (F1990) da SAP segue esse padrão. Um overview page é a escolha certa quando um perfil precisa primeiro de amplitude e de profundidade a um clique de distância.

Um overview page tem uma estrutura simples:

1. Cabeçalho: o título da área de negócio que a página cobre, com um menu do usuário que inclui o gerenciamento de quais cards são exibidos.
2. Barra de filtros (opcional): filtros no nível da aplicação, como um código de empresa ou um intervalo de datas, que se aplicam a todos os cards cuja entidade compartilha a propriedade filtrada.
3. Cards em uma grade: colunas responsivas, até cinco conforme a largura da tela, que os usuários podem reorganizar arrastando e soltando.

Cada card tem duas áreas. O cabeçalho do card traz um título obrigatório, um subtítulo opcional e um contador que mostra quantos registros o card exibe em relação ao total do filtro atual; ele também pode trazer um valor de KPI com tendência, o que exige um serviço que faça agregação. A área de conteúdo mostra uma lista, uma tabela, links ou um gráfico. Clicar em um card ou em um de seus itens navega, geralmente por navegação baseada em intent, até o app que trata o detalhe. O card, não a página, é a unidade de trabalho de um overview page.

Cada card é vinculado a um único entity set. UI.SelectionVariant e UI.PresentationVariant restringem e ordenam o que um card mostra, UI.Identification contém as ações do card e UI.KPI configura os cabeçalhos de KPI. Os desenvolvedores também podem criar cards customizados. Os cards de overview page são componentes desse floorplan definidos por anotações; os UI integration cards são uma tecnologia de card declarativa e separada, projetada para reutilização em diferentes hosts. Escolher bem os tipos de card é a maior parte do trabalho de design em um overview page.

Todas as configurações ficam na seção sap.ovp do manifest.json, em dois níveis:

• Nível de página: o modelo e o entity set do filtro global, o layout do contêiner (um layout redimensionável permite que os usuários redimensionem os cards), o carregamento de dados na abertura e a atualização automática, cujo intervalo mínimo e padrão é de um minuto.
• Nível de card: para cada card, o template, o entity set, os caminhos de anotação para line items, gráficos, seleção, apresentação e KPI, além das configurações de navegação.

O overview page aceita serviços OData V2 e V4, inclusive na mesma página. A SAP observa que seus princípios de UI vêm do OData V2, que ele ainda usa smart controls e que apenas o building block FilterBar é usado; por isso, a documentação completa fica na seção V2 do SDK. Os usuários podem reorganizar, ocultar, exibir, redimensionar e filtrar cards, e os cards movidos mantêm sua posição. O flexible column layout não se aplica a overview pages. No SAP S/4HANA Cloud Public Edition, overview pages customizados dependem das opções de extensibilidade disponíveis nesse ambiente, então consulte a documentação de extensibilidade da sua release. Configurar um overview page é sobretudo uma questão de selecionar cards, não de construir telas.

1. Cards que não levam a lugar nenhum. Um card sem navegação mostra um problema, mas não o caminho para resolvê-lo.
2. Cards demais. Vinte cards transformam uma visão geral em uma rolagem; mantenha os que um perfil verifica diariamente.
3. Ignorar a autorização. Sem a configuração de card requireAppAuthorization, os usuários podem ver um card e depois encontrar um erro de acesso ao navegar. Com ela, o card só aparece se o usuário puder abrir o intent de destino.
4. Cabeçalhos de KPI em serviços sem agregação. Valores de KPI exigem agregação no back-end.
5. Duplicar apps existentes. Um card que reproduz um list report completo incentiva os usuários a trabalhar dentro do card em vez de no app.

Quando um card não aparece ou está vazio, verifique nesta ordem: se o usuário o ocultou em Manage Cards, o intent de requireAppAuthorization e as roles do usuário, a selection variant do card, os valores do filtro global e, por fim, a autorização no entity set do card. A maioria dos problemas de overview page vem da seleção dos cards e da autorização, não do framework.