API e CronJob de sincronismo de chamados entre Hubsoft e GLPI — integração com Mundiale
Go to file
Rafael Lopes 7b44180de5
Some checks failed
Deploy Production / deploy (push) Failing after 0s
FIX: executa deploy de produção com usuário desenvolvimento
2026-05-07 14:56:58 -03:00
.gitea/workflows FIX: executa deploy de produção com usuário desenvolvimento 2026-05-07 14:56:58 -03:00
src FEAT: Add lookback days configuration for responsible users in ticket repository 2026-05-04 11:14:05 -03:00
.env.example FEAT: Add lookback days configuration for responsible users in ticket repository 2026-05-04 11:14:05 -03:00
.gitignore FEAT: Adicionado variáveis de ambiente para definir os responsáveis por implantação, cancelamento e titularidade no HubSoft 2026-04-30 16:41:28 -03:00
ecosystem.config.js CHORE: Preparando ambiente PM2 para novas Features 2026-01-12 16:40:47 -03:00
fluxoEntidade.md REFACTOR: Preparando WatchDog para nova feature 2026-01-19 17:55:15 -03:00
package-lock.json FEATURE: Finalizado Feature Watchdog, responsável por coletar chamados pendentes de fechamento no GLPI e notificar algum grupo 2026-01-14 17:51:49 -03:00
package.json WIP: Criado Watchdog/Goleito para detectar chamados que estao fechados no hubsoft mas nao no GLPI, testes pendentes 2026-01-12 16:42:08 -03:00
README.md DOC: Documentação ajustada praa se adequar a mudanças 2026-01-06 14:50:26 -03:00

Serviço de Integração HubSoft ⇄ GLPI

Node.js Express.js PostgreSQL PM2 License

Este projeto é um serviço de integração entre HubSoft e GLPI, responsável por sincronizar tickets, fechamentos e comentários, utilizando Node.js, PostgreSQL e uma arquitetura baseada em Clean Architecture.

O foco do projeto é:

  • confiabilidade
  • idempotência
  • isolamento de responsabilidades
  • facilidade de manutenção e evolução

Funcionalidades

  • Criação automática de tickets no GLPI a partir de atendimentos do HubSoft
  • Fechamento automático de atendimentos no HubSoft a partir de tickets encerrados no GLPI
  • Sincronização de comentários do GLPI para o HubSoft
  • Processamento assíncrono via cron/worker
  • Controle de estado e idempotência via banco intermediário
  • Prevenção de concorrência e duplicidade de eventos
  • Execução separada de API e Worker
  • Suporte a execução local, desenvolvimento e produção

🧱 Arquitetura

O projeto segue princípios da Clean Architecture, separando claramente:

Controller → UseCase → Repository → Infra

Camadas

  • Controller
    • Entrada HTTP (webhooks, endpoints)
    • Não contém regra de negócio
  • UseCases
    • Regras de negócio
    • Orquestração dos fluxos
  • Repositories
    • Contratos de acesso a dados e integrações
  • Infra
    • Implementações técnicas (DB, APIs, cron, HTTP)

🔄 Fluxos de Integração

1. Criação de Tickets (HubSoft → GLPI)

Fluxo assíncrono executado por worker (cron).

HubSoft DB
   ↓
Worker (Cron)
   ↓
Banco Intermediário
   ↓
API GLPI

Passo a passo:

  1. Worker consulta novos atendimentos no HubSoft
  2. Use case valida e transforma os dados
  3. Registro é salvo no banco intermediário
  4. Ticket é criado no GLPI
  5. Status de sincronização é atualizado

2. Fechamento de Tickets (GLPI → HubSoft)

Fluxo síncrono iniciado via webhook.

GLPI Webhook
   ↓
API (Controller)
   ↓
UseCase
   ↓
API HubSoft
   ↓
Banco Intermediário

Regras importantes:

  • Apenas tickets elegíveis (ex: tipo Mundiale)
  • Controle de lock para evitar duplicidade
  • Atualização de status após sucesso

3. Sincronização de Comentários (GLPI → HubSoft)

Fluxo acionado por webhook do GLPI.

GLPI Webhook
   ↓
API (Controller)
   ↓
UseCase
   ↓
API HubSoft
   ↓
Banco Intermediário

Detalhes:

  • Sanitização de HTML/texto
  • Controle por comment_id e source_comment_id
  • Garantia de idempotência
  • Comentários duplicados são ignorados

🗄️ Banco de Dados Intermediário

O banco intermediário é fundamental para a integração.

Ele é responsável por:

  • Controle de estado dos tickets
  • Idempotência de webhooks
  • Lock de processamento
  • Auditoria e rastreabilidade

Exemplos de status

  • pending_create
  • created
  • processing_close
  • closed
  • synced

📂 Estrutura do Projeto

src/
├── config/                # Configurações gerais
├── infra/                 # Infraestrutura
│   ├── api/               # Clientes de APIs externas
│   ├── cron/              # Workers / Jobs agendados
│   ├── db/
│   │   ├── connections/
│   │   └── repositories/
│   └── http/
│       └── routes/
├── modules/               # Domínio (Clean Architecture)
│   ├── close/
│   ├── comments/
│   ├── createTickets/
│   └── tickets/
├── shared/                # Código compartilhado
│   └── utils/
├── logs/                  # Logs da aplicação
└── server.js              # Bootstrap da aplicação

🚀 Execução do Projeto

Pré-requisitos

  • Node.js 18+
  • NPM
  • PostgreSQL
  • PM2 (produção)
npm install -g pm2

Variáveis de Ambiente

Criar arquivos:

.env.development
.env.production

Exemplo:

PORT=3000
NODE_ENV=development

HUBGLPI_DB_HOST=localhost
HUBGLPI_DB_PORT=5432
HUBGLPI_DB_USER=postgres
HUBGLPI_DB_PASSWORD=senha
HUBGLPI_DB_NAME=hubglpi

HUBSOFT_DB_HOST=ip
HUBSOFT_DB_PORT=5432
HUBSOFT_DB_USER=usuario
HUBSOFT_DB_PASSWORD=senha
HUBSOFT_DB_NAME=hubsoft

GLPI_API_URL=https://seu-glpi/apirest.php
GLPI_APP_TOKEN=token
GLPI_USER_TOKEN=token

HUBSOFT_API_URL=https://seu-hubsoft/api
HUBSOFT_API_TOKEN=token

▶️ Scripts NPM

Desenvolvimento

Rodar apenas a API:

npm run dev:api

Rodar apenas o worker (cron):

npm run dev:worker

Produção (PM2)

Rodar apenas a API:

pm2 start npm --name hubxglpi-api -- start:api

Rodar apenas o Worker:

pm2 start npm --name hubxglpi-worker -- start:worker

Rodarr API e Worker:

pm2 start ecosystem.config.js --env production

Ver status:
```bash
pm2 status

Logs:

pm2 logs

🧠 Boas Práticas

  • Sempre utilizar o banco intermediário para controle de estado
  • Controllers não devem conter lógica de negócio
  • UseCases não devem conhecer detalhes de infraestrutura

📜 Licença

MIT