Web Dynpro ABAP

O Web Dynpro ABAP mantém a lógica da aplicação e o estado da interface do usuário no servidor ABAP:

1. Os desenvolvedores constroem components com views, controllers e um context, que guarda os dados exibidos por uma view, no Web Dynpro Explorer do ABAP Workbench (SE80). O sistema gera a partir deles classes ABAP Objects.
2. Cada aplicação é publicada como um serviço ICF, normalmente sob o caminho /sap/bc/webdynpro seguido do namespace e do nome da aplicação.
3. Quando o usuário abre a URL, o servidor executa o component e envia HTML renderizado ao navegador; toda ação relevante do usuário volta ao servidor.
4. O Web Dynpro Configuration Editor e a personalização permitem que administradores e usuários adaptem layouts sem modificar código SAP.

O Floorplan Manager (FPM) se apoia no Web Dynpro ABAP e oferece padrões de página, de forma semelhante ao que os floorplans fazem no SAP Fiori elements. O Web Dynpro ABAP é, portanto, um framework conduzido pelo servidor, no qual o navegador exibe o que o servidor ABAP decide.

Uma aplicação Web Dynpro ABAP chega aos usuários do launchpad como qualquer outro destino:

1. Um tile ou link dispara um intent, isto é, um semantic object mais uma ação.
2. Um target mapping do tipo Web Dynpro resolve o intent para o nome da aplicação e um system alias.
3. O launchpad inicia a aplicação em um iFrame.

O modo de integração é uma propriedade do intent, mantida no launchpad app manager (/UI2/FLPAM):

O modo Compatible não pode mais ser selecionado para conteúdo novo, mas os target mappings salvos com ele continuam a usá-lo. Dentro da aplicação, a interface IF_WD_FLP_API permite que o Web Dynpro ABAP use navegação baseada em intent para apps SAPUI5 e de volta. No nível da navegação, o Web Dynpro ABAP é um cidadão pleno do launchpad, mesmo que suas telas sejam renderizadas de outra forma.

O Web Dynpro ABAP fica na camada de aplicações de UI, ao lado dos apps SAPUI5 e das transações SAP GUI for HTML. Três fatos explicam por que os profissionais o encontram em projetos SAP Fiori:

• A Reference Library o lista. A SAP Fiori Apps Reference Library usa o tipo de aplicação "Web Dynpro" para essas aplicações, com a configuração necessária para iniciá-las.
• A SAP ainda o entrega. Parte do conteúdo analítico atual é construída com Web Dynpro ABAP; relatórios multidimensionais como o Journal Entry Analyzer são aplicações Web Dynpro.
• Ele pode se parecer com o SAP Fiori. Os temas visuais da SAP para aplicações clássicas, SAP Belize e SAP Quartz Light, aplicam-se ao Web Dynpro ABAP e também ao SAP GUI, de modo que os usuários veem uma única linguagem visual em todo o launchpad.

Um tema semelhante não torna a tela responsiva nem muda seu modelo de interação. O Web Dynpro ABAP é um destino de inicialização dentro do SAP Fiori, não um app SAP Fiori no sentido do design.

O Web Dynpro ABAP tem pontos fortes reais que explicam sua longevidade:

• Ferramentas maduras no ABAP Workbench, com integração direta ao sistema de transporte.
• Adaptação sem modificação por meio de camadas de configuração, customizing e personalização.
• Qualidades embutidas, como suporte a acessibilidade, internacionalização e tratamento de segurança.
• As diretrizes de programação ABAP da SAP ainda indicam o Web Dynpro ABAP e o SAPUI5 como as tecnologias padrão para novas UIs web no ABAP clássico.

Os limites são igualmente claros. Os novos apps do SAP S/4HANA seguem o SAP Fiori elements e o ABAP RESTful application programming model, e o Web Dynpro ABAP não faz parte do ABAP Cloud, que suporta o SAP Fiori como tecnologia de UI. As telas são projetadas para desktops e exigem uma ida e volta ao servidor na maioria das interações.

Um critério prático de decisão: manter e integrar as aplicações Web Dynpro ABAP existentes que funcionam, adaptá-las por configuração e escolher SAP Fiori elements ou SAPUI5 para novos desenvolvimentos. O Web Dynpro ABAP continua sendo um runtime sólido para o que já existe, não o padrão para o que vem a seguir.

Trabalhe do launchpad em direção à aplicação:

1. Resolução do intent. Execute a /UI2/FLIA para o usuário. Se nenhum target mapping corresponder, a causa é de catálogo ou de atribuição de role.
2. Nó ICF. Uma página HTTP 403 ou 404 normalmente significa que o serviço da aplicação sob /sap/bc/webdynpro está inativo na SICF do sistema para o qual o alias aponta.
3. System alias. Um target mapping que aponta para o back-end errado abre outro sistema ou nada.
4. Modo de integração. Conteúdo antigo salvo no modo compatible inicia o SAP Business Client dentro do launchpad; a navegação e o comportamento do botão voltar passam a diferir do modo direct.
5. Autorização. A aplicação inicia, mas mostra um erro de autorização; verifique a role de back-end, incluindo o S_START para a aplicação quando essa verificação de início estiver ativada, e analise com a SU53.
6. Timeouts de sessão. O timeout do servidor Web Dynpro ABAP pode ser diferente da configuração do launchpad, então verifique os dois.

A maioria das falhas de inicialização do Web Dynpro ABAP são lacunas de configuração em torno da aplicação, não defeitos da própria aplicação.

• On-premise e Private Edition: os clientes executam aplicações Web Dynpro ABAP entregues pela SAP e próprias, ativam seus serviços ICF e criam target mappings do tipo Web Dynpro para aplicações customizadas.
• SAP S/4HANA Cloud Public Edition: as aplicações Web Dynpro ABAP entregues pela SAP, como os relatórios multidimensionais, chegam aos usuários por meio de business catalogs; o desenvolvimento do cliente ali usa ABAP Cloud, então os clientes não podem construir novas.
• SAP ERP: muitos processos do SAP Business Suite usam telas Web Dynpro ABAP e Floorplan Manager, frequentemente iniciadas a partir do SAP Business Client ou do SAP Enterprise Portal antes do launchpad.

O Web Dynpro ABAP roda em todas as edições do SAP S/4HANA baseadas em ABAP; o que varia é se os clientes podem construir as suas próprias aplicações.