Catálogos (technical e business)

O conteúdo do SAP Fiori Launchpad é organizado em dois níveis:

1. Technical catalogs são o repositório. Contêm os tiles e target mappings originais de uma área de aplicação, empacotados como itens de app descriptor do launchpad (um target mapping mais um ou mais tiles). A SAP os nomeia SAP_TC_<AREA>_….
2. Business catalogs contêm referências a esses originais, selecionadas conforme o que um usuário de negócio específico precisa, como um comprador da Alder Manufacturing. A SAP os nomeia SAP_<AREA>_BC_….
3. Roles recebem business catalogs. Technical catalogs não se destinam a ser atribuídos a usuários.

As referências existem apenas no nível de tiles e target mappings individuais; um business catalog nunca referencia um technical catalog inteiro. Por isso, uma alteração em um original de um technical catalog se propaga para todos os business catalogs que o referenciam. A SAP trata seus business catalogs como templates cujo conteúdo pode mudar de release para release. Um catálogo é, portanto, a menor unidade em que os apps são concedidos, enquanto as definições em si existem uma única vez, nos technical catalogs.

• On-premise e Private Edition: um administrador de roles adiciona o business catalog ao menu da role PFCG (SAP Fiori Launchpad → Launchpad Catalog). Com suas aplicações incluídas, a PFCG também propõe os valores padrão de autorização dos apps referenciados, incluindo as autorizações de início de serviços OData.
• Public Edition: a SAP entrega business catalogs como pacotes de apps e, onde há suporte, apps IAM (variantes de autorização de apps). Os administradores os adicionam a business roles no Maintain Business Roles, mantêm restrições e ativam ou desativam apps IAM individuais. Onde um catálogo não suporta apps IAM, o próprio catálogo continua sendo a menor unidade de autorização. O app Business Catalogs (F2471) documenta cada catálogo.

Em ambos os casos, todo app de um catálogo atribuído pode ser encontrado pela pesquisa e pelo app finder, esteja ou não colocado em uma page. Na Public Edition, catálogos desnecessários também ampliam o acesso, e por isso a SAP desaconselha usar templates de business role sem alterações em produção. Um business catalog é, portanto, primeiro uma decisão de acesso e só depois uma decisão de conteúdo.

A documentação de boas práticas da SAP para on-premise e Private Edition dá critérios de decisão claros:

Technical catalogs customizados pertencem ao escopo de configuração multimandante; o launchpad app manager sempre trabalha ali. Business catalogs customizados pertencem ao escopo de customizing específico do mandante (/UI2/FLPCM_CUST); alterações na /UI2/FLPCM_CONF valem para todos os mandantes e viajam em requests de workbench. Catálogos cujo ID começa com SAP são somente leitura nos sistemas do cliente. Copiar um business catalog mantém os originais da SAP conectados, ao passo que copiar um tile ou target mapping corta essa conexão.

1. Separar tile e target mapping. A SAP recomenda manter o tile e o target mapping de um item de app descriptor do launchpad no mesmo business catalog; caso contrário, a navegação falha para usuários que têm apenas um deles.
2. Montar catálogos app por app. Copiar um business catalog SAP traz os target mappings necessários para a navegação entre apps; selecionar apps isolados de technical catalogs muitas vezes os deixa de fora.
3. Catálogos grandes demais. As operações de catálogo ficam mais lentas à medida que os catálogos crescem, e todo app de um catálogo se torna alcançável para todo usuário que o tem.
4. Presumir que as cópias se mantêm atualizadas. Um business catalog copiado mantém as referências com que foi copiado; apps ausentes são adicionados manualmente. Após um upgrade, o launchpad content manager sinaliza conteúdo obsoleto ou descontinuado e seus sucessores.
5. Esquecer os apps SAP GUI for HTML. Alguns deles existem apenas em technical catalogs, então precisam ser adicionados individualmente a um business catalog.

A maioria dos erros com catálogos são decisões de granularidade: catálogos grossos demais concedem acesso em excesso, e catálogos montados de forma fina demais quebram a navegação.

No on-premise e na Private Edition, comece pelo usuário e avance em direção ao conteúdo:

1. Quais catálogos o usuário recebe de fato? A /UI2/FLPCA_USER mostra os catálogos e spaces por usuário, e a /UI2/FLPCA faz o mesmo por role.
2. O intent é resolvido? A /UI2/FLIA mostra se um target mapping dos catálogos do usuário corresponde a um determinado intent.
3. As referências estão íntegras? O launchpad content manager sinaliza referências que não podem ser resolvidas, catálogos cujo estado difere entre os escopos de configuração e de customizing e configurações defeituosas de tiles ou target mappings.
4. O conteúdo é consistente? A /UI2/FLC verifica o conteúdo do launchpad entregue e customizado (descontinuada a partir do ABAP platform 2025 em favor da visão de problemas do passo 3 e da /UI2/FLPCA). A /UI2/FLC1 encontra catálogos órfãos no escopo de customizing.
5. Onde um tile é usado? A verificação de onde-usado do launchpad content manager lista as pages e os business catalogs que contêm um tile. Um tile que ainda está colocado em uma page não pode ser removido do catálogo.

Na Public Edition, o app IAM Information System mostra quais business roles e business catalogs concedem acesso a quais apps. Um problema de catálogo costuma se manifestar como um problema de role, por isso o diagnóstico deve sempre começar pelos catálogos efetivos do usuário.