SAP CPI (Cloud Integration)

O CMS chama os iFlows do SAP Cloud Integration (Integration Suite) pelo endpoint do adaptador de entrada: HTTPS em /http/... e SOAP em /cxf/.... É o caminho quando a integração com o SAP já passa pelo CPI — o iFlow faz o mapeamento e fala com o S/4HANA, e o CMS só entrega a ele.

Como o SAP Gateway, é HTTP puro: não usa o SDK nem microserviço. Vale para os três ambientes: Cloud Foundry, Neo e Edge Integration Cell.

Ver SAP para comparar com RFC/BAPI, IDoc e Gateway.

Como se monta

• A Conexão Externa é o tenant. Ela tem duas partes, com credenciais separadas no BTP:
  • o runtime, onde os iFlows rodam — é para ele que Coletas e Entregas vão;
  • a API de gestão (opcional), que o CMS só lê: endpoints implantados e como terminou o processamento de cada mensagem.
• A Aplicação é do tipo SAP CPI e aparece no grupo SAP em todas as telas. A URL dela vem da conexão e fica travada.
• O caminho do iFlow fica em cada Coleta (Caminho da Coleta) e em cada Entrega (URI).

Exemplo: runtime https://meutenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com, Entrega com o caminho /http/pp/confirmacao. A chamada sai para https://meutenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com/http/pp/confirmacao.

O sentido contrário — o iFlow chamar o CMS — não precisa desta conexão: o iFlow usa a Entrada HTTP ou a API dinâmica de Coleta, com um API Token, como qualquer sistema.

O que preparar no BTP

No Cloud Foundry, as credenciais saem de instâncias do serviço SAP Process Integration Runtime, em Services › Instances and Subscriptions da subconta (vale também para o trial):

Nas duas, o Grant type é Client Credentials. Depois de criar a instância, crie uma Service Key nela: é o JSON que o CMS lê.

{
  "oauth": {
    "clientid": "sb-xxxx!b123|it-rt-meutenant!b456",
    "clientsecret": "....",
    "url": "https://meutenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com",
    "tokenurl": "https://minhasubconta.authentication.us10.hana.ondemand.com/oauth/token"
  }
}

O campo url da service key do runtime tem -rt no host; o da API de gestão, não.

No Neo e no Edge Integration Cell o comum é usuário e senha de um usuário com o papel ESBMessaging.send.

Configurar a conexão

Em Conexões Externas, tipo SAP CPI (Cloud Integration), no grupo SAP.

Colar service key

Ao lado da URL do runtime e da URL da API de gestão há o link Colar service key. Cole o JSON inteiro e clique em Preencher: a URL, a URL do token, o client id e o client secret são preenchidos (na service key de certificado, o certificado e a chave privada). O JSON não é salvo — só os campos seguem no Salvar, com os segredos cifrados.

As duas service keys têm o mesmo formato, e colar uma no lugar da outra é o engano mais comum. Se a URL colada no runtime não tem -rt (ou a da API de gestão tem), a tela avisa.

Runtime

Senha, client secret, chave privada e a senha da chave ficam cifrados e nunca voltam para a tela: na edição, deixar em branco mantém o atual.

API de gestão (opcional)

Preencha a URL da API de gestão — o url da service key do plano api — e a credencial dela (OAuth 2.0 ou Basic). Com ela em branco, a conexão funciona normalmente; ficam desligados só o catálogo de iFlows e o status no SAP CPI.

O teste de conexão

O runtime do CPI não tem um “ping”, e um GET num endpoint executa o iFlow. Por isso, com o iFlow de teste em branco, o Testar Conexão e o Keep Alive não chamam iFlow nenhum: obtêm o token (o que prova client id e secret) e conferem que o runtime responde. Um 401 ou 403 ali é credencial recusada — no Cloud Foundry, quase sempre falta o papel ESBMessaging.send na instância.

Preencha o iFlow de teste só com um iFlow de ping, sem efeito no SAP. Aí o teste passa a ser um GET nele.

O botão Testar Conexão testa também a API de gestão, quando configurada, e só dá certo com as duas no ar. O Keep Alive testa só o runtime: a API de gestão fora do ar não impede a Entrega, e não derruba a Aplicação.

