GBR: Requisitos de Telemetria e Operações Híbridas (BPM + Túneis) | Wiki
GBR: Requisitos de Telemetria e Operações Híbridas (BPM + Túneis)
*Requisitos Ubíquos (Ubiquitous Requirements)*
- *UBQ-01:* O sistema (falconctl) deve distribuir-se como um binário monolítico auto-contido, com capacidade total de operação silenciosa (Background Daemon) para processar telemetria ou provisionar suporte remoto.
- *UBQ-02:* A interface de telemetria do Gateway (Wisp/HTTP ou Yamux/P2P) não deve executar validações de regras de negócios ou lógicas de alertas no momento da ingestão; seu comportamento estrito é decodificar, tipar e injetar no motor de despacho O(1) do ETS.
*Requisitos Orientados a Eventos (Event-Driven Requirements)*
- *EVD-01:* Quando a Máquina BPE transacionar um Token que afete o armazenamento (Ex: estado persistente ativado), o motor deve acionar de forma síncrona a interface injetada BpeStorage.save_token, convertendo nativamente (zero-cost) a variável em memória num artefato disco/Mnesia.
- *EVD-02:* Quando o BPE avaliar uma expressão da telemetria identificando a necessidade formal de conexão de suporte, ele deverá instanciar ativamente o evento colateral lógico OpenReverseTunnel com base nas propriedades do Alvo avaliado.
*Requisitos Orientados a Estado (State-Driven Requirements)*
- *STD-01:* Enquanto o falconctl estiver executando em modo tunnel open na borda de um cliente corporativo, a BEAM deve monitorar e impor um limite incondicional de autodestruição do túnel de conexão de 3.600.000 ms (1 hora) como um seguro criptográfico infalível (Kill-Switch).
- *STD-02:* Enquanto a infraestrutura Gateway estiver operando sobre cargas intensivas de reconexão de clientes na malha P2P ("Thundering Herd Problem"), o servidor deverá manter os identificadores das sessões Yamux instanciadas nativamente no ETS configurados com alta concorrência (ReadConcurrency(True) / WriteConcurrency(True)), abolindo Atores em fila (Registries via Dict).
*Requisitos de Comportamento Indesejado (Unwanted Behavior Requirements)*
- *UNW-01:* Se o cliente falconctl interromper um Túnel de Conexão devido ao teto do Kill-Switch ou encerramento manual e existirem execuções subjacentes nas pontas de dados do cliente (ex: Driver JDBC Java rodando na porta remota), a comunicação Inter-Processos deverá transmitir um payload JSON ({"command": "cancel_execution"}) para exigir que a ferramenta efetue rotinas de liberação síncronas de trava de banco de dados (Statement.cancel()).
- *UNW-02:* Se a integração da decodificação HTTP via Wisp (gleam/dynamic/decode) receber dados malformados na interface Norte-Sul que deturpariam o formato esperado TelemetryEvent (incluindo falhas estritas em inteiros mascarados por floats no JSON vindo de plataformas Microsoft/Windows), a camada não deve abortar o serviço e sim descartar silenciosamente a mensagem maliciosa/inválida.
*Requisitos de Funcionalidades Opcionais / Futuras (Optional Feature Requirements)*
- *OPT-01:* Onde o cliente administrador prover especificações criadas através do frontend BPMN do Camunda (bpmn.js), a aplicação deverá utilizar parsers de XML via API de Streaming SAX nativos ao Erlang (xmerl_sax_parser ou erlsom) para decodificá-las eficientemente em um objeto ProcessDef, evitando sobrecarga de consumo de RAM.