O roteamento de exceções define como transações não conciliadas são classificadas, atribuídas e escaladas. Este guia descreve classificação de severidade, regras de atribuição, rastreamento de SLA e integrações com sistemas externos de workflow.Documentation Index
Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
Use this file to discover all available pages before exploring further.
Classificação de severidade
Exceções são automaticamente classificadas por severidade para priorizar revisão e resolução.
Regras de severidade padrão
| Severidade | Critério padrão | SLA |
|---|---|---|
| Critical | Valor ≥ 100.000 OU idade ≥ 120 horas | 24 horas |
| High | Valor ≥ 10.000 OU idade ≥ 72 horas | 72 horas |
| Medium | Valor ≥ 1.000 OU idade ≥ 24 horas | 120 horas (5 dias) |
| Low | Todos os outros casos | 168 horas (7 dias) |
Roteamento de atribuição
O roteamento de atribuição garante que exceções cheguem às equipes apropriadas automaticamente.
Grupos de usuários
Grupos de usuários permitem estratégias de atribuição escaláveis e resilientes.Os métodos automáticos de atribuição de grupos de usuários (round_robin, least_loaded, random, all) estão planejados mas ainda não implementados. Atualmente, as exceções podem ser atribuídas a usuários ou grupos individuais manualmente via API de atribuição.
Rastreamento de SLA
O rastreamento de SLA monitora o envelhecimento de exceções e dispara avisos ou escalonamentos quando os limites são atingidos.
Endpoints adicionais de exceções
Além do CRUD básico de exceções, o Matcher fornece endpoints para workflows avançados de exceções:
| Endpoint | Método | Descrição |
|---|---|---|
| Despachar exceção | POST | Enviar uma exceção para um sistema ou equipe externa |
| Processar callback | POST | Receber callbacks de resolução de sistemas externos |
| Atribuição em lote | POST | Atribuir múltiplas exceções a um usuário ou grupo de uma vez |
| Resolução em lote | POST | Resolver múltiplas exceções em uma única operação |
| Despacho em lote | POST | Despachar múltiplas exceções para sistemas externos |
| Listar comentários | GET | Recuperar todos os comentários de uma exceção |
| Adicionar comentário | POST | Adicionar um comentário para auditoria e colaboração |
| Excluir comentário | DELETE | Remover um comentário de uma exceção |
| Listar disputas | GET | Recuperar todas as disputas com filtros |
| Obter disputa | GET | Recuperar detalhes de uma disputa específica |
| Abrir disputa | POST | Sinalizar uma exceção como disputada para revisão escalada |
| Fechar disputa | POST | Fechar uma disputa com uma resolução |
| Enviar evidência | POST | Adicionar evidência para fundamentar uma disputa |
Integrações
O Matcher se integra com sistemas externos para suportar workflows operacionais.
- JIRA: Use o JIRA para rastrear e resolver exceções como issues.
- Webhooks: Envie eventos de exceção para sistemas customizados em tempo real.
- Autenticação segura
- Retry e backoff
- Atualizações de status bidirecionais (quando habilitadas)
Destinos de despacho
Ao despachar uma exceção, o campotarget_system deve ser um dos seguintes valores:
| Destino | Descrição |
|---|---|
JIRA | Despachar para um projeto JIRA |
SERVICENOW | Despachar para ServiceNow (ainda não implementado — retorna MTCH-0508) |
WEBHOOK | Despachar para um endpoint de webhook personalizado |
MANUAL | Sinalizar para tratamento manual fora de sistemas automatizados |
Filtrando por sistema externo
Ao listar exceções, o parâmetro de consultaexternal_system aceita qualquer valor de string para filtragem. Isso permite filtrar exceções despachadas para qualquer sistema, incluindo identificadores customizados que podem ter sido definidos através de callbacks.
Tratamento de erros de despacho
Ao despachar uma exceção para um sistema externo, o Matcher retorna respostas de erro específicas:| Código de Status | Condição | Descrição |
|---|---|---|
| 200 | Sucesso | Exceção despachada e issue externa criada |
| 400 | Requisição inválida | Campos obrigatórios ausentes (ID da exceção, sistema de destino ou ator) |
| 422 | Sistema de destino não suportado | O valor do sistema de destino não é um dos destinos de despacho suportados listados acima |
| 422 | Conector não configurado | O sistema de destino é válido, mas não possui configuração de conector. Verifique se a integração está configurada antes de despachar. |
| 422 | Transição de estado inválida | A exceção não está em um estado despachável |
Monitoramento e analytics
Use estatísticas de roteamento para avaliar a efetividade:
- Volume de exceções por severidade
- Taxas de violação de SLA
- Distribuição de regras de roteamento
- Taxas de sucesso e falha de integrações
Boas práticas
Comece simples
Comece simples
Comece com roteamento baseado em severidade e expanda conforme padrões emergem.
Prefira grupos a indivíduos
Prefira grupos a indivíduos
Roteamento baseado em grupos melhora resiliência e balanceamento de carga de trabalho.
Defina SLAs realistas
Defina SLAs realistas
Alinhe metas de SLA com capacidade operacional.
Monitore tendências de SLA
Monitore tendências de SLA
Violações frequentes indicam limites desalinhados ou gaps de equipe.
Valide integrações antes de produção
Valide integrações antes de produção
Sempre teste integrações JIRA e webhook em ambientes de não-produção.
Planeje para falhas de webhook
Planeje para falhas de webhook
Configure retries e alertas para caminhos de notificação críticos.
Próximos passos
Resolvendo exceções
Resolva exceções através da API ou sistemas externos.
Webhooks e callbacks
Entrega avançada de eventos e tratamento de callbacks.