Worklist

Um worklist é adequado quando o conjunto de itens já é definido pela tarefa e o trabalho do usuário é percorrê-lo: requisições de compra aguardando um comprador, documentos com um campo faltando, entregas a confirmar. Processar geralmente significa abrir um item, revisá-lo e então concluí-lo ou repassá-lo.

O critério de decisão é onde está o esforço de seleção:

• Se os usuários precisam combinar vários critérios antes que a lista faça sentido, use um list report.
• Se a lista é predefinida e os usuários agem principalmente sobre ela, use um worklist.
• Se os itens são tarefas de workflow encaminhadas ao usuário por um motor de workflow, o My Inbox já oferece a caixa de entrada, com decisões, encaminhamento e substituição.

Exemplo: a equipe de compras da Alder Manufacturing abre um worklist de requisições de compra, organizado em abas por status, e processa uma a uma as solicitações em aberto da Cedar Office Supply e da Bright Freight. Um worklist é a escolha certa quando o processamento, e não a busca, é o primeiro passo da tarefa.

Uma página de worklist tem quatro regiões, de cima para baixo:

1. Título do cabeçalho: o nome da fila de trabalho, sem o cabeçalho carregado de variantes de um list report.
2. Abas por status: visões opcionais, definidas pelos desenvolvedores, que dividem os itens em grupos como abertos, em processamento e concluídos. Cada aba pode mostrar o número de itens que contém.
3. Campo de busca: uma busca de texto livre na barra de ferramentas da tabela, que substitui a barra de filtros.
4. Tabela: os próprios itens, com ações na barra de ferramentas ou em cada linha e navegação para um object page com os detalhes.

No SAP Fiori elements para OData V2, o worklist usa uma responsive table por padrão, mostra a contagem de linhas no título da tabela e oculta o gerenciamento de variantes, a menos que o desenvolvedor o ative. O worklist V2 também não oferece exportação para planilha. Um worklist troca a barra de filtros por uma página mais enxuta, que coloca os itens e suas ações em primeiro lugar.

A configuração difere entre as duas variantes do SAP Fiori elements:

As abas de status são múltiplas visões. Os desenvolvedores as definem com as anotações UI.SelectionVariant ou UI.SelectionPresentationVariant e as listam no manifest.json. No V4, o multiple table mode renderiza uma icon tab bar, e a opção showCounts, desativada por padrão, adiciona a contagem de itens a cada aba. As colunas da tabela vêm de UI.LineItem, e cada aba pode apontar para seu próprio line item por meio de uma presentation variant. Configurar um worklist é, portanto, sobretudo configurar um list report com a barra de filtros removida.

Sim. A SAP documenta o worklist como um list report simplificado, então as opções do list report se aplicam:

• Seu próprio app: extension points adicionam colunas, ações e visões customizadas; no OData V4, building blocks e custom pages do flexible programming model cobrem lacunas maiores. Visões customizadas também podem ser adicionadas como abas extras por meio de uma controller extension.
• Um app entregue pela SAP: adaptation projects criados com o SAP Fiori tools, ou a adaptação por key user, alteram o app sem modificar o código da SAP.

No SAP S/4HANA Cloud Public Edition, verifique quais desses caminhos a SAP suporta para o app em questão.

Um limite prático: quando os usuários pedem vários campos de filtro, o requisito se tornou um list report, e reativar a barra de filtros é mais honesto do que construir filtros customizados em torno de um worklist. Estender um worklist funciona bem para ações e colunas, e menos bem para busca.

1. Usar um worklist para busca aberta. Sem barra de filtros, os usuários rolam e buscam em vez de selecionar; um list report é mais adequado.
2. Apontá-lo para um entity set enorme. Uma barra de filtros oculta significa que o conteúdo é carregado na abertura, então as selection variants das abas já precisam restringir os dados.
3. Abas sobrepostas. Se um item pode aparecer em duas abas de status, as contagens deixam de bater e os usuários perdem a confiança na fila.
4. Esperar contagens em tempo real. No OData V4, atualizar a contagem de uma aba por meio de um side effect global só funciona para uma visão que o usuário já abriu, então planeje como as contagens são atualizadas após as ações.
5. Recriar o My Inbox. Modelar aprovações de workflow como um worklist customizado duplica o encaminhamento, a substituição e o tratamento de tarefas que o My Inbox já oferece.

Quando as contagens parecerem erradas, verifique nesta ordem: a selection variant por trás de cada aba, as sobreposições entre abas e se a aba foi atualizada após a última ação. A maioria dos problemas de worklist são problemas de design da seleção, não defeitos do framework.