Pular para conteúdo

C3 — KAPSCH / SISFREFLOW

Zoom dentro do Container Staging KAPSCH (extractor do hub no C2) e do Projetor SISFREFLOW (que lê do schema KAPSCH em BANCO STAGE e escreve o Read Model SISFREFLOW em BANCO ARTESP). Mostra os componentes lógicos que ingestam dados do KAPSCH on-prem para o hub e os transformam na visão de produto SISFREFLOW.

Estado: hipotético. Ficha de Discovery ainda não iniciada — ver tpf-motiva/docs/0-discovery/01-kapsch.md no repositório. Componentes e contratos abaixo refletem o melhor entendimento atual a partir de Fornecedores §3.1 e do produto/blueprint-solucao.md. Marcadores de confiança nas afirmações.

Contexto rápido

  • Ferramenta: KAPSCH (sistema operacional crítico de arrecadação eletrônica)
  • Sistema ARTESP: SISFREFLOW
  • Onda: 1 — deadline jul/2026 (urgente)
  • Padrão arquitetural (C2): Pull-On-Prem [B]
  • C/P/B: Producer [B] (gera eventos de passagem)
  • Hosted: On-prem Motiva, intranet-only [B]

Diagrama

Diagrama a fazer

O Projetor SISFREFLOW (que consumiria o schema KAPSCH em BANCO STAGE para gerar o Read Model SISFREFLOW em BANCO ARTESP) ainda não foi modelado nesta versão. Será adicionado quando D3 do blueprint (modelo de dados canônico) e a Discovery 01 (contrato de dados KAPSCH) destravarem.

Componentes do Container Staging KAPSCH

# Componente Tecnologia (hipótese) Responsabilidade
1 Extrator de eventos Python ou .NET, executado como job pelo SINCRONIZADOR Pull periódico de eventos da API/DB KAPSCH. Mantém checkpoint (offset/timestamp) para evitar perda. Reprocessável. [B]
2 Normalizador (mínimo) Mesma stack Resolve km/sentido/faixa via lookup geo. Sem regra de negócio — só normalização técnica para o dado caber no schema as-is. [B]
3 LGPD scrubber Função utilitária Trata placa de veículo (dado pessoal) na escrita em Staging. Hash determinístico, tokenização ou descarte — política pendente com Cyber (D1 do blueprint). [?]
4 Publisher Staging Driver Oracle Upsert (insert/update) na tabela do schema KAPSCH em BANCO STAGE. Idempotente por id_evento. [B]

Projetor SISFREFLOW

Lê de BANCO STAGE.KAPSCH.passagens_raw, aplica regras de produto SISFREFLOW (agregações por pórtico/janela, classificações, indicadores), persiste o Read Model em BANCO ARTESP. Executado pelo SINCRONIZADOR conforme dependências (provavelmente em janela horária — confirmar com Discovery).

Aspecto Decisão atual
Tecnologia a definir — mesma stack do extractor é plausível, ou Oracle PL/SQL para transformações pesadas. [?]
Cadência dispara após cada batch consolidado de Staging KAPSCH. Janela exata depende de latência aceitável (D-K2). [?]
Idempotência Read Model é reescrito por janela; reprocessar é seguro. [B]

Contrato de dados em Staging (entidade-chave: PassagemFreeFlow — as-is)

Schema hipotético em BANCO STAGE.KAPSCH.passagens_raw — a confirmar na Discovery e com Cyber/InfoSec.

Campo Tipo Origem Notas
id_evento string KAPSCH Chave única; usada no upsert
timestamp datetime UTC KAPSCH Momento da passagem
id_portico string KAPSCH Identificador do pórtico
km decimal resolver no normalizador Lookup geo a partir de id_portico
sentido enum (norte, sul, leste, oeste) KAPSCH ou derivado A confirmar fonte
faixa int KAPSCH Número da faixa no pórtico
id_veiculo string (TAG) KAPSCH Pode ser nulo se não-TAG
placa_hash string LGPD scrubber Placa hasheada — original não persiste [?]
classe_tarifaria enum KAPSCH Categoria por eixos/altura
valor_cobrado decimal KAPSCH BRL
status_pagamento enum KAPSCH Pago / pendente / isento
lat / lon float resolver no normalizador Geometria do pórtico — útil para o Read Model

O Read Model SISFREFLOW em BANCO ARTESP é derivado: estrutura por produto, com agregações, classificações e campos calculados — a desenhar com Design Authority (D3 do blueprint).

Decisões pendentes (entrar em pauta na entrevista KAPSCH)

# Pergunta Confidence atual Onde resolver
D-K1 KAPSCH expõe API REST ou apenas DB direto? [?] §2.4 do roteiro-base
D-K2 Latência aceitável: tempo real, hora ou dia? [?] §2.7
D-K3 Volume estimado de passagens/dia? [?] §2.7
D-K4 Política LGPD da placa (D1 blueprint): hash determinístico, tokenização ou descarte? [?] §2.9 + Cyber
D-K5 O Container Staging KAPSCH roda em rede com acesso direto ao KAPSCH, ou em rede Motiva separada com VPN/VLAN? [?] §2.3 + InfoSec
D-K6 Quem é o owner técnico KAPSCH do lado da Motiva? (D7 blueprint) [?] §2.2

Decisões transversais aplicáveis: D1 (LGPD placa), D2 (Oracle DB confirmado?), D3 (Read Model SISFREFLOW), D12 (tecnologia SINCRONIZADOR) — ver Apêndice D do blueprint.

Riscos críticos

  • Onda 1, deadline jul/2026 (~12 semanas) — Discovery + setup do Container Staging + Projetor + aprovação Cyber/InfoSec é caminho crítico. Atraso de ~2 semanas em qualquer aprovação compromete o prazo.
  • LGPD da placa de veículo (D1) — sem política definida, qualquer arquitetura fica em rascunho.
  • Hipóteses não testadas — quase tudo abaixo de [M]. Risco de retrabalho se a entrevista revelar arquitetura diferente (ex.: KAPSCH expõe webhooks → Extrator vira Listener; ou KAPSCH é DB-only sem API → Extrator vira leitor SQL).

Referências