Trocar tabela por CDS liberada pode mudar o resultado do seu relatório

A ocorrência mais comum no débito Clean Core é a leitura direta de uma tabela da SAP: um SELECT em uma tabela que a SAP considera interna. Para muitas delas, a própria SAP indica uma CDS liberada como sucessora, e o ADT chega a oferecer a troca automática. Parece o trabalho mais simples da adequação. É também o que mais esconde risco.

O problema não é a troca em si. É assumir que a CDS sucessora devolve exatamente o que a tabela devolvia.

Campo que não existe, ou que não é o mesmo

A sucessora nem sempre tem todos os campos da tabela. Quando o programa usa um campo sem correspondente, a troca simplesmente não fecha. O caso mais traiçoeiro é outro: o campo existe na CDS, com nome parecido, mas com conteúdo diferente, porque a CDS converte o valor, soma ou aplica uma regra. O código compila, o programa roda e o número muda.

Filtro embutido

Uma CDS pode trazer só parte dos registros da tabela. Uma tabela que guarda vários tipos de documento pode ter como sucessora uma CDS que traz só um deles. Uma CDS de documentos pode deixar de fora os já eliminados, os arquivados ou os modelos. Se o programa precisava desses registros, o relatório passa a mostrar menos, sem nenhum erro.

Controle de acesso

CDS liberadas costumam vir com controle de acesso: dependendo das autorizações de quem roda, a mesma consulta devolve menos registros, e dados pessoais bloqueados podem sumir. O SELECT original não fazia essa verificação. Trocar a fonte sem tratar isso cria uma regra de acesso nova dentro de um relatório antigo: um usuário que sempre viu a lista inteira passa a ver só uma parte.

Como verificar antes de trocar

"Compilou" e "o ATC parou de apontar" não bastam como critério. O que importa é o programa continuar devolvendo o mesmo resultado. Qualquer que seja a forma de fazer a troca, à mão, pelo quick fix do ADT ou com alguma automação, quatro verificações evitam a surpresa:

1. Liste os campos que o programa usa, e não só os que aparecem no SELECT: um campo lido no começo pode ser usado muito depois, num cálculo ou numa saída. Para cada um, confirme que a CDS tem o equivalente e que o conteúdo é o mesmo, com o mesmo elemento de dados e sem conversão no caminho.
2. Leia a definição da CDS no ADT. Condições no WHERE, junções e associações mostram quais registros ela deixa de fora. Se o programa precisa desses registros, a sucessora não serve como está.
3. Olhe o controle de acesso. A anotação de autorização e a regra de acesso (DCL) da CDS dizem se a leitura passa a depender de quem roda o programa. Manter o comportamento antigo ou adotar a regra nova é uma escolha legítima, desde que feita de propósito, e não por acidente.
4. Compare com dados reais. Num ambiente com dados representativos, leia a fonte antiga e a nova com o mesmo filtro e compare registro a registro, nos campos que o programa usa. Contagem igual não basta: duas listas podem ter o mesmo tamanho e registros diferentes.

Depois da troca, ative o objeto, rode o ATC de novo para garantir que nenhuma ocorrência nova apareceu e deixe o teste funcional com quem conhece o processo. Quando alguma das quatro verificações falha, a troca deixa de ser só técnica e passa a ser uma decisão de negócio. É melhor tomá-la antes, com o impacto à vista, do que descobri-la em produção.

Para ver como essas correções aparecem no painel da SAP, leia Como o SAP Cloud ALM calcula o débito Clean Core.