Apps customizados (Z-apps)

O nome vem da regra de nomenclatura ABAP: sem um namespace de prefixo registrado, os objetos de repositório criados em sistemas do cliente precisam começar com Y ou Z. "Z-app" virou abreviação para qualquer aplicação que o cliente constrói e da qual é dono, seja qual for a tecnologia:

• apps freestyle SAPUI5 para tarefas que nenhum app standard cobre;
• apps SAP Fiori elements sobre views CDS e serviços customizados;
• cópias de apps entregues pela SAP, renomeadas no namespace Z e alteradas;
• transações, relatórios ou aplicações Web Dynpro ABAP customizados iniciados a partir do launchpad;
• apps side-by-side no SAP BTP que estendem processos do SAP S/4HANA.

Algumas organizações registram seu próprio namespace de prefixo em vez de usar Z ou Y, o que evita conflitos de nomes entre projetos. O traço que define um Z-app é a responsabilidade, não a letra: um Z-app é qualquer aplicação cujo ciclo de vida é responsabilidade do cliente, e não da SAP.

Um app customizado típico on-stack passa por todas as camadas abaixo do launchpad:

1. Dados e lógica: views CDS e, para apps transacionais, um business object construído com o ABAP RESTful application programming model; apps mais antigos usam ABAP clássico.
2. Serviço: um serviço OData, publicado por meio de um service binding RAP ou, em apps mais antigos, construído no Gateway Service Builder (SEGW) e ativado na /IWFND/MAINT_SERVICE.
3. UI: um app SAP Fiori elements ou freestyle SAPUI5, implantado no repositório ABAP do SAPUI5, onde cada app é armazenado como uma aplicação BSP com nome Z ou Y.
4. Conteúdo do launchpad: um tile e um target mapping em um technical catalog criado com o launchpad app manager (/UI2/FLPAM), referenciados em um business catalog e atribuídos por meio de uma role na PFCG.
5. Transporte: todos os objetos percorrem juntos o landscape de transporte.

Cada uma das cinco etapas cria um objeto que o cliente precisa manter consistente depois. Um app SAP Fiori customizado é, portanto, um pequeno produto com várias partes móveis, não um único arquivo.

• Encaixe exato: um app customizado pode modelar uma etapa do processo do jeito que o negócio realmente funciona, incluindo etapas que a SAP não entrega.
• Diferenciação: os processos que distinguem uma empresa são justamente os que têm menos chance de ser cobertos por apps standard.
• Mesma experiência do usuário: construído com SAP Fiori elements ou SAPUI5, um app customizado tem a aparência e o comportamento dos apps SAP e usa o mesmo launchpad, as mesmas roles e a mesma navegação.
• Opções modernas e amigáveis a upgrades: apps construídos com ABAP Cloud sobre APIs liberadas, ou side-by-side no SAP BTP, podem permanecer estáveis ao longo dos upgrades.

Exemplo: a Alder Manufacturing constrói um pequeno app para seus compradores confirmarem janelas de entrega da Bright Freight, uma etapa que nenhum app standard oferece, e o vincula a partir do pedido de compra. Onde o standard termina e o processo não, um app customizado costuma ser a forma mais direta de fechar a lacuna.

• A responsabilidade nunca termina. Cada upgrade do SAPUI5, release do back-end e revisão de segurança afeta o app. Alguém precisa testá-lo, corrigi-lo e saber por que ele existe.
• As dependências determinam o custo. Apps que usam objetos SAP não liberados caem nos níveis mais baixos de clean core e podem quebrar em upgrades; apps sobre APIs liberadas trazem muito menos risco.
• O conhecimento sai com as pessoas. Muitos apps customizados foram construídos por um único desenvolvedor ou parceiro; quando eles saem, a finalidade e a lógica do app muitas vezes ficam difíceis de reconstruir.
• As cópias se distanciam. Um app SAP copiado não recebe as correções e melhorias da SAP, e a diferença aumenta a cada release.
• Lacunas de inventário. Muitas vezes as organizações não sabem dizer quantos apps customizados executam nem quem os usa, uma reclamação frequente nas comunidades de profissionais.

Esses limites não são falhas técnicas; são o preço de ser dono de um software que a SAP não mantém.

Desça a escada de extensão e pare no primeiro degrau que atender:

1. Standard: procure na SAP Fiori Apps Reference Library um app ou sucessor que cubra a necessidade.
2. Extensibilidade key user: um campo, uma verificação ou um valor padrão ausente pertence a este degrau, não a um novo app.
3. Variante de app em vez de cópia: para alterar um app entregue pela SAP, um SAPUI5 adaptation project cria uma variante que continua recebendo as atualizações da SAP; a SAP suporta isso na Public Edition desde a release 2402.
4. Extensibilidade para desenvolvedores on-stack: um novo app sobre APIs liberadas com ABAP Cloud.
5. Side-by-side no SAP BTP: quando o app abrange vários sistemas, precisa de dados próprios ou tem um ciclo de vida diferente.

Um erro comum é copiar um app standard para alterar dois campos; a solução é um adaptation project ou a extensibilidade key user. Um app customizado se justifica quando falta a própria etapa do processo, não quando falta um campo.

• On-premise e Private Edition: tanto o ABAP clássico quanto o ABAP Cloud estão disponíveis, então os apps customizados vão do clean core total a modificações profundas. Quem define os limites é a governança, não o sistema.
• SAP S/4HANA Cloud Public Edition: a extensibilidade para desenvolvedores permite aos clientes construir apps SAP Fiori customizados em um subconjunto do ABAP otimizado para a nuvem, somente sobre APIs liberadas; o desenvolvimento Z clássico com acesso irrestrito não é possível.
• SAP BTP: os apps side-by-side vivem em seu próprio subaccount e ciclo de vida e chegam ao SAP S/4HANA apenas por meio de APIs.

A questão da responsabilidade é a mesma em todas as opções; o que difere é o quanto a plataforma restringe aquilo de que um app customizado pode depender.