Cobertura: REST, SOAP, event-driven, gateway e middleware
Você chama o Integrações Expert quando o problema atravessa fronteiras entre sistemas. O território dele começa no contrato de integração e acompanha a arquitetura que transporta a informação: REST, SOAP, eventos, Gateway, middleware, ESB, iPaaS, webhooks e integrações híbridas. O objetivo não é apenas explicar uma chamada; é identificar onde cada responsabilidade está na jornada integrada.
REST e SOAP têm contrato
Em REST, o expert trabalha com endpoint, método HTTP, autenticação, headers, payload, response, erros e versão. No ecossistema Sankhya, o Developer documenta APIs e requisições via Gateway. Um exemplo real é a autenticação atual por POST /authenticate, usando OAuth 2.0 Client Credentials com client_id, client_secret e X-Token, que retorna um access token JWT. Isso é contrato oficial validado; não é um endpoint deduzido pelo nome de uma tela.
SOAP permanece no território do expert quando a integração utiliza web services e contratos desse modelo. Ele separa protocolo de regra funcional: conhecer XML ou SOAP não autoriza presumir operação, serviço ou estrutura de mensagem. Você precisa trazer o contrato que realmente está em uso.
Gateway e middleware têm papéis diferentes
Gateway controla a entrada governada na API. No Sankhya, chamadas via Gateway dependem de autenticação e autorização, e a documentação oficial descreve o bearer token nas requisições subsequentes. Há ainda uma camada de autorização vinculada aos serviços que a aplicação poderá consumir.
Middleware fica entre sistemas para executar responsabilidades como transformação, roteamento, enriquecimento, desacoplamento e tratamento técnico. ESB e iPaaS entram aqui.
Event-driven muda a unidade de análise
Em uma arquitetura orientada a eventos, o expert separa evento gerado, publicado, consumido e processado. Esses estados não são sinônimos. A arquitetura do Expert trata evento como parte de uma jornada, e não como prova automática de conclusão.
Ao procurar o expert, identifique primeiro se o fluxo é síncrono, assíncrono ou híbrido e onde estão Gateway e middleware. Isso determina qual arquitetura será analisada.
síncrono, assíncrono ou híbrido?
É a primeira pergunta, e ela muda tudo o que vem depois.
Num fluxo síncrono, a resposta HTTP carrega o resultado — e a investigação vive em request, response, status e timeout.
Num fluxo assíncrono, a resposta confirma apenas o aceite. O resultado aparece depois, e a investigação precisa de fila, consumidor, correlation ID e evidência do efeito final.
Num híbrido, os dois convivem — e é onde mais se erra: alguém trata o aceite do síncrono como conclusão do assíncrono.
Um exemplo de contrato oficial validado: POST /authenticate, com OAuth 2.0 Client Credentials, client_id, client_secret e header X-Token, retornando um access token JWT. Isso é contrato documentado — não um endpoint deduzido pelo nome de uma tela.
Dizer o formato do fluxo e onde estão Gateway e middleware determina qual arquitetura será analisada, e economiza metade das perguntas.
Desenhe seu fluxo atual marcando origem, REST ou SOAP, Gateway, middleware, evento e destino antes de pedir uma análise ao Integrações Expert.
As demais aulas, as avaliações e o certificado ficam disponíveis após o cadastro. Iniciativa independente, sem vínculo oficial com a fornecedora do Sankhya ERP.