Componentes de software no ABAP Cloud: quem pode chamar quem
Num objeto ABAP Cloud, o que decide se uma chamada é aceita não é a versão de linguagem do objeto chamado, e sim o componente de software. Como a regra funciona, por que o C1 não limpa débito e como organizar os componentes.
Quem começa a escrever código em ABAP Cloud no S/4HANA logo esbarra numa mensagem como "The use of Class ZCL_... is not permitted", ao chamar uma classe Z que já existe. A reação comum é converter também a classe chamada para ABAP Cloud. Muitas vezes não adianta: o erro continua. A explicação está num conceito pouco comentado, o componente de software.
O que é um componente de software
Um componente de software é um conjunto de pacotes que forma uma unidade de entrega: ele é versionado, instalado e atualizado como um bloco. O próprio S/4HANA é feito deles. Em Sistema → Status, na lista de componentes instalados, aparecem nomes como SAP_BASIS (a base técnica), SAP_ABA e S4CORE (o núcleo do S/4HANA), cada um com a sua versão e o seu nível de pacote de suporte.
O código da empresa também mora em componentes:
- todo pacote pertence a exatamente um componente, e todo objeto pertence a um pacote. A hierarquia é componente → pacote → objeto;
- os pacotes Z ficam, por padrão, no componente HOME, que existe em todo sistema para o desenvolvimento do cliente. Muitas empresas têm todo o código Z nele, sem nunca ter pensado no assunto;
- a empresa pode criar os seus próprios componentes, por exemplo um para o código novo e outro para o legado, e escolher em qual deles cada pacote fica;
- no SAP BTP ABAP Environment, cada componente corresponde a um repositório Git, o que deixa a ideia de "unidade de entrega" mais visível.
Para quem vem de outras linguagens, a analogia mais próxima é a de um módulo: um limite em volta de um conjunto de código, que diz o que pertence a ele. No ABAP clássico, esse limite quase não fazia diferença no dia a dia. No ABAP Cloud, ele passa a decidir quem pode chamar quem.
Onde mora a "marca" de ABAP Cloud
A versão de linguagem aparece em três lugares, e cada um tem um papel:
| Onde | O que define |
|---|---|
| Objeto | A versão de linguagem do próprio objeto: ABAP padrão ou ABAP Cloud. É ela que o SAP Cloud ALM usa para o nível A |
| Pacote | A versão sugerida para os objetos novos criados nele |
| Componente de software | O grupo de pacotes e a regra do que pode existir dentro dele |
O componente de software é configurado pela administração do sistema (no S/4HANA, pelo report RSMAINTAIN_SWCOMPONENTS) e tem duas características: se é transportável ou local, e qual versão de linguagem aceita.
| Versão do componente | O que aceita |
|---|---|
| Standard ABAP | Qualquer objeto, padrão ou ABAP Cloud: é um componente sem restrição, apesar do nome |
| ABAP for Cloud Development | Só objetos ABAP Cloud. Um objeto padrão é recusado, e todo objeto novo já nasce ABAP Cloud |
O componente padrão dos objetos Z costuma ser o HOME, que é "Standard ABAP", ou seja, sem restrição.
A regra: quem pode chamar quem
Um objeto em ABAP padrão chama qualquer coisa: a regra só vale para quem está em ABAP Cloud. Para ele, o que decide é o componente de software do objeto chamado:
| O objeto ABAP Cloud chama um objeto Z... | Resultado |
|---|---|
| do mesmo componente, padrão ou ABAP Cloud | Aceito, sem contrato |
| de outro componente, sem liberação C1 | Recusado: "The use of ... is not permitted" |
| de outro componente, com liberação C1 | Aceito |
O detalhe que surpreende: a regra vale mesmo quando o objeto chamado já é ABAP Cloud. Uma classe ABAP Cloud em outro componente, sem C1, continua inacessível. E o contrário também vale: um objeto em ABAP padrão com C1 pode ser chamado por código ABAP Cloud de outro componente. É exatamente assim que funciona um wrapper.
Há uma exceção documentada pela SAP: as Software Component Relations, que permitem a um componente ABAP Cloud usar objetos de outro componente ABAP Cloud sem liberar cada um deles. A documentação não diz a partir de qual release do S/4HANA on-premise o recurso está disponível. Sem uma relação configurada, vale a regra da tabela.
O C1 libera o uso, não limpa o débito
A liberação C1 é um contrato: o objeto passa a poder ser usado por código ABAP Cloud de outros componentes, e quem o libera se compromete a não fazer mudanças incompatíveis nele. Num objeto Z, quem cobra esse compromisso é o ATC de compatibilidade de API, com uma foto (snapshot) da API tirada antes, e não a ativação (veja Contratos de liberação de API: o que o C0, o C1, o C2, o C3 e o C4 garantem). A liberação não muda nada nas ocorrências do próprio objeto. Um wrapper com C1 que lê uma tabela da SAP continua tendo a ocorrência de nível C.
E as chamadas entre objetos Z nunca geram ocorrência no check de Clean Core: ele só avalia o uso de objetos da SAP. Isso tem uma consequência importante:
- um objeto ABAP Cloud fica no nível A mesmo chamando, no mesmo componente, um objeto Z padrão de nível C;
- o débito existe, mas mora no vizinho, e não aparece no objeto A.
Por que separar o código ABAP Cloud num componente próprio
Se o código ABAP Cloud fica num componente sem restrição, junto com o legado, ele pode chamar qualquer objeto Z antigo sem contrato. O resultado é um nível A com dependências escondidas.
Com o código ABAP Cloud num componente que só aceita ABAP Cloud, toda dependência do legado passa a exigir um objeto com C1. Cada dependência vira um contrato explícito, revisado e visível, e o débito fica concentrado nos wrappers. É também a orientação do ABAP Extensibility Guide da SAP: código ABAP Cloud num componente de ABAP Cloud, código clássico no HOME ou num componente clássico.
A SAP organizava isso no antigo modelo de três camadas. Desde agosto de 2025 ela fala em níveis A a D e em "desenvolvimento ABAP Cloud" e "desenvolvimento ABAP clássico", mas a separação em camadas continua sendo um jeito prático de organizar os componentes:
| Camada | Onde fica | Regra |
|---|---|---|
| 1. ABAP Cloud | Componente que só aceita ABAP Cloud (ex.: ZCLOUD) | Só usa API liberada da SAP ou objeto Z de outro componente com C1 |
| 2. Wrappers | Componente sem restrição (ex.: ZSTANDARD) | Usa o que não é liberado e se expõe com C1 |
| 3. Legado | Componente sem restrição | É reduzido aos poucos ou encapsulado na camada 2 |
Dentro da camada 2, só a classe que de fato chama a SAP precisa ser ABAP padrão. A interface do wrapper pode ser ABAP Cloud no mesmo componente, e o painel mostra um único objeto fora do nível A por wrapper.
Três cuidados práticos
- A variante de prontidão para ABAP Cloud (
ABAP_CLOUD_READINESS) antecipa a regra. Rodado num objeto padrão, ele aponta as chamadas a objetos Z de outro componente sem C1, que impediriam a conversão. Chamadas no mesmo componente e a objetos com C1 não aparecem. - Trocar o componente de um pacote exige os objetos já em ABAP Cloud, quando o componente novo só aceita ABAP Cloud. Converta primeiro, mude o componente depois.
- Revogue o C1 antes de apagar um objeto liberado que ninguém usa. Se ele for apagado com o contrato ativo, o registro de liberação fica órfão e a request com a exclusão não libera. Se alguém usa o objeto, o caminho é marcá-lo como obsoleto, com um sucessor.
Para ver como o wrapper usa essa regra, leia Wrapper no Clean Core: o débito se concentra, não some. Para entender por que o nível A exige ABAP Cloud, leia Por que um programa com tela clássica para no nível B.
Fontes
- SAP, Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions (ABAP Extensibility Guide), versão 2.3, agosto de 2025, capítulo 5.
- SAP Help, ABAP Development Tools, Released APIs e Software Component Relations.
- Testes de chamada entre componentes num SAP S/4HANA 2025 (SAP_BASIS 816), com classes nos componentes HOME, num componente só de ABAP Cloud e no LOCAL.