SAP Fiori vs HTML GUI: Por que nem todo bloco é um aplicativo Fiori nativo

Isso acontece em quase todos os projetos S/4HANA. Um usuário acessa o SAP Fiori Launchpad, vê uma grade limpa de blocos, clica em um deles — e chega a uma tela que parece suspeitamente com a transação SAP GUI que ele usa há quinze anos, apenas sendo executada em uma aba do navegador. A pergunta natural vem em seguida: "Espere, isso é Fiori?"

A resposta honesta é: não necessariamente. O SAP Fiori Launchpad é um ponto de entrada, não uma garantia de tecnologia. Por trás desses blocos uniformes, podem existir aplicações muito diferentes: apps SAP Fiori nativos criados com SAPUI5 ou Fiori Elements, desenvolvimentos SAPUI5 freestyle, aplicações Web Dynpro ABAP, páginas analíticas — ou transações clássicas do SAP GUI renderizadas no navegador via SAP GUI for HTML (também chamado de Web GUI ou HTML GUI).

Essa distinção não é acadêmica. Ela afeta o que os usuários podem esperar realisticamente em termos de experiência, acesso móvel, desempenho e treinamento. Também afeta como as equipes de projeto medem o progresso da modernização. Este artigo explica a diferença, quando os blocos HTML GUI fazem sentido, onde eles geram confusão e como identificar o que um bloco realmente abre antes de criar um plano de implantação em torno dele.

O que é um aplicativo SAP Fiori nativo?

Um aplicativo SAP Fiori nativo é uma aplicação projetada e criada de acordo com o sistema de design SAP Fiori — o conjunto de princípios da SAP para experiências de usuário coerentes, baseadas em funções e orientadas a tarefas.

Em termos práticos, um aplicativo Fiori nativo normalmente tem estas características:

• Criado com tecnologias SAP Fiori. A maioria dos aplicativos nativos usa SAPUI5, seja como aplicativos Fiori Elements (gerados a partir de serviços OData anotados usando floorplans padrão, como List Report ou Object Page) ou como aplicativos SAPUI5 freestyle desenvolvidos para padrões de interação mais específicos.
• Baseado em funções e orientado a tarefas. Em vez de uma transação gigante cobrindo dezenas de cenários, um aplicativo Fiori é delimitado para uma função de usuário específica e uma tarefa específica — aprovar um pedido de compra, verificar o status de um fornecedor, lançar um documento simples.
• Conectado a serviços de backend modernos. Aplicativos nativos geralmente consomem serviços OData, o que possibilita recursos como tratamento de rascunhos, pesquisa e navegação estruturada entre objetos relacionados.
• Projetado para uma experiência moderna. Isso significa navegação consistente, ações contextuais e — dependendo do aplicativo — comportamento responsivo que se adapta a diferentes tamanhos de tela.

Um modelo mental útil: um aplicativo Fiori nativo foi projetado como um aplicativo Fiori desde o início. Ele não foi convertido, encapsulado ou renderizado em um.

O que é SAP GUI para HTML (Web GUI / HTML GUI)?

O SAP GUI para HTML é uma tecnologia que renderiza transações clássicas do SAP GUI em um navegador web. Em vez de instalar o SAP GUI para Windows em uma estação de trabalho, a geração do SAP Internet Transaction Server (ITS) dentro da pilha ABAP traduz as telas Dynpro clássicas para HTML, e o usuário interage com a transação por meio do navegador.

Os pontos importantes:

• A aplicação subjacente ainda é a transação clássica. Quando um bloco inicia a ME23N ou a VA03 por meio do SAP GUI para HTML, a lógica de negócio, a sequência de telas e a estrutura dos campos são as da transação Dynpro original.
• O navegador é apenas a camada de apresentação. As telas são convertidas para HTML dinamicamente, por isso mantêm a aparência clássica — barras de menu, teclas de função, navegação baseada em telas — com alguma tematização visual aplicada para suavizar a aparência.
• Essas transações podem ser iniciadas a partir do Fiori Launchpad por meio de blocos e mapeamentos de destino, exatamente como aplicativos nativos. É isso que as torna fáceis de confundir.
• O benefício prático é real: os usuários obtêm acesso a transações sem uma instalação local do SAP GUI, e os administradores obtêm acesso centralizado, baseado em navegador, a funcionalidades que ainda não têm equivalente no Fiori.

