Por que um programa com tela clássica para no nível B
O nível A exige ABAP Cloud, e o ABAP Cloud não aceita tela do SAP GUI. O que isso significa para relatórios e transações Z, e quando vale ir até o A.
Quem começa a adequação Clean Core costuma se surpreender com um detalhe do painel do SAP Cloud ALM: um relatório Z corrigido por completo, sem nenhuma ocorrência, continua no nível B. Não é erro de medição. É regra, e entender essa regra muda a forma de planejar o trabalho.
O nível A exige ABAP Cloud
Um objeto em ABAP padrão, mesmo sem nenhuma ocorrência, aparece como nível B. Para chegar ao A, ele precisa estar na versão de linguagem ABAP Cloud, que só permite APIs liberadas pela SAP. A conversão é um passo próprio do trabalho: além de zerar o débito, é preciso tirar o que o ABAP Cloud não aceita, mesmo que não conte como débito.
O que o ABAP Cloud não aceita
O ABAP Cloud nasceu na nuvem pública, onde a SAP atualiza o sistema de todos os clientes sem testar o código de cada um. Por isso ele é bem mais do que "usar só API liberada": é uma versão enxuta da linguagem, em que o que não existe simplesmente não ativa. As principais diferenças:
| Área | No ABAP clássico | No ABAP Cloud |
|---|---|---|
| Interface | Dynpro, tela de seleção, listas com WRITE, ALV, GUI status |
Fiori sobre RAP, com serviço OData. O desenvolvimento é só no ADT, sem SAP GUI |
| Programas | REPORT, INCLUDE, module pool, SUBMIT, CALL TRANSACTION |
Só classes, interfaces e grupos de função. Processamento em fundo vira application job |
| Objetos da SAP | Qualquer um | Só os liberados: tabela da SAP dá lugar à CDS liberada, e BAPI à interface RAP sucessora, quando existe |
| Arquivos | OPEN DATASET, upload e download pelo SAP GUI |
Sem acesso ao sistema de arquivos do servidor |
| Banco de dados | SQL nativo (EXEC SQL), cursores, acesso a outro mandante |
ABAP SQL e AMDP, sempre só no mandante corrente |
| Transação | Update task, PERFORM ON COMMIT |
Atualização sempre local. Dentro do RAP, quem confirma a gravação é o próprio framework |
| Paralelismo | STARTING NEW TASK, tRFC |
Frameworks liberados: CL_ABAP_PARALLEL e o Background Processing Framework |
| Ampliações | User exit, ampliação implícita ou explícita, modificação | Só BAdI liberado |
| Serviços técnicos | Funções clássicas de log, numeração, e-mail e bloqueio; Smart Forms e SAPscript; destinos na SM59 | APIs liberadas para cada serviço, Adobe Forms e cenários de comunicação |
| Linguagem | Macros, header line, MOVE, DESCRIBE e outros comandos obsoletos |
Sem macros e sem obsoletos. Mensagem só por exceção, pelo RAP ou pelo log de aplicação |
E o que costuma ser dito como proibido, mas não é: criar e chamar módulos de função próprios, RFC síncrono, COMMIT WORK fora do RAP, AMDP, programação dinâmica (com a verificação de liberação feita na execução), AUTHORITY-CHECK e leitura e gravação nas tabelas próprias da empresa.
Para um programa com tela clássica (SAP GUI), a primeira linha da tabela já decide: ele não tem como ser ABAP Cloud. Logo, o máximo dele é o nível B. Levá-lo ao A significa refazer a interface em Fiori, um projeto à parte.
A lista completa, com os comandos de cada área e o que entra no lugar de cada um, está em ABAP Cloud: o que muda em relação ao ABAP clássico.
A e B não são a mesma coisa
Os dois níveis estão do lado aceito pelo Clean Core. A diferença está em quem garante:
| Nível B (ABAP padrão) | Nível A (ABAP Cloud) | |
|---|---|---|
| Estabilidade | Na prática: uma BAPI quase nunca muda, mas a SAP não assume compromisso formal | Por contrato: o objeto liberado só muda com aviso e sucessor indicado |
| Quem garante | O ATC, quando é executado | O próprio sistema: código com uso não liberado não é ativado |
| Pode piorar depois | Sim: uma alteração futura pode voltar a ler uma tabela da SAP | Não: a verificação de sintaxe recusa |
| Onde funciona | SAP S/4HANA on-premise e Private Edition | O mesmo modelo vale em todas as edições; o código vai para onde as mesmas APIs estão liberadas, como a Public Edition |
Até onde cada objeto pode chegar
Antes de prometer um nível, vale classificar cada objeto:
| Tipo de objeto | Como reconhecer | Até onde pode chegar |
|---|---|---|
| Clássico por natureza | Tem tela: tela de seleção, dynpro, WRITE ou lista ALV |
B |
| Convertível para ABAP Cloud | Não tem tela: classes de regra de negócio, funções de cálculo, interfaces | A, se todo uso da SAP tiver alternativa liberada ou wrapper |
Num objeto clássico por natureza, trocar uma ocorrência B por uma API liberada reduz o débito, mas o nível continua B. Comandos clássicos que não geram ocorrência, como FORM, WRITE e as telas, podem ficar como estão: não mudam o débito nem o nível.
Então vale tratar um programa com tela?
Vale, e muito. O risco real de um upgrade está nas ocorrências C e D: leituras diretas de tabelas da SAP, que ela considera internas, e usos fora do Clean Core, que podem quebrar quando a SAP muda o sistema. Um objeto sem ocorrências C e D já elimina quase todo esse risco, e é isso que o painel mostra como ganho de pontuação.
O nível A compensa onde o código vai continuar evoluindo: regras de negócio compartilhadas, wrappers e desenvolvimento novo. Nesses casos, a garantia de que o código não volta a piorar paga a conversão. Para entender como esses pontos entram na conta do painel, leia Como o SAP Cloud ALM calcula o débito Clean Core.
Fontes
- SAP Help, ABAP Keyword Documentation, Language Elements in ABAP Versions (S/4HANA 2025) e a documentação de ABAP for Cloud Development.
- SAP Community, ABAP Cloud FAQ.
- Thomas Schneider (SAP), ABAP Language Versions – FAQs, SAP Community.
- SAP, Cloudification Repository (GitHub SAP/abap-atc-cr-cv-s4hc), com os sucessores liberados dos objetos clássicos.