SAP
O CMS integra com SAP ECC e S/4HANA por três protocolos — RFC/BAPI, IDoc e OData (SAP Gateway) —, pelo SAP CPI (Cloud Integration), quando a integração já passa pelo Integration Suite, e pelos packs prontos sobre RFC. Eles não competem entre si: resolvem problemas diferentes. Esta página diz qual usar; as páginas seguintes detalham cada um.
Qual caminho usar
| RFC / BAPI | IDoc | SAP Gateway (OData) | SAP CPI | Packs SAP | |
|---|---|---|---|---|---|
| Quem inicia | O CMS chama o SAP | O SAP chama o CMS | O CMS chama o SAP | O CMS chama o iFlow | — |
| Natureza | Síncrono, request/response | Assíncrono, orientado a documento | HTTP, request/response | HTTP e SOAP, request/response | Configuração pronta sobre RFC |
| Serve para | Ler e gravar dados pontuais | Receber documentos de negócio em volume | Consumir serviços OData já publicados (os dos apps Fiori, APIs do S/4HANA) | Entregar a iFlows que já fazem o mapeamento para o SAP | Cenários clássicos de chão de fábrica |
| Exemplo | Apontar produção, ler a ordem 60003285 | Receber ORDERS, MATMAS, DELVRY | Ler centros de trabalho, confirmar operação pelo serviço Fiori | Mandar o apontamento a um iFlow /http/pp/confirmacao | “Apontamento de produção por tempo” |
| Microserviço | cms-sap-connector | cms-idoc-connector | Nenhum: HTTP direto, sem SDK | Nenhum: HTTP direto, sem SDK | Usa o de RFC |
| Página | SAP RFC / BAPI | SAP IDoc | SAP Gateway (OData) | SAP CPI | Packs SAP |
Na prática, uma implantação típica usa RFC para o fluxo operacional (o MES aponta produção, lê a carteira de ordens) e IDoc para o cadastro e o documento de negócio (material, ordem de venda, remessa) — que é como o próprio SAP separa as duas coisas.
Os packs não são um quarto caminho: são RFC/BAPI já configurado, com os nomes de campo de negócio no lugar dos técnicos e os erros do SAP traduzidos. Quem começa por eles evita descobrir na marra qual BAPI chamar.
O SAP Gateway (OData) é o caminho quando o serviço já existe do lado do SAP — os apps Fiori e as APIs do S/4HANA são OData —, ou quando o time SAP prefere publicar OData a liberar RFC. É HTTP puro: não usa o SDK nem microserviço, e uma conexão atende a todos os serviços do servidor.
O SAP CPI é o caminho quando o cliente já integra pelo Integration Suite: o iFlow faz o mapeamento e fala com o SAP, e o CMS entrega a ele (ou lê dele). Também é HTTP puro, e a conexão é o tenant — com a API de gestão opcional para escolher o iFlow numa lista e saber como cada mensagem terminou lá dentro.
A arquitetura, e por que ela é assim
Nenhum dos dois lados RFC roda dentro do cms-api. Os dois vivem em microserviços separados,
porque o SAP NetWeaver RFC SDK é código nativo em C: um crash de addon derrubaria a API, o agendador
e os workers junto. Em processo separado, derruba apenas a integração SAP.
E são dois microserviços, não um, porque um RFC Server é um listener de longa duração registrado no gateway SAP — natureza completamente diferente de um cliente request/response. Uma falha ou reinício do listener não pode afetar o cliente RFC nem a API.
Os dois serviços ficam só na rede interna do docker-compose, sem porta publicada e sem passar
pelo nginx. Os endpoints, exceto /health, exigem o header X-Internal-Token quando o token
correspondente está configurado.
O pré-requisito comum: o SDK
RFC/BAPI, IDoc e os packs dependem do SAP NetWeaver RFC SDK oficial (o SAP Gateway e o SAP CPI, não), usado através do node-rfc. Não há
emulação nem tradução intermediária: a chamada sai do connector direto para o gateway RFC do seu SAP,
com o mesmo protocolo de um programa ABAP remoto.
O SDK é licenciado pela SAP e não pode ser redistribuído, por isso não vem embutido na imagem — ele é instalado na implantação, com a licença do cliente. O passo a passo está em SAP RFC / BAPI.
A variante do SDK precisa bater com a plataforma do container (Linux x86_64), não com a do
servidor SAP (AIX, por exemplo). Baixar a variante errada é a causa mais comum de falha na
compilação do node-rfc.
Uma conexão, dois blocos de configuração
A Conexão Externa do tipo SAP guarda a configuração dos dois lados, em blocos separados:
- RFC client — como o CMS chega ao SAP: application server ou message server (com grupo de logon), mandante, usuário, senha, idioma, SAProuter, tamanho do pool e a função usada no teste de conexão.
- RFC server (IDoc) — como o SAP chega ao CMS: gateway host e serviço, Program ID e o logon usado para carregar os metadados dos segmentos.
Os dois blocos podem apontar para sistemas diferentes, e o de IDoc só é preenchido quando há recebimento de IDoc.
O idioma da conexão (sapLang) determina o idioma das mensagens de erro que o SAP devolve —
e os Erros de Negócio casam por texto. Mudar o idioma depois de configurar exige revisar as regras.
Segurança: o que o CMS não deixa chamar
O nome da função configurada numa Coleta ou Entrega passa por uma validação antes de ser salvo e antes de ser executado:
- precisa ter formato de identificador ABAP válido;
- não pode estar na lista fixa de funções bloqueadas:
RFC_ABAP_INSTALL_AND_RUN,RFC_START_PROGRAM,SXPG_COMMAND_EXECUTE,SXPG_STEP_COMMAND_EXECUTE,RFC_GET_TABLE_ENTRIES,BAPI_TRANSACTION_COMMITeBAPI_TRANSACTION_ROLLBACK; - não pode ter prefixo de gestão de usuário (
SUSR_).
BAPI_TRANSACTION_COMMIT é bloqueada como configuração porque o commit tem lugar próprio: a opção
commit após a chamada na Definição de Entrega. RFC_PING é sempre permitida — é o que o teste de
conexão e o keep-alive usam.
Isto é defesa em profundidade, não a proteção principal. A proteção real é a role S_RFC do usuário de serviço no SAP, restrita aos function groups estritamente necessários. Um CMS bem configurado com um usuário SAP mal configurado continua sendo um problema.