A renderização em um navegador não muda a natureza da aplicação. Um bloco HTML GUI é o SAP GUI clássico entregue por um canal diferente — não uma experiência redesenhada.

Por que os blocos podem ser enganosos

O Fiori Launchpad apresenta deliberadamente uma superfície unificada. Todos os blocos parecem semelhantes: um título, talvez um número de KPI, um estilo visual consistente. Essa consistência é boa para a navegação, mas oculta a diversidade técnica por baixo.

Um único Launchpad pode conter blocos que abrem, entre outros:

• Um aplicativo SAP Fiori nativo (por exemplo, um Relatório de Lista do Fiori Elements para gerenciar pedidos de venda)
• Um aplicativo SAPUI5 freestyle criado para um cenário personalizado
• Uma transação clássica do SAP GUI renderizada por meio do Web GUI
• Uma aplicação Web Dynpro ABAP, comum em muitos cenários de RH e finanças
• Uma aplicação web personalizada ou de terceiros incorporada via URL
• Uma página ou relatório analítico, como um detalhamento de KPI do Smart Business

Para o usuário, todos esses são "blocos no Fiori". Para a equipe do projeto, eles representam tecnologias diferentes, com diferentes capacidades, limitações e ciclos de vida. Tratá-los como intercambiáveis é onde começam os problemas de expectativa — um usuário que teve uma ótima experiência com um aplicativo de aprovação do Fiori Elements clicará no próximo bloco esperando o mesmo e poderá, em vez disso, encontrar uma transação clássica densa com navegação por teclas de função.

SAP Fiori vs HTML GUI: comparação prática

A comparação não é "bom vs ruim." É "experiência redesenhada vs acesso preservado." Ambos têm seu lugar — mas devem ser rotulados com honestidade.

Por que as organizações usam blocos de HTML GUI

Há razões sólidas e defensáveis para que blocos de HTML GUI apareçam em Launchpads reais:

• Lacunas de cobertura. Nem toda transação do SAP GUI tem um equivalente nativo no Fiori. Mesmo nas versões atuais do S/4HANA, algumas áreas funcionais ainda são atendidas principalmente por transações clássicas.
• Profundidade funcional. Alguns aplicativos Fiori cobrem deliberadamente os 80% mais comuns de um cenário. Usuários avançados que precisam dos 20% restantes — visões especiais de estoque, tipos de documentos pouco conhecidos, funções de alteração em massa — ainda podem precisar da transação completa.
• Migração gradual. A adoção do S/4HANA raramente é uma grande virada de uma só vez para a experiência do usuário. As empresas frequentemente migram funções para o Fiori de forma incremental, e o HTML GUI mantém tudo acessível a partir de um único lugar nesse meio-tempo.
• Um único ponto de entrada. Colocar transações clássicas por trás de blocos do Launchpad oferece aos usuários uma única URL, uma única estrutura de catálogo e um único conceito de autorização — em vez de manter o acesso ao SAP GUI em paralelo para um subconjunto de usuários.
• Escopo de projeto controlado. Reconstruir uma transação raramente usada como um aplicativo SAPUI5 personalizado custa esforço real de desenvolvimento e manutenção. Se a transação funciona e é usada por cinco especialistas por mês, encapsulá-la costuma ser a escolha racional.

Usados de forma consciente, os blocos de HTML GUI são uma decisão arquitetônica legítima, não um atalho do qual se envergonhar.

Os riscos de chamar tudo de "Fiori"

Os problemas não surgem da HTML GUI em si, mas de rotulá-la incorretamente. Quando tudo no Launchpad é comunicado como "nossa nova experiência Fiori", vários riscos se acumulam:

