2 - Configuração inicial
Este capítulo cobre o que precisa estar em ordem antes de cadastrar o primeiro endpoint. São quatro coisas: acesso à tela, um endereço do lado do cliente, saída de rede a partir das estações, e a rotina de reenvio ligada.
1. Onde fica a tela
A tela é cadastrada com restrição de acesso de propósito. Ela guarda o HMAC secret e os headers de autenticação do sistema do cliente — ou seja, credenciais de terceiros. Tratar como tela de administrador: liberar apenas para quem cuida de integrações, nunca para o operador de balcão.
2. O endereço do lado do cliente
O cliente precisa fornecer uma URL que aceite a chamada e responda rápido. Não adianta cadastrar antes de existir: o teste vai falhar e o histórico vai encher de tentativa perdida.
O que combinar com o cliente antes de cadastrar:
-
A URL completa, com
https://— inclusive o caminho (ex.:https://sistema.cliente.com.br/integracao/tryerp/fiscal) - Como autenticar — se o endpoint exige algum header (um token, uma chave de API) e qual é
- Se vai validar assinatura — e, nesse caso, qual será o segredo compartilhado (ver capítulo Cadastrar um endpoint)
- Quais eventos interessam — quase sempre autorização e cancelamento; encerramento só faz sentido para quem usa MDF-e
O capítulo Guia para o desenvolvedor do endpoint foi escrito para ser enviado direto ao programador do cliente. Ele é autocontido e explica o contrato inteiro — formato, headers, assinatura, o que responder e como se comportar em caso de repetição. Mandar essa página adiantada economiza várias idas e vindas.
3. A rede: quem chama é a estação, não o servidor
Este é o ponto que mais gera surpresa, então vale entender antes de cadastrar.
Quem faz a chamada HTTP é o TryERP rodando na estação — a mesma máquina que emitiu o documento (no envio imediato) ou a máquina designada para a rotina de reenvio. Não existe um servidor central da tryideas fazendo essa chamada.
| Consequência | O que verificar |
|---|---|
| A saída HTTPS precisa estar liberada nas estações | Firewall/proxy da rede do cliente permite as estações alcançarem a URL cadastrada |
| URL interna só funciona se for enxergada dali | Se o endpoint é http://192.168.0.x, ele precisa estar na mesma rede das estações. Endereço interno de outra rede não vai resolver |
| Não é preciso abrir porta de entrada no cliente do TryERP | O tráfego é de saída. Quem precisa estar publicamente acessível é o endpoint do destinatário |
Se a rede usa proxy com autenticação, a chamada vai falhar com erro de conexão e o histórico vai mostrar isso como falha do endpoint — quando o problema é a saída da rede. Testar com o botão Testar envio na própria estação antes de culpar o destinatário.
4. A rotina de reenvio
A rede de segurança (a rotina que reenvia o que falhou) é iniciada junto com o sistema e roda a cada 2 minutos. Ela só é ativada em uma instância por máquina — se o operador abre dois TryERP no mesmo computador, apenas o primeiro executa a varredura.
Isso é proposital: evita que várias estações fiquem varrendo a mesma fila ao mesmo tempo. Mesmo que duas máquinas diferentes rodem a rotina, o sistema reserva cada notificação antes de enviar, então não há envio em duplicidade.
Consequência operacional: com todos os TryERP fechados, nada é reenviado. As notificações pendentes ficam guardadas e saem quando alguém abrir o sistema. Em operação normal isso não aparece, porque o envio imediato já resolveu; só importa no cenário de endpoint que ficou fora do ar durante a noite.
5. Conferência rápida antes de seguir
| Item | Como confirmar |
|---|---|
| Tela acessível | O item aparece no menu e abre sem erro de permissão |
| Filial correta disponível | O campo Emitente/Filial no topo lista a filial que vai emitir |
| Endereço do cliente no ar | O cliente confirma que o endpoint responde |
| Saída de rede liberada | Botão Testar envio retorna sucesso (capítulo seguinte) |
Próximo capítulo: Cadastrar um endpoint — campo a campo, e o teste de conectividade.