Sothis/snglpi
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
v1.2.0
snglpi/docs/casosdeuso.md
Rafael Lopes 35b4a1fef9 FIX/FEATURE: Ajustes de fluxo SN<->GLPI e documentação operacional 
- feito ajuste do fluxo GLPI->SN para tratar status 5 (resolve no SN) e status 6 (aviso definitivo e retirada de monitoramento)
- feito ajuste de reabertura SN->GLPI quando ticket estiver solved no GLPI
- feito ajuste de data/hora de comments/worknotes para evitar inversão de data
- feito ajuste de vínculo Ticket Externo no SN com validação de persistência e retry idempotente
- feito ajuste de filtro de journals para ignorar SOTHIS.CAOA e admin.caoa por configuração
- feito inclusão de monitor dedicado de encerramento definitivo (processGlpiClosureController)
- feito atualização de flags de controle (ENABLE_STATUS_SYNC, ENABLE_GLPI_CLOSE_CRON, ENABLE_GLPI_WEBHOOK)
- feito atualização da documentação (README, docs/regrasdenegocio.md, docs/fluxo.md, docs/casosdeuso.md, docs/checklist.md)
2026-03-04 16:37:04 -03:00

4.8 KiB
Raw Permalink Blame History

Casos de Uso (Formato RPG)

Capitulo 1 - Abertura do chamado

No reino da CAOA, um usuario abre um chamado no ServiceNow. O oraculo da integracao observa o novo registro e grava no banco intermediario. Sem demora, o chamado atravessa o portal SN -> GLPI. No GLPI, o ticket nasce com seu vinculo e recebe seu identificador. De volta ao ServiceNow, o campo "Ticket Externo" e preenchido com o ID GLPI.

Resultado esperado:

  1. Chamado criado no GLPI.
  2. ticket_sync em synced/synced.
  3. Ticket Externo preenchido no SN.

Capitulo 2 - O chamado fora do escopo

Um atendente da Sothis analisa o chamado e percebe: "Problema relacionado a Rede e nao Telefonia".

Ele registra essa justificativa na nota de solucao do GLPI (fora do escopo). A integracao reconhece o tipo de solucao configurado para fora de escopo. Entao envia a justificativa para o ServiceNow como nota. Nao encerra o chamado no SN nesse passo de negocio de fora de escopo. O chamado sai do monitoramento automatico da integracao.

Estado final esperado no banco intermediario:

  1. glpi_sync_status = 'closed'
  2. sn_sync_status = 'ignored'

Interpretacao operacional:

  1. Chamado nao sera mais tratado pela fila automatica da integracao.
  2. Evita retrabalho e loops de sincronizacao.

Capitulo 3 - Encerramento definitivo

Quando um chamado chega ao encerramento definitivo no GLPI (status=6), o cron de fechamento detecta o estado final e executa:

  1. Publica no SN a mensagem:
    • "Chamado encerrado definitivamente. Reabertura deste chamado nao sera atendida. Caso necessario, abra um novo chamado."
  2. Nao altera o status do chamado no SN.
  3. Marca ticket_sync como closed/closed para retirar do monitoramento.

Resultado esperado:

  1. Nao fica chamado fechado no GLPI e aberto no SN.
  2. Nao ocorre tentativa de reabertura automatica para GLPI 6.

Capitulo 4 - Comunicacao entre os reinos (comentarios)

No salao da CAOA (ServiceNow), o usuario escreve: "Equipe Sothis, conseguimos reproduzir o erro as 14h10."

A mensagem atravessa o portal SN -> GLPI e aparece como followup. Do outro lado, no castelo da Sothis (GLPI), o atendente responde: "Recebido. Estamos validando o circuito."

A resposta volta pelo portal GLPI -> SN como comentario. Os escribas da integracao registram origem e destino para evitar duplicidade.

Resultado esperado:

  1. Comentario SN vira followup GLPI.
  2. Followup GLPI vira comentario SN.
  3. Sem mensagens duplicadas no vai-e-volta.

Capitulo 5 - As tarefas e os segredos do reino

No reino da CAOA, toda work_note do SN e uma ordem de batalha. Essas ordens sao enviadas ao GLPI como tarefas visiveis para o time tecnico.

No reino da Sothis, tarefas internas do GLPI sao consideradas secretas. Elas nao atravessam o portal para o SN. Somente followups/comentarios publicos participam da comunicacao entre reinos.

Resultado esperado:

  1. Toda work_note SN vira task GLPI.
  2. Task criada no GLPI nao volta para SN.
  3. O SN recebe somente comentarios/followups do GLPI.

Capitulo 6 - A solucao no reino Sothis (GLPI)

Quando o atendente Sothis conclui o trabalho tecnico no GLPI, ele registra a solucao e coloca o chamado em Solucionado (status=5).

O cron da integracao observa esse estado e realiza:

  1. Busca a nota de solucao do GLPI.
  2. Resolve o chamado correspondente no SN.
  3. Atualiza o estado local para solved/solved.

Se o chamado no SN estiver em estado que bloqueia encerramento (como espera/aguardando), a integracao primeiro ajusta para em atendimento e depois aplica a resolucao.

Resultado esperado:

  1. GLPI solucionado reflete SN resolvido.
  2. A nota de resolucao do GLPI vira base do fechamento no SN.
  3. Chamado continua monitorado ate o encerramento definitivo.

Capitulo 7 - A solucao vinda do reino CAOA (SN)

Quando a CAOA marca o chamado como resolvido no SN, a integracao nao fecha o chamado no GLPI automaticamente.

Em vez disso:

  1. Uma nota informativa e adicionada no GLPI.
  2. O chamado sai do monitoramento automatico de status.

Essa regra evita conflito de fluxo e protege o time tecnico de mudancas de estado inesperadas do outro reino.

Resultado esperado:

  1. GLPI recebe contexto da resolucao do SN.
  2. Nao ocorre fechamento forcado no GLPI por esse evento.
  3. Fluxo fica estavel para evitar reaberturas em cadeia.

Capitulo 8 - Regras de ouro para os guardioes dos dois reinos

  1. Comentario e diplomacia entre reinos: sempre pode cruzar o portal.
  2. Task do SN e ordem operacional para Sothis: cruza para o GLPI.
  3. Task interna do GLPI e sigilo tecnico: nao cruza para SN.
  4. GLPI 5 resolve SN.
  5. GLPI 6 encerra monitoramento e publica aviso definitivo no SN.
  6. Reabertura automatica:
    • permitida se GLPI estiver 5
    • bloqueada se GLPI estiver 6
  7. Fora de escopo:
    • justifica no SN
    • remove do monitoramento
    • estado final closed/ignored.