• Expectativas dos usuários quebradas. Usuários a quem foi prometida uma experiência moderna clicam em um bloco e recebem uma transação clássica. A decepção se associa a todo o programa, incluindo os aplicativos nativos realmente bons.
• Planos móveis irreais. A liderança pode presumir que "agora tudo está no Fiori, então tudo funciona em tablets". Telas da HTML GUI em um telefone são, na melhor das hipóteses, utilizáveis em emergências.
• Material de treinamento confuso. Se o treinamento tratar todos os blocos da mesma forma, ele explicará em excesso aplicativos Fiori simples ou explicará de menos transações clássicas complexas. Os instrutores precisam saber qual é qual.
• Métricas de modernização infladas. "Temos 300 blocos em produção" soa como progresso. Se 220 deles são wrappers da Web GUI, a modernização real da UX é muito menor do que o número sugere — e as decisões de roadmap baseadas nesse número estarão erradas.
• Redesenho de processo ignorado. Encapsular uma transação preserva o processo antigo exatamente como era. As equipes podem perder a oportunidade — e às vezes a necessidade — de repensar o processo que um redesenho de aplicativo nativo teria forçado.
• Chamados de suporte encaminhados incorretamente. Um problema de renderização no ITS, um problema de desempenho em um serviço OData e um erro de tela Dynpro têm causas raiz diferentes e responsáveis diferentes. Se a equipe de suporte não consegue distinguir os tipos de aplicativo, a triagem fica mais lenta.

Por que a HTML GUI nem sempre é ruim

Vale a pena apresentar explicitamente uma visão equilibrada, porque a HTML GUI muitas vezes é descartada injustamente nas discussões sobre modernização:

• Para usuários avançados, a transação completa frequentemente é melhor do que um aplicativo simplificado. Um especialista experiente em MM trabalhando o dia todo no ME21N perde produtividade em uma interface reduzida em escopo.
• Ela preserva funcionalidades comprovadas sem risco de redesenvolvimento. A transação se comporta exatamente como foi validada ao longo de anos de uso.
• Ela reduz a interrupção durante a transição. Os usuários mantêm fluxos de trabalho familiares enquanto a organização desenvolve a capacidade Fiori onde ela é mais importante.
• Ela lida com a longa cauda de transações — as centenas de funções raramente usadas, mas ocasionalmente essenciais, que nunca justificariam uma reconstrução.
• Ela oferece suporte à centralização de acesso: um Launchpad, um fluxo de autenticação, nenhuma instalação local de GUI para gerenciar para usuários ocasionais.

A única coisa que ela não faz é oferecer uma experiência de usuário Fiori nativa — e isso não é um problema, desde que ninguém afirme o contrário.

Como identificar que tipo de aplicativo um bloco abre

Para qualquer pessoa que esteja avaliando um Launchpad existente ou planejando uma implantação, estas verificações revelam o que realmente há por trás de um bloco:

1. Verifique a Biblioteca de Referência de Aplicativos SAP Fiori. Pesquise o aplicativo por nome ou ID. A biblioteca lista explicitamente o tipo de aplicação — SAP Fiori (SAPUI5), Web Dynpro ou SAP GUI. Ela também mostra os componentes de backend necessários e as versões disponíveis.
2. Observe o tipo de aplicação nos detalhes técnicos. Na configuração de conteúdo do Launchpad (mapeamentos de destino, ou conteúdo do launchpad em ferramentas mais recentes), cada destino especifica se inicia um componente SAPUI5, uma aplicação Web Dynpro ou uma transação via SAP GUI for HTML.
3. Revise o mapeamento de destino e o objeto/ação semântica. A intenção por trás do bloco aponta para a configuração concreta de inicialização, que identifica a tecnologia.
4. Inspecione a URL em tempo de execução. Aplicativos SAPUI5 normalmente carregam um componente dentro do shell do Launchpad; sessões Web GUI mostram padrões característicos de URL do ITS (como caminhos que contêm /sap/bc/gui/sap/its/webgui).
5. Aplique o teste de design. A tela segue padrões Fiori — páginas de objeto, relatórios de lista, barras de ação no rodapé? Ou mostra barras de menu clássicas, campos de código OK e dicas de teclas de função?
6. Teste em desktop e dispositivos móveis. Um aplicativo nativo e responsivo se adapta. Uma tela Web GUI em um telefone torna a diferença óbvia em poucos segundos.
7. Valide em relação à função e ao processo. Independentemente da tecnologia, confirme se o aplicativo realmente oferece suporte às tarefas executadas pela função-alvo — um aplicativo Fiori nativo que cobre apenas parte do processo ainda pode precisar de uma transação clássica ao lado.