A Aplicação

No cadastro de Aplicações, escolha o tipo SAP CPI e a conexão no campo de Keep Alive. A URL da Aplicação aparece travada, com a URL do runtime, e muda sozinha se a conexão mudar — junto com o destino das Entregas dela. Autenticação e certificados não ficam na Aplicação.

Coletas e Entregas

O caminho começa em /http/ ou /cxf/: o host vem da conexão. Para um teste de leitura, a Coleta HTTP_GET não precisa estar ativa — o botão Testar do formulário abre o Banco de Testes e executa a leitura.

Escolher o iFlow na lista

Com a API de gestão configurada, o campo de caminho da Coleta e da Entrega ganha o botão iFlows: a lista dos endpoints implantados no tenant, com o nome e a versão do iFlow, o tipo (HTTP ou SOAP) e o status do artefato — STARTED rodando, ERROR implantado com erro. Clicar no + preenche o caminho.

• Na Coleta, só endpoints HTTP podem ser escolhidos.
• Na Entrega, escolher um endpoint SOAP muda o tipo para HTTP_SOAP, e escolher um HTTP tira de lá.
• Endpoint em outro host não sai por esta conexão e fica desabilitado.

Token CSRF

O adaptador HTTPS de entrada nasce com CSRF Protected ligado e recusa POST, PUT, PATCH e DELETE sem um token válido. O CMS resolve isso sozinho:

1. antes da primeira escrita num endpoint /http/, faz um HEAD no próprio endpoint com X-CSRF-Token: Fetch e guarda o token e os cookies da sessão;
2. as escritas seguintes no mesmo endpoint reaproveitam o token (renovado a cada 20 minutos);
3. se o CPI recusar o token (403 com x-csrf-token: Required), o CMS busca outro e tenta uma vez.

No CPI o token é do iFlow: o de um endpoint não serve para outro, então cada endpoint tem o seu. O adaptador SOAP (/cxf/) não usa CSRF, e o CMS nunca busca token para ele. Desligue a opção só se os iFlows estiverem com a proteção desligada.

Outro usuário numa Coleta ou Entrega

A credencial do runtime é a padrão. Quando um iFlow exige outro usuário, escolha uma Credencial da Aplicação no campo Credencial da Coleta ou da Entrega — a primeira opção, Da Conexão SAP CPI, é a padrão. Só a autenticação muda; o token CSRF continua vindo da conexão, guardado por usuário.

Status no SAP CPI

O CPI responde à Entrega assim que recebe. Num iFlow assíncrono — com fila JMS, ou que chama o S/4HANA depois de responder — a falha vem depois, dentro do tenant, e o CMS mostraria “Processada” sem saber de nada.

Toda resposta do CPI traz o id do log de processamento (SAP_MessageProcessingLogID). O CMS grava esse id em cada tentativa de Entrega e de Coleta, no sucesso e na falha, e o usa de duas formas:

No detalhe da mensagem, o painel Status no SAP CPI consulta a API de gestão e mostra, por tentativa: o status no tenant (COMPLETED, FAILED, PROCESSING, RETRY, ESCALATED…), o iFlow, quando terminou, o texto do erro e o link Abrir no Monitor do CPI. O tenant guarda os logs por cerca de 30 dias; mais antigo que isso, o painel diz que não encontrou.

Pelo alerta Falha no iFlow (SAP CPI): o agendador de sistema Check-sap-cpi-processamento confere, a cada minuto, as Entregas das últimas 24 horas que o CPI aceitou e que ainda não têm status final. Quando o iFlow termina em FAILED, ESCALATED ou ABANDONED, dispara o alerta — uma vez por tentativa.

O alerta nasce pré-cadastrado, desativado e sem destinatários, ao criar uma Entrega para uma Aplicação SAP CPI, ao lado do Erro de Entrega. Para receber, ative-o em Alertas e escolha os destinatários. Sem API de gestão na conexão, a varredura não faz chamada nenhuma.

Quando dá erro

A falha de uma Coleta ou Entrega traz o texto que o iFlow devolveu, depois do status.