No horizonte, mudanças estão se manifestando. E essas mudanças tornarão o desenvolvimento de UI5 uma habilidade bastante obsoleta.

Para muitos desenvolvedores, o desenvolvimento freestyle UI5 é a abordagem preferida para criar um novo app UI5. É uma escolha popular entre os desenvolvedores UI5 por várias razões. Primeiro, o desenvolvimento freestyle UI5 é a maneira original de criar apps UI5. Outra razão é que a experiência geral do desenvolvedor para apps freestyle aumentou drasticamente na última década. As ferramentas disponíveis hoje ajudam enormemente. Muitas tarefas que tornavam o desenvolvimento de UI5 bastante complicado foram quase eliminadas. Isso torna o desenvolvimento freestyle UI5 bastante agradável. Um motivo importante é a qualidade do serviço OData fornecido pelo back-end. Ou a falta de qualidade. Podem faltar associações a entidades, filtros, classificação ou leitura de uma entidade diretamente, batch ou deep insert não são implementados. Em tais casos, o desenvolvedor UI5 era capaz de cobrir a falta de qualidade no back-end. No entanto, a falta de qualidade nos serviços OData está chegando ao fim. O ABAP RESTful Programming Model (RAP) está superando muitos problemas que o desenvolvimento baseado em SEGW permitiu acontecer. RAP e CAP garantem que o desenvolvedor siga um framework mais de perto. Para o desenvolvimento Fiori, ele alinha o app front-end e back-end mais próximos, fazendo dos Fiori Elements a primeira escolha para o app.

As mudanças nas ferramentas, frameworks e roadmaps terão um impacto no desenvolvimento de UI5.

Mudanças constantes

A tecnologia está em constante mudança e, assim, as habilidades necessárias também. O desenvolvimento de websites evoluiu de HTML e CSS básicos para apps dinâmicos. No início dos anos 2000, era comum desenvolver apps Java empresariais usando J2EE. Hoje, apps Java são implantados em alguma nuvem, incluindo alta disponibilidade, sem precisar ter um conhecimento profundo de infraestrutura. JSP já foi uma habilidade importante para apps web. Hoje, apps web são desenvolvidos usando Angular, React ou Vue. As tecnologias SAP podem estar sujeitas a um ritmo diferente aqui, mas obviamente não são imunes. A tecnologia básica NetWeaver ainda fará parte do S/4HANA em 2040, assim como outras tecnologias como serviços web SOAP ou até mesmo IDocs. Você poderia testemunhar nos últimos 20+ anos como as tecnologias foram promovidas, adotadas, usadas e, posteriormente, declaradas obsoletas. Tecnologias que focam no usuário têm uma frequência de mudança maior. Por exemplo, Web Dynpro Java, Visual Composer, Duet, SAP Portal, SUP, Kapsel, SMP, etc. Pense em todos os frameworks JavaScript disponíveis que prometem facilitar o desenvolvimento de apps.

Ter que aprender algo novo não é ruim e, pelo menos fora do universo SAP, é comum. Essa renovação constante é prova de que há inovação. Tecnologias antigas são assimiladas ou substituídas. Raramente ficam completamente obsoletas de uma vez. A mudança leva tempo e normalmente as ideias, ou pressupostos básicos, do que será substituído, continuam. Apps low code iniciais como Visual Composer não sobreviveram às mudanças na tecnologia web. A ideia básica de permitir que um usuário construa seu próprio app baseado em serviços, sim. Outros, como o SAP Portal, evoluíram ao longo do tempo para produtos modernos como Work Zone. A ideia de fornecer um ponto de entrada único com acesso transparente a apps para os usuários finais ainda é importante.

Demanda por apps Fiori

O que isso tem a ver com o desenvolvimento UI5? Existem muitos apps UI5 desenvolvidos para atender aos requisitos do usuário e oferecer uma UX moderna. Por que o desenvolvimento UI5 deve se tornar obsoleto? As empresas precisam entregar apps Fiori e também dependem do UI5 para fazer isso. Em todos os lugares você pode ver a demanda por apps e desenvolvedores UI5. As empresas estão migrando para o S/4HANA e uma maneira fácil de se preparar para isso é oferecer apps Fiori. A questão é: os desenvolvedores acreditam que habilidades em UI5 são necessárias para atender à demanda da empresa por apps Fiori. E aí está o erro: os usuários querem um app que os ajude a resolver uma tarefa. As empresas querem que esses apps funcionem com SAP. Portanto, esses apps devem ser Fiori. A demanda é por apps Fiori. Não apps UI5.