O que as equipes SAP devem documentar

A maior parte da confusão no Launchpad pode ser evitada com um catálogo interno simples de aplicativos. Para cada bloco no escopo, registre:

• Nome do bloco e atribuição de catálogo/espaço
• Função de negócio que o utiliza
• Processo suportado (vinculado à sua documentação de processo)
• Tipo de aplicativo — Fiori Elements, SAPUI5 freestyle, Web Dynpro, SAP GUI para HTML, URL externa
• Classificação: Fiori nativo ou wrapper de HTML GUI
• Transação SAP GUI relacionada (para transações encapsuladas ou parcialmente substituídas)
• Responsável — funcional e técnico
• Suporte móvel — testado, não presumido
• Limitações conhecidas em comparação com a transação clássica ou o escopo esperado
• Notas de treinamento — o que os usuários precisam aprender, o que muda em relação ao anterior
• Roteiro de substituição, se o bloco for um wrapper transitório programado para ter um sucessor nativo

Esse catálogo se torna a referência compartilhada para equipes de treinamento, suporte, testes e planejamento de roteiro — e torna o progresso da modernização mensurável em vez de anedótico.

Implicações para implantações do SAP Fiori

Saber quais blocos são nativos e quais são wrappers muda a forma como você conduz a própria implantação:

• Adoção pelos usuários: Comunique com honestidade. Posicione os aplicativos nativos como a nova experiência e os blocos de HTML GUI como um acesso conveniente pelo navegador a transações familiares. Os usuários perdoam uma tela clássica; eles não perdoam que lhes digam que ela é algo que não é.
• Treinamento: Separe os materiais por tipo de aplicativo. Aplicativos nativos precisam de integração a novos padrões de interação; blocos de Web GUI precisam, no máximo, de uma observação de que a transação familiar agora abre no navegador.
• Desenho de funções: Catálogos e espaços devem refletir o que uma função realmente precisa — o que muitas vezes significa uma combinação deliberada de aplicativos nativos para tarefas frequentes e transações encapsuladas para trabalho especializado.
• Documentação de processos: Quando um aplicativo nativo substituiu uma transação, as etapas documentadas do processo geralmente mudam. Quando um wrapper é usado, geralmente não mudam. Documente de acordo.
• Testes: Aplicativos nativos exigem testes de serviço OData e de interface do usuário; blocos de Web GUI exigem testes de transação, além de verificações de renderização no navegador. Planos de teste diferentes, defeitos diferentes.
• Expectativas de desempenho: Defina-as por tipo de aplicativo. As idas e voltas tela a tela no Web GUI se comportam de forma diferente dos aplicativos Fiori baseados em OData, especialmente por VPN ou conexões de alta latência.
• Gestão de mudanças: Organize a comunicação em torno das experiências genuinamente novas. Um anúncio de lançamento baseado em transações encapsuladas promete demais e compromete a credibilidade para ondas posteriores.
• Roteiro de modernização: Use o catálogo de aplicativos para acompanhar a conversão real — quantas tarefas de alta frequência migraram para aplicativos nativos — em vez de contar blocos.

Resposta final

Um bloco no SAP Fiori Launchpad é apenas um ponto de acesso. Ele não garante que a aplicação por trás dele seja um aplicativo SAP Fiori nativo. Aplicativos Fiori nativos, aplicativos Fiori Elements, aplicativos SAPUI5 freestyle, aplicações Web Dynpro e transações clássicas do SAP GUI renderizadas por meio do SAP GUI for HTML podem estar todos por trás de blocos visualmente idênticos.

