Nos últimos anos, o conceito de Clean Core tornou-se central nas discussões sobre modernização no SAP S/4HANA. A meta é clara: manter o núcleo do ERP limpo, resiliente e preparado para inovações futuras, evitando o acúmulo de technical debt que compromete upgrades e agilidade.
Recentemente, a SAP deu um passo importante ao evoluir o antigo modelo 3-tier de extensibilidade para um novo framework baseado em níveis (A a D). Essa mudança traz mais transparência e realismo para classificar as customizações, principalmente em cenários que envolvem código ABAP clássico.
O que mudou?
Antes, a regra era binária: ou sua extensão era “clean” (seguindo apenas APIs liberadas e SAP BTP/ABAP Cloud), ou era considerada “unclean”.
Agora, o novo modelo classifica as extensões em quatro níveis, permitindo um diagnóstico mais granular:
- Level A (Ideal – “Clean Core”): Extensões feitas usando apenas APIs e objetos liberados oficialmente.
Exemplo: uma aplicação de aprovação de pedidos criado no SAP BTP consumindo APIs oficiais de compras. - Level B (Clássico, mas estável): Uso de APIs clássicas e frameworks consolidados (ex.: BAPIs, user-exits documentados).
Exemplo: uma integração que ainda utiliza BAPI_PO_CREATE1, considerada estável, mas não tão moderna quanto APIs REST publicadas. - Level C (Condicionalmente limpo): Extensões que acessam objetos internos do SAP. Não são recomendadas, mas com suporte a um novo recurso: o changelog de objetos internos, que ajuda a prever impactos em upgrades.
Exemplo: um relatório customizado que lê diretamente tabelas do módulo de MM. - Level D (Não recomendado): Modificações diretas em objetos SAP, implicit enhancements e escrita em tabelas padrão. Representam alto risco e devem ser eliminados.
Exemplo: alteração direta no código padrão de criação de notas fiscais.
Por que isso importa nos projetos SAP?
Esse novo modelo aproxima a teoria da prática. Em muitos projetos, encontramos cenários híbridos, onde temos partes modernas em BTP e, ao mesmo tempo, código legado em ABAP clássico.
Com os novos níveis, o CIO e o time de TI ganham visibilidade sobre o risco de cada extensão, podendo:
- Priorizar a eliminação de extensões nível D.
- Planejar a modernização gradual de extensões nível C, usando o changelog para evitar surpresas em upgrades.
- Reconhecer que nem todo uso de ABAP clássico é “inimigo do Clean Core” — algumas APIs maduras agora são oficialmente aceitas no nível B.
Imagine um cliente que vai migrar seu SAP ECC cheio de customizações para o S/4HANA:
- Seu painel de relatórios Z baseado em ALV com BAPIs → agora classificado como Level B (estável, pode permanecer).
- A integração de pedidos com WMS que usa tabelas internas → cai em Level C (precisa de monitoramento e refatoração futura).
- A modificação direta na transação de MIRO → é Level D (requer eliminação imediata).
Esse olhar mais realista evita a visão punitiva do passado (“tudo é unclean”) e cria um plano de transição gradual, mantendo a modernização estratégica viável.
Conclusão
O novo Clean Core Level Concept traz mais clareza, transparência e pragmatismo.
- Level A segue como referência, alinhado à estratégia “BTP First”.
- Mas agora, as empresas podem lidar com o legado de forma estruturada, sem paralisar projetos.
Na Redware Brasil, entendemos a importância de manter o SAP limpo de customizações malfeitas, que acabam comprometendo atualizações e gerando alto custo de manutenção. Ao mesmo tempo, avaliamos o SAP BTP não apenas como uma decisão técnica, mas também comercial: embora favoreça a atualização do núcleo do sistema, ele pode elevar significativamente os custos de infraestrutura, desenvolvimento e manutenção para as empresas.
Por isso, acreditamos em um equilíbrio: adotar o Clean Core de forma responsável, aproveitando os benefícios do BTP quando fizer sentido estratégico, mas sempre com foco em soluções sustentáveis, eficientes e financeiramente viáveis para cada cliente.
E você? Como enxerga o impacto desse novo modelo nos seus projetos SAP? Já mapeou quantas das suas extensões cairiam nos níveis C e D?