O UI5 é uma das muitas alternativas para entregar um app Fiori. Existem outras maneiras de entregar um app que siga as diretrizes de design Fiori. Da SAP você obtém MDK, Fiori para iOS/Android. Existe o SAP Build Code ou SAP Build Apps. Aqui o foco está no resultado, o app, não em como obter o app. Talvez em alguns anos, esboços, notas e requisitos sirvam para obter um app Fiori gerado por IA. Enquanto funcionar e puder ser aprimorado e mantido, as empresas não se importarão se a tecnologia subjacente é um app UI5 freestyle ou outra coisa. Ao contrário disso, atualmente, a maioria dos apps UI5 freestyle são entregues por desenvolvedores. Isso não mudará tão cedo, pois os desenvolvedores que aprenderam Fiori e desenvolvimento UI5 nos últimos anos fizeram isso principalmente escrevendo apps UI5 freestyle. Smart controls facilitaram o desenvolvimento de apps UI5. Não só tornam o desenvolvimento mais rápido, mas também alinhado automaticamente com as diretrizes Fiori. E: a falta de qualidade dos serviços OData é revelada. Enquanto smart controls são um acelerador para o desenvolvimento freestyle e ajudam a ter um serviço OData melhor, o desenvolvedor ainda deve cuidar de muitas coisas como navegação, layout de página, posicionamento de informações, fluxos de ações etc. Ferramentas ajudam, mas no final, ainda é tarefa do desenvolvedor garantir que o app funcione e siga as diretrizes Fiori. Este é um processo intensivo em trabalho e demorado.

O fato de que um app Fiori não é necessariamente um app UI5 é cada vez mais aceito. Afinal, UI5 freestyle é apenas uma alternativa para desenvolver um app Fiori. Olhando alguns anos no futuro, Fiori Elements será o padrão para o desenvolvimento de apps Fiori. Fiori Elements substituirá apps UI5 freestyle.

Fiori Elements

Existem dois componentes envolvidos que trabalham juntos e dependem um do outro: Fiori Elements no front-end (UI5) e o serviço OData no back-end (RAP). Ambos os frameworks evoluíram drasticamente nos últimos anos. É possível desenvolver apps Fiori complexos apenas usando anotações. Um app Fiori Elements impõe algumas regras tanto no front-end quanto no back-end que facilitam para as empresas se beneficiarem.

Back-end: o serviço deve ter alta qualidade. O modelo de dados deve estar completo. As anotações fornecidas devem ser boas o suficiente para entregar um app funcional. Isso significa que coisas como ajuda de valor, tabelas, páginas de objetos ou edição funcionam e mostram todas as informações necessárias para o usuário final.

Front-end: uma coisa boa sobre Fiori Elements é: no melhor caso, o app é realizado em tempo real usando as anotações do back-end. O app segue automaticamente as diretrizes Fiori. Atualizações tornam-se um não-evento. Quanto menos mudanças forem feitas pelo desenvolvedor front-end, melhor. Isso implica que: mudanças exigidas pelos negócios devem ser justificadas e mudanças desnecessárias podem ser recusadas referindo-se aos Fiori Elements.

OData

A qualidade do serviço OData aumentará. Serviços OData v4 serão comuns. Serviços oferecerão recursos avançados como draft handling. OData v4 é a melhor escolha para apps Fiori Elements. OData v4 atualmente não é tão usado quanto OData v2. Novamente, isso se deve ao passado. Quando o desenvolvimento UI5 começou, a única opção era OData v2. Em versões anteriores do S/4HANA, OData v2 era usado. O mesmo para RAP: OData v4 está disponível e recomendado recentemente (em termos SAP). Isso foi diferente para CAP, onde OData v4 era o padrão desde cedo. Mas então CAP carece de adoção e a maioria dos apps Fiori nos clientes são baseados em ABAP. OData v4 é o futuro para serviços. Realizar serviços OData v4 com RAP é fácil. A qualidade entregue por um serviço RAP é normalmente superior à de SEGW. Embora serviços OData v2 estejam disponíveis por anos, novas implementações devem usar OData v4. Isso traz algumas mudanças para os desenvolvedores de back-end e suas habilidades SEGW se tornarão obsoletas. O compromisso da SAP com RAP é uma realidade. Considerando o ciclo de vida dos produtos SAP – aqui: S/4HANA ou NW ABAP – e os ciclos de suporte, RAP ficará conosco até 2040. Olhando para a nuvem, nos últimos anos a SAP nos trouxe muitas opções diferentes para desenvolver algo com OData. A última iteração aqui sendo CAP. Meu conselho: escolha RAP como a maneira de desenvolver serviços (ou extensões), especialmente quando seus desenvolvedores são principalmente desenvolvedores ABAP e você tem um sistema S/4HANA disponível em algum lugar ou tem acesso ao BTP Steampunk.