Isso não é uma falha do Launchpad — é assim que uma plataforma favorável à transição deve funcionar. O problema começa apenas quando as equipes deixam de distinguir entre as duas coisas. Antes de tomar decisões sobre adoção, treinamento, uso móvel, desempenho ou progresso da modernização, identifique o que cada bloco realmente abre. A tecnologia por trás do bloco — não o bloco em si — determina o que os usuários irão vivenciar.

FAQ

Todo bloco do SAP Fiori Launchpad é um aplicativo Fiori nativo?

Não. O Fiori Launchpad pode iniciar aplicativos nativos SAPUI5/Fiori Elements, aplicações Web Dynpro, transações clássicas do SAP GUI via SAP GUI for HTML e até aplicações web externas. O bloco é apenas o ponto de entrada; a tecnologia por trás dele varia.

Qual é a diferença entre SAP Fiori e SAP GUI for HTML?

Os aplicativos SAP Fiori são aplicações projetadas e desenvolvidas de acordo com os princípios de design do SAP Fiori, normalmente com SAPUI5 ou Fiori Elements e serviços OData. O SAP GUI for HTML renderiza transações clássicas existentes do SAP GUI em um navegador sem alterar seu design, lógica ou padrões de interação.

HTML GUI é o mesmo que Web GUI?

Sim. "HTML GUI", "Web GUI" e "SAP GUI for HTML" se referem todos à mesma tecnologia: renderização baseada em navegador de transações clássicas do SAP GUI por meio do Internet Transaction Server (ITS) integrado à pilha ABAP.

As transações do SAP GUI podem ser iniciadas a partir do Fiori Launchpad?

Sim. Por meio de mapeamentos de destino, transações clássicas podem ser iniciadas como blocos e abertas no navegador via SAP GUI for HTML. Essa é uma configuração comum e suportada, especialmente durante transições para o S/4HANA.

Por que alguns blocos do Fiori parecem telas antigas do SAP GUI?

Porque são telas antigas do SAP GUI — transações clássicas Dynpro renderizadas como HTML. O bloco inicia a transação original por meio do Web GUI, portanto o layout da tela, os menus e a navegação permanecem os do SAP GUI clássico, com apenas uma leve tematização visual.

O SAP GUI for HTML é ruim?

Não. É uma forma prática de preservar o acesso a transações que não têm equivalente nativo no Fiori, dar suporte a usuários avançados que precisam de toda a profundidade da transação e evitar redesenvolvimento desnecessário. Ele se torna um problema apenas quando é apresentado como uma experiência Fiori moderna, criando falsas expectativas.

Como posso saber se um bloco é um aplicativo Fiori nativo?

Verifique o aplicativo na SAP Fiori Apps Reference Library, inspecione o mapeamento de destino ou a configuração de conteúdo do launchpad para o tipo de aplicação, observe a URL em tempo de execução (sessões Web GUI usam caminhos ITS característicos) e aplique o teste de design: aplicativos nativos seguem padrões Fiori, enquanto o Web GUI mostra menus clássicos e campos de código OK.

As empresas devem substituir todos os blocos HTML GUI por aplicativos Fiori nativos?

Não necessariamente. Tarefas de alta frequência usadas por muitos usuários ocasionais ou móveis se beneficiam mais de aplicativos nativos. Transações especializadas raramente usadas podem não justificar redesenvolvimento e podem permanecer como blocos Web GUI. A abordagem correta é um roteiro priorizado com base no uso, nas funções dos usuários e no valor de negócio.

Um bloco do Launchpad significa que o processo foi modernizado?

Não. Um bloco que encapsula uma transação clássica preserva o processo existente exatamente como era. A modernização genuína geralmente envolve redesenhar a experiência do aplicativo — e frequentemente o processo por trás dela —, não apenas mudar a forma como a transação é acessada.

Como as equipes SAP devem documentar os blocos do Launchpad?

Mantenha um catálogo interno de aplicativos listando o nome de cada bloco, função de negócio, processo suportado, tipo de aplicação (Fiori Elements, SAPUI5, Web Dynpro, SAP GUI for HTML), transação clássica relacionada, proprietário, suporte móvel, limitações conhecidas, notas de treinamento e roteiro de substituição quando aplicável.