Os Tiers do SAP HANA: Entendendo o Modelo de Extensibilidade em Três Níveis

A extensibilidade é um aspecto fundamental para empresas que utilizam o SAP S/4HANA, permitindo que as soluções sejam adaptadas às necessidades específicas de cada negócio.

Para garantir a estabilidade e a manutenção da plataforma ao longo do tempo, a SAP definiu um modelo de extensibilidade em três tiers.

Esses tiers estabelecem diretrizes para customização de aplicações, garantindo que o desenvolvimento siga padrões compatíveis com a nuvem e com as atualizações da SAP.

Tier 1: Cloud Extensibility Model (ABAP Cloud)

O primeiro tier é baseado no modelo de desenvolvimento ABAP Cloud e prioriza os princípios "cloud-first". Ele impõe regras rigorosas para garantir que todas as customizações sejam compatíveis com a nuvem e facilmente atualizáveis.

Principais Características:

Sintaxe ABAP Cloud Enforced: Apenas tipos de objetos ABAP aprovados podem ser desenvolvidos, como artefatos do ABAP RESTful Application Programming Model (RAP).
Uso Restrito de APIs: Apenas APIs liberadas pela SAP podem ser utilizadas, com validação através de verificadores de sintaxe.
Ferramentas de Desenvolvimento: O desenvolvimento ABAP é realizado em ferramentas baseadas no Eclipse (ABAP Development Tools - ADT).
Extensões para Key Users e Desenvolvedores: Permite tanto extensões simples (como adição de campos customizados) quanto extensões mais avançadas para desenvolvedores.

Casos de Uso:

Adicionar campos personalizados a tabelas de banco de dados ou views CDS.
Implementar um Business Add-In (BAdI) liberado pela SAP.
Criar um aplicativo SAP Fiori customizado usando o ABAP RAP.

Nota: Para clientes do SAP S/4HANA Cloud Public Edition, o Tier 1 é a única opção disponível. Já para o SAP S/4HANA Cloud Private Edition, essa abordagem é altamente recomendada como primeira escolha.

Tier 2: Cloud API Enablement

O Tier 2 é exclusivo para o SAP S/4HANA Cloud Private Edition e foi projetado para cenários em que é necessário acessar APIs da SAP que ainda não foram oficialmente liberadas.

Para isso, utiliza-se um mecanismo de "custom wrappers" para garantir a compatibilidade com o modelo de nuvem.

Principais Características:

Wrappers Personalizados: APIs não liberadas podem ser utilizadas, desde que encapsuladas em classes customizadas.
Monitoramento de Conformidade: O ABAP Test Cockpit (ATC) é utilizado para garantir a conformidade com os padrões do ABAP Cloud, permitindo exceções quando necessário.
Governança de API: Após cada atualização da SAP, os desenvolvimentos devem ser reavaliados. Se a API envolvida for oficialmente liberada, o wrapper deve ser descontinuado.

Casos de Uso:

Criar uma classe wrapper para um BAPI não liberado.
Desenvolver uma view CDS que encapsule tabelas ou views não liberadas pela SAP.
Implementar lógica ABAP RESTful utilizando objetos SAP não publicados.

Tier 3: Classic ABAP Extensions

O Tier 3 é destinado a customizações ABAP clássicas que não podem ser implementadas nos Tiers 1 ou 2.

No entanto, essa abordagem apresenta riscos mais elevados de problemas durante atualizações do sistema e deve ser utilizada com cautela.

Principais Características:

Sem Restrições: Nenhuma restrição é imposta ao uso da linguagem ABAP ou dos tipos de objetos.
Maior Risco de Impacto: Como o código pode depender diretamente de componentes internos da SAP, atualizações futuras podem causar falhas.
Boas Práticas: Modificações devem ser evitadas sempre que possível, utilizando-se alternativas como "customer includes" e "CDS extends" para minimizar impactos.

Casos de Uso (Evitar Sempre Que Possível):

Implementação de um BAdI não liberado.
Extensão de aplicativos SAP Fiori baseados em modelos de programação antigos.
Modificação direta de objetos SAP (caso necessário, usar o Modification Assistant).

Conclusão: Escolhendo o Melhor Tier para seu Negócio

O modelo de extensibilidade em três tiers da SAP oferece um guia claro para empresas que desejam customizar o SAP S/4HANA de maneira segura e sustentável:

Tier 1 é a melhor escolha para garantir compatibilidade com a nuvem e segurança em atualizações.
Tier 2 deve ser utilizado apenas quando APIs não liberadas forem necessárias, sempre com governança e monitoramento adequado.
Tier 3 deve ser evitado sempre que possível devido ao alto risco de impacto nas atualizações.

Para garantir que os desenvolvimentos continuem alinhados às melhores práticas, as empresas devem periodicamente reavaliar suas customizações, refatorando ou eliminando soluções que não são mais necessárias.

Ao seguir essas diretrizes, é possível construir soluções customizadas que atendam às necessidades do negócio sem comprometer a estabilidade e escalabilidade do sistema.