Navegação baseada em intent

No SAP Fiori Launchpad, a parte da URL depois de # é um intent, não um endereço de aplicativo. Um intent típico tem esta forma: #PurchaseOrder-display?PurchaseOrder=4500000123.

1. O usuário clica em um tile ou link, ou um app dispara a navegação em código. Cada um deles nomeia apenas o semantic object, a ação e parâmetros opcionais.
2. O launchpad verifica quais intents o usuário pode usar. No launchpad ABAP, eles vêm dos catálogos das roles PFCG do usuário.
3. A resolução de destino do launchpad compara o intent com os target mappings disponíveis, incluindo tipo de dispositivo e regras de parâmetros.
4. O target mapping vencedor fornece o aplicativo: um componente SAPUI5, uma transação SAP GUI for HTML, um aplicativo Web Dynpro ABAP ou uma URL, além do sistema em que ele é executado.
5. O launchpad inicia o destino e repassa os parâmetros.

O lado chamador nunca sabe qual app respondeu. A navegação baseada em intent é um contrato de vinculação tardia entre o que o usuário quer fazer e o app que o faz.

A indireção resolve problemas reais de ciclo de vida:

• Destinos específicos por role. O mesmo intent pode abrir uma visão de gestor para uma role e uma visão de operador para outra, apenas por configuração.
• Destinos específicos por dispositivo. Um usuário de desktop e um usuário de smartphone podem chegar a apps diferentes pelo mesmo link.
• Apps substituíveis. Um intent pode apontar hoje para um aplicativo Web Dynpro ABAP e mais tarde para um novo app SAPUI5, sem alterar os apps que apontam para ele.
• Implantação independente. Os apps têm ciclos de vida diferentes; um app de origem não pode presumir que um app de destino esteja instalado. Os intents deixam o launchpad decidir o que existe para este usuário, neste sistema.
• Extensão sem modificação. Os clientes podem redirecionar um intent standard para um app customizado sem tocar no código SAP.

Essas propriedades explicam por que os apps SAP Fiori se vinculam uns aos outros por intents, e não por endereços fixos no código. A navegação baseada em intent troca um pouco de esforço de configuração por apps que podem evoluir de forma independente.

• SAP Fiori elements: campos anotados com um semantic object se tornam smart links, e a navegação de saída é declarada por anotações e pelo app descriptor. O framework chama o launchpad em nome do desenvolvedor.
• App descriptor: sap.app → crossNavigation declara inbounds (os intents que um app aceita, com regras de parâmetros, como o tratamento de parâmetros adicionais: permitidos, ignorados ou não permitidos) e outbounds (os intents que um app pode disparar).
• SAPUI5 freestyle: o serviço de shell sap.ushell.services.Navigation oferece métodos assíncronos para navegar, montar um link, verificar se um intent é suportado para o usuário e listar os links de um semantic object. O serviço mais antigo CrossApplicationNavigation está descontinuado desde o SAPUI5 1.120.

Os desenvolvedores devem verificar se um intent é suportado antes de renderizar um link, porque o suporte varia por usuário. A navegação baseada em intent em código é uma solicitação ao launchpad, nunca uma chamada direta a outro app.

• Ela precisa de um runtime de launchpad ou de site. Os intents são resolvidos pelo shell. A SAP descreve o serviço Navigation como atuando no escopo do launchpad atual, de modo que um app aberto isoladamente, fora do launchpad ou de um site do SAP Build Work Zone, não tem serviço para resolvê-los.
• Os erros aparecem em tempo de execução. Um target mapping ausente ou uma role errada se manifestam quando o usuário clica, não quando o conteúdo é transportado; por isso, testar por role é importante.
• Os parâmetros viajam na URL. Seleções grandes precisam de um app state em vez de parâmetros de URL, e valores sensíveis não devem ser colocados em um intent.
• Destinos entre sistemas dependem de configuração. Um destino em outro sistema depende de um system alias ou destination correto.
• Navegação não é estado de processo. Um intent abre um app com contexto; ele não registra o que o usuário faz em seguida, se uma tarefa está concluída ou o que vem depois.

Esses limites decorrem do desenho: a navegação baseada em intent resolve para onde ir e deixa o que acontece lá para o app de destino.

No launchpad ABAP, siga as evidências em vez de editar o conteúdo primeiro:

1. Leia o intent na barra de endereços do navegador ou na mensagem do console.
2. Se o console mostrar um ID de log de aplicação, abra o log de aplicação UI2 na SLG1; a partir da mensagem, é possível saltar para a análise de intents.
3. Execute a /UI2/FLIA com o intent, o tipo de dispositivo e o usuário afetado. Ela mostra quais roles e catálogos carregam o intent e qual target mapping pertence a ele.
4. Se o target mapping estiver correto, mas o app carregar no sistema errado, verifique os system aliases com a /UI2/FSAC.
5. Se um componente SAPUI5 não puder ser carregado, verifique o log do índice de aplicações SAPUI5 com a /UI5/APP_INDEX_CALCULATE.

No SAP BTP, compare o intent do tile com os inbounds do app descriptor implantado. Um intent que falhou costuma ser um problema de conteúdo ou de role, e as ferramentas da navegação baseada em intent mostram qual deles antes que algo seja alterado.

A sintaxe e a ideia são as mesmas; muda apenas a origem dos target mappings. Os apps implantados no SAP BTP declaram seus inbounds no app descriptor, e o SAP Build Work Zone trata esses inbounds como os destinos do site. Os apps do SAP S/4HANA chegam a um site do Work Zone pela Federation of Remote Content Providers, que expõe o conteúdo do launchpad do back-end ao site. Em todas as opções de implantação, a navegação baseada em intent mantém o mesmo contrato: um intent entra, e o conteúdo do usuário decide qual app sai.