Tradução de formatos
Cada sistema fala o seu idioma. O hub converte para o formato interno e de volta, sem contaminar os demais.
Ecossistema YveTech · Sistemas · Por dentro
Hub de integrações
Seis sistemas ligados dois a dois dão quinze conexões para manter. Ligados a um ponto central, dão seis. Essa aritmética é o motivo de existir um hub — e ela piora a cada sistema novo.
A conta que ninguém faz no começo
Ligação direta parece mais simples até o quarto sistema. Depois dele, nunca mais.
A primeira integração de uma empresa costuma ser direta: o e-commerce fala com o ERP. Funciona, e por isso a segunda também é feita assim, e a terceira. O problema aparece quando os sistemas viram seis — o número de ligações possíveis cresce muito mais rápido que o de sistemas. Com quatro, são seis conexões; com seis, quinze. Cada uma com o seu formato, o seu horário, o seu jeito de falhar e, quase sempre, uma pessoa diferente que a escreveu.
O hub troca essa teia por uma estrela. Cada sistema conversa apenas com o ponto central, no formato que ele entende, e o ponto central se encarrega de traduzir e entregar a quem precisa. Seis sistemas viram seis conexões. Trocar de transportadora ou de gateway passa a mexer em um ponto, e não em cinco — e a conexão nova não obriga ninguém a revisar as antigas.
O ganho maior, porém, não é o número. É que passa a existir um lugar só onde olhar: uma fila de pendências, um registro de trocas, um painel de situação, um jeito de repetir tentativa. Numa teia de ligações diretas, cada conexão tem o seu próprio comportamento — e descobrir por que um pedido não chegou vira arqueologia em quinze lugares.
O hub não é uma camada a mais por gosto de arquitetura. É o que faz a décima integração custar o mesmo que a segunda — e o que permite trocar um fornecedor sem refazer o resto.
O que o ponto central faz
Seis responsabilidades que, sem ele, ficam espalhadas e repetidas em cada conexão.
Roteamento de eventos
Um pedido novo pode interessar a quatro sistemas. Quem recebe o quê é configuração, e não código novo.
Registro central
Toda troca guardada em um só lugar: origem, destino, conteúdo e resultado, com consulta por pedido ou por período.
Política de falha
Repetição, espera crescente, limite de tentativas e fila de pendências definidos uma vez e valendo para todas as conexões.
Credenciais em um lugar
Chaves e senhas de acesso guardadas e trocadas centralmente, em vez de espalhadas por scripts.
Observação unificada
Volume, tempo de resposta e taxa de erro de todas as conexões no mesmo painel, com a mesma leitura.
A cena, quadro a quadro
O mesmo recorte da vitrine em três momentos do fluxo.
Como uma integração nova entra
O caminho de acrescentar um sistema depois que o hub existe — normalmente dias, e não semanas.
Contrato de dados
Definimos que informação o sistema novo envia e recebe, em que formato e com que frequência.
Conector
Escrevemos apenas a ponta que fala com ele. O resto — registro, repetição, fila, alerta — já existe.
Ensaio com volume real
A conexão roda em homologação com dados parecidos com os de produção, inclusive os casos de falha.
Entrada em operação
Sobe observada, com alerta configurado antes de assumir volume, e passa a aparecer no mesmo painel das demais.
O que a teia de ligações diretas provoca
Sintomas conhecidos de quem foi somando integrações uma a uma.
- Ninguém sabe quantas existem — scripts em servidores diferentes, escritos por gente que já saiu.
- Troca de fornecedor trava — mudar um sistema obriga a mexer em cinco conexões.
- Cada falha avisa de um jeito — quando avisa — várias falham em silêncio.
- Credencial espalhada — senha de acesso dentro de arquivo, sem troca periódica nem controle.
O que o hub muda na prática
Efeitos que aparecem na manutenção, que é onde mora o custo real.
- Conexão nova é rotina — a décima custa o mesmo esforço que a segunda.
- Um lugar para investigar — a pergunta "cadê o pedido" tem uma resposta, e não quinze.
- Fornecedor trocável — mudar de transportadora mexe em um conector.
- Regra de falha única — repetição, fila e alerta valem igual para todas.
Ligação direta e hub, lado a lado
A comparação que costuma decidir a escolha — e que pesa mais a cada sistema acrescentado.
| Situação | Ligações diretas | Com hub central |
|---|---|---|
| Seis sistemas conectados | até 15 conexões para manter | 6 conexões, uma por sistema |
| Acrescentar o sétimo | até 6 conexões novas de uma vez | 1 conector novo |
| Trocar de transportadora | mexer em cada ponto que a chamava | trocar um conector; o resto não sente |
| Descobrir onde um pedido parou | procurar em cada script e cada registro | uma consulta no registro central |
| Mudar a política de repetição | ajustar conexão por conexão | uma configuração, valendo para todas |
| Trocar uma credencial | achar todos os lugares onde ela está | trocar em um cofre só |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
N conexõesuma por sistema, em vez de N × (N−1) ÷ 2
1 registrocentral, para toda troca entre sistemas
1 políticade repetição e falha valendo para todas
Diaspara acrescentar um sistema depois do hub
Perguntas frequentes sobre o hub de integrações
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Isso não é complexidade demais para a minha empresa?
Para duas ou três integrações, provavelmente é — e nesse caso dizemos isso. O hub começa a compensar por volta da quarta conexão, ou antes disso quando a operação depende delas para faturar. O critério não é o tamanho da empresa: é quantos sistemas precisam conversar e o que acontece com o negócio quando um deles para.
O hub vira um ponto único de falha?
É a pergunta certa. Ele é projetado justamente para não ser: as mensagens ficam guardadas antes de serem processadas, então uma parada não perde nada — apenas atrasa, e o processamento retoma do ponto onde estava. Numa teia de ligações diretas, cada script é um ponto único de falha silencioso, e ninguém os observa.
Preciso de servidor próprio para isso?
Depende do volume e das exigências de conformidade. Boa parte dos casos roda na mesma hospedagem que já sustenta o sistema; volumes maiores ou requisitos específicos pedem infraestrutura dedicada. Avaliamos os dois caminhos com o custo na mesa antes de você decidir.
Já tenho integrações funcionando. Preciso refazer tudo?
Não. A migração é gradual: o hub sobe ao lado do que existe e as conexões atuais são trazidas uma a uma, começando pelas que mais dão problema. As que funcionam bem podem ficar como estão por bastante tempo — a decisão de trazê-las costuma vir quando o sistema do outro lado muda.
Quer parar de somar integrações uma a uma?
Mostramos como ficaria o seu desenho atual com um ponto central. Conte o seu cenário e retornamos em até 1 dia útil.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Sistemas de InformaçãoVoltar à visão geral da área
Mapeamento dos processosComo a informação circula hoje — inclusive pelas planilhas paralelas
Modelagem e migraçãoUma base única bem modelada, com o histórico conferido registro a registro
Implantação e integraçãoERP, CRM, fiscal e e-commerce conversando por integrações monitoradas
Treinamento e indicadoresEquipe treinada, painéis publicados e rotina de acompanhamento
Integrações em operaçãoO caminho de um pedido entre os sistemas, do clique ao recebimento
Ambiente de Sistemas de InformaçãoA base única, as camadas em volta dela e o que protege cada uma