Modelo de Dados

Relacionado ao serviço OData está o modelo de dados. A tarefa mais importante é definir o modelo de dados. Com ele, o resto vem quase automaticamente. O tempo em que serviços OData estavam apenas expondo um BAPI está chegando ao fim. Começando rigorosamente o serviço a partir do modelo de dados, visões CDS (entity), associações e construindo a partir daí o serviço. Isso fechará muitas lacunas na qualidade do serviço OData construído no modelo de dados. Um efeito colateral disso: os serviços OData serão mais fáceis de consumir em outros frameworks, como MDK ou low code.

RESTful Application Programming Model

RAP é o equivalente ABAP do CAP. De ambos os frameworks você deve esperar um serviço OData de alta qualidade. Ambos garantem que o desenvolvedor siga de perto o framework resultando em um serviço de alta qualidade. RAP, no entanto, vem com vários benefícios prontos para uso que o CAP não pode oferecer. O mais importante é: RAP roda em ABAP. O principal benefício é simplesmente: todo cliente SAP usando S/4HANA tem acesso ao RAP. Empresas e seus desenvolvedores obtêm RAP com S/4HANA e com BTP, ambiente ABAP. Como a probabilidade de um cliente S/4HANA ter desenvolvedores ABAP disponíveis é maior do que ter desenvolvedores CAP disponíveis, serve como uma indicação razoavelmente boa de que esses clientes adotarão RAP. Desenvolver apps Fiori Elements com RAP é super simples. Especialmente on-stack. Nenhuma configuração de conta, conectividade ou configuração de implantação necessária. Basta usar. Acessar dados via RAP e anotar o serviço é feito pela pessoa que definiu o modelo de dados e normalmente tem um conhecimento muito bom do processo de negócios.

Anotações

As anotações fazem parte de um projeto RAP ou CAP. Em vez de tê-las no projeto SEGW ou sobrescrevê-las na codificação, elas são mais visíveis no projeto. Também é “mais fácil” para o desenvolvedor escrevê-las. Importante aqui: os desenvolvedores que definiram o modelo de dados, a implementação, também estão escrevendo as anotações. Eles se tornam os proprietários. O cenário onde o desenvolvedor UI5 escreve elas no front-end será cada vez menos. Ou usado apenas para pequenos ajustes.

Essas mudanças resolverão um problema antigo: qualidade do serviço. As empresas se beneficiarão disso não apenas no desenvolvimento mais rápido de apps Fiori. Como mencionado acima, existem várias ferramentas fornecidas pela SAP para criar apps. Quando o serviço oferece os recursos necessários, fica fácil construir apps sobre eles. Seja um app móvel, low code, gerado por IA ou um app Fiori Elements.

Fiori Elements

Já foi mencionado várias vezes acima: o futuro do desenvolvimento UI5 é Fiori Elements. Muitas tarefas necessárias para um app UI5 freestyle não são necessárias. A maior parte do trabalho é feita pelo framework Fiori Elements e pelas anotações.

Fiori Elements já é possível com um serviço OData v2. Portanto, por vários anos. No entanto, o uso de Fiori Elements não era generalizado. Nem mesmo nos apps Fiori fornecidos pela SAP. Os problemas mencionados acima em relação à qualidade eram uma das razões. As ferramentas e recursos que o Fiori Elements com OData v2 oferecem eram bons, mas logo atingiram seus limites. Isso muda com o Fiori Elements e o OData v4. O modelo de programação flexível (FPM) permite desenvolver um app Fiori Elements e ainda ser capaz de ajustá-lo quando necessário. E com os FPM Macros, controles de UI complexos podem ser usados e controlados via anotações. O ponto de partida para um app Fiori com UI5 será o Fiori Elements. O foco do conhecimento mudará. De UI5 freestyle para Fiori Elements com FPM. Essa mudança é o que tornará o conhecimento de desenvolvimento UI5 em uma habilidade obsoleta. Seguir a abordagem mais rigorosa dos Fiori Elements significa: menos tempo necessário para um app, melhor alinhamento com as diretrizes Fiori, melhores serviços, mais recursos prontos para uso. Com Fiori Elements como base, o Flexible Programming Model será a base das extensões de apps personalizados. O conhecimento dos controles UI5 como responsive table, input field, panel, etc. será substituído pelo conhecimento de como usar os FPM Macros. O conhecimento de como a responsive table funciona ainda será usado, mas a primeira coisa a saber é como usar o Macro para table em um app FPM aprimorado Fiori Elements.

A adoção do OData v4 também tornará o desenvolvimento UI5 freestyle menos atraente. Usar OData v2 no UI5 é super fácil. Como os smart controls só funcionam com OData v2, desenvolver um app UI5 freestyle com OData v4 que usa os controles UI é trabalhoso. O OData v4 exige trabalho adicional do desenvolvedor, pois seu uso não é realmente destinado a apps freestyle.

Isso agora significa que o desenvolvimento UI5 é uma habilidade obsoleta? Claro que não se tornará completamente obsoleta. Os fundamentos ainda serão necessários. Ajustar apps Fiori Elements ainda precisa de habilidades de desenvolvimento UI5. Mas não confunda isso com o mesmo nível de habilidades e conhecimento de UI5 para um app UI5 freestyle. Escrever uma extensão de controlador ou fragmento de visualização não é o mesmo que criar um app do zero. Conhecimento profundo de como o rooting funciona, como aplicar um layout de página, trabalhar com FCL, etc. não será necessário.

Desenvolvimento UI5 de Próximo Nível

A mudança para habilidades de Fiori Elements liberará recursos no lado do desenvolvimento front-end do app. Hoje, muitas vezes criar um app UI5 do zero, mesmo com os assistentes e ferramentas, é uma tarefa demorada. E o freestyle sempre vem com o risco do “claro que podemos”. O freestyle é ótimo porque o app pode ser desenvolvido de uma maneira que faz tudo o que o consultor funcional deseja. É difícil para um desenvolvedor rejeitar um requisito quando é possível implementar. Afinal: tecnicamente é possível e há um requisito, então por que não fazer? E todos ficam felizes. Se o orçamento estiver disponível, por que não usá-lo para implementar esses desejos e depois em manter esses apps? Adicionar draft handling, collaborative editing, view management, fica complicado. Com Fiori Elements é mais fácil. Portanto, o foco do desenvolvimento UI5 mudará. Talvez para validar melhor se os apps seguem as diretrizes Fiori? Mais no usuário final e nos apps, independentemente se um UI5, Fiori Elements, MDK, Low Code, qualquer app? Mais no teste? Ou apenas em entregar mais apps? Uma coisa é certa: para o desenvolvedor UI5, as coisas mudarão. A demanda por UI5 freestyle não desaparecerá completamente. Sempre haverá demanda por alguns apps que exigem ser freestyle. No entanto, será apenas uma pequena porcentagem da demanda geral por Fiori.

Os desenvolvedores UI5 precisam aprender Fiori Elements. O foco é em Fiori Elements com OData v4 e FPM. A quantidade de apps Fiori Elements com OData v4 fornecidos pela SAP aumentará. Eles precisam saber como ajustar esses apps. Quais são as possibilidades e limitações. Aprender anotações e melhores práticas sobre onde colocá-las: melhor no back-end ou no front-end, e por quê? Validar apps UI5 freestyle “antigos” e verificar se eles estão realmente seguindo as diretrizes Fiori. Testar será importante. Usar ferramentas que permitem testar apps da perspectiva do usuário final. Assim como dados fictícios e como gerenciá-los. O serviço OData será consumido talvez não apenas por um app, mas por muitos. Esses apps dependerão de anotações e demandarão alta qualidade do serviço. Esta é uma mudança para o desenvolvedor de back-end, mas também para o desenvolvedor UI5, já que a tarefa de cobrir erros no back-end desaparecerá.

A habilidade de desenvolvimento Fiori Elements parece ser a mesma que UI5 freestyle. Mas não é. Fiori Elements vem com uma mentalidade diferente. Com uma abordagem diferente para todo o processo de criação de apps. É mais disruptivo do que você imagina.

Web Components

Uma área onde habilidades UI5 freestyle podem ser consideradas importantes é para controles de UI personalizados. Atualmente, você precisa saber como desenvolver um controle UI5, e isso inclui um bom entendimento de como o UI5 funciona. O futuro para controles UI5 são os Web Components. Com isso, as habilidades de desenvolvimento UI5 são substituídas por saber como desenvolver Web Components. E com isso, o foco do desenvolvedor muda. De um controle UI para UI5, para um controle UI para uma ampla gama de frameworks. Isso será mais do que interessante. Se a SAP fizer certo com os Web Components, isso tem uma grande chance de mudar como o Fiori é usado e adotado em uma empresa. E não apenas para a área SAP. Escreverei sobre isso em um post futuro no blog.

Deixe o mundo saber.