Wrapper no Clean Core: o débito se concentra, não some
Quando a SAP não oferece substituto liberado, o wrapper isola o uso não liberado num ponto só. Como ele mexe no débito, quando compensa e quando não.
Nem toda função ou tabela da SAP tem um substituto liberado. Para esses casos, a recomendação da própria SAP para quem segue o Clean Core é o wrapper: um objeto da empresa que encapsula o uso não liberado atrás de um contrato liberado. Os programas passam a usar o wrapper, e o uso não liberado fica num lugar só.
É uma boa ferramenta, desde que se entenda o que ela faz com o débito.
O que é um wrapper
O wrapper não reescreve a lógica da SAP: ele só repassa. A regra continua sendo a da função ou da tabela original, e o comportamento não muda. O que muda é que, em vez de dezenas de programas chamarem a função interna, todos chamam o wrapper, e só o wrapper chama a função.
| Tipo | Quando usar | Como é |
|---|---|---|
| Função da SAP | A função não tem substituto liberado e vários objetos Z a chamam | Interface liberada e uma classe que chama a função original, repassando tudo |
| Classe da SAP | A classe não é liberada, não tem sucessora liberada e vários objetos Z chamam os métodos dela | Interface liberada e uma classe que cria a classe original e repassa as chamadas, só para os métodos que os objetos Z usam |
| Tabela da SAP | Várias CDS Z leem a mesma tabela e a SAP não indica sucessora liberada | Uma CDS com os campos da tabela, com os mesmos nomes e sem filtro |
O débito muda de lugar
O wrapper continua usando o que não é liberado, então a ocorrência passa para ele: um wrapper de tabela fica no nível C, como qualquer CDS que lê tabela da SAP. O ganho está nos objetos que passam a usar o wrapper, que deixam de ter a ocorrência.
Por isso a conta é simples:
- com um único objeto usando, o débito só muda de lugar, e o wrapper não compensa;
- a partir de dois, o débito cai: dez programas que chamavam a mesma função interna viram uma ocorrência só, no wrapper.
Quando o wrapper é criado, a primeira troca não reduz o débito: só o muda de lugar. Cada objeto que passa a usá-lo depois reduz.
Quando não fazer wrapper
- Quando a SAP indica uma sucessora liberada. Nesse caso, a troca pela sucessora é o caminho: ela tira a ocorrência de vez.
- Quando a função depende de quem a chama. Se o corpo da função testa quais parâmetros foram informados, repassar tudo pode não equivaler a omitir, e o wrapper mudaria o comportamento.
- Quando o objeto Z herda de uma classe da SAP ou implementa uma interface dela. Aqui o vínculo é a própria estrutura do objeto, não uma chamada, e não há o que repassar: o caminho é a alternativa liberada, quando existe, ou manter como está.
- Quando é para esconder o problema. Um wrapper que acrescenta regra própria em cima da SAP deixa de ser wrapper: vira um objeto Z novo, com lógica nova, para manter.
Por que liberar o wrapper
Um wrapper costuma ser liberado com o contrato C1. Sem isso, o código ABAP Cloud de outro componente de software não consegue usá-lo, e ele perderia a razão de existir: preparar o caminho para o nível A. No mesmo componente, a chamada funciona sem contrato, mas a dependência fica escondida. A liberação também é um compromisso com quem usa: o wrapper não pode mudar de forma incompatível. 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, como mostra Contratos de liberação de API: o que o C0, o C1, o C2, o C3 e o C4 garantem. A regra de quem pode chamar quem, e por que ela depende do componente de software, está em Componentes de software no ABAP Cloud: quem pode chamar quem.
O wrapper é a ponte entre o código que existe hoje e o ABAP Cloud. Usado no lugar certo, concentra o problema num ponto conhecido, vigiado pelo ATC, e libera o resto do código para seguir limpo. Para entender como o nível de cada objeto é calculado, leia Como o SAP Cloud ALM calcula o débito Clean Core.