Pare de descobrir problemas no JD Edwards quando o negócio já foi impactado.

O AlwaysOn é um produto de monitoramento, alertas e automação criado especificamente para ambientes Oracle JD Edwards EnterpriseOne. Ele roda como um cliente desktop somado a um serviço Windows sempre ativo, coleta continuamente dados de infraestrutura, serviços JD Edwards, instâncias gerenciadas WebLogic e bancos de dados, e centraliza status, alertas, histórico e ações operacionais protegidas em cerca de 45 telas.

Ele foi desenhado para cobrir o que o monitoramento genérico de infraestrutura não alcança: a camada JD Edwards. Um monitor de propósito geral informa que a CPU está alta ou que uma porta está aberta. O AlwaysOn avalia kernels jdenet, o batch engine, filas de UBE, o Scheduler JDE, instâncias gerenciadas JAS/AIS/BSSV, blockers e tablespaces no Oracle e logins reais no JD Edwards, e também cobre CPU, memória, disco por ponto de montagem e acessibilidade no nível do host. Se ele substitui ou complementa a sua ferramenta atual depende do seu parque, que é exatamente o tipo de pergunta que um diagnóstico responde.

Serviços do Enterprise Server, com kernels jdenet, batch engine, portas JDE, security server, processos zombie e descontrolados; batch e UBE, com jobs em erro, jobs aguardando, o Scheduler JDE e o histórico do Job Monitor; a camada web, com instâncias gerenciadas WebLogic e WebSphere, JAS, AIS e BSSV, surface tests e web exceptions; bancos de dados Oracle, SQL Server e DB2 for i; o Orchestrator; certificados TLS; e os hosts subjacentes. No total, 51 tipos de alerta distribuídos em 9 famílias de ticket.

Não. O AlwaysOn é agentless por design. Ele se conecta de saída para coletar: SSH para hosts Linux, WMI e WinRM para Windows, as APIs REST do WebLogic e do Server Manager para a camada web, e conexões padrão de banco para Oracle e SQL Server. Enterprise servers em IBM i são lidos através de DB2 for i SQL Services. Nada é instalado nos seus servidores JD Edwards e nada fica para trás.

O AlwaysOn roda dentro da sua rede e alcança o seu parque JD Edwards por SSH, WMI/WinRM, REST e conexões de banco. Onde essas conexões forem permitidas, seja on-premises, em ambientes hospedados em nuvem ou numa combinação dos dois, os coletores funcionam da mesma forma. Caminhos de rede e regras de firewall fazem parte do que um diagnóstico mapeia para a sua topologia específica.

Por meio de sete passos sequenciais. O tipo de alerta precisa estar habilitado para o grupo e a categoria daquele servidor; o valor medido precisa cruzar um threshold definido por grupo; onde se aplica, a condição precisa se manter por N minutos contínuos, então uma única leitura falsa zera a sequência; snooze, regras de pausa, janelas de deploy e de manutenção suprimem o alerta durante eventos planejados; um cooldown mantém o mesmo alerta em silêncio após o envio, enquanto o ticket segue aberto; uma chave de dedup reaproveita o número do ticket existente; e quando a condição volta ao normal o ticket é resolvido automaticamente com um e-mail verde de RESOLVED. Toda avaliação fica registrada de qualquer forma, inclusive o cooldown que segurou um disparo.

O banco local é um store SQLCipher (AES) criptografado, ilegível sem a chave. Toda senha de sistema operacional, banco, serviço, administração e keystore é criptografada e nunca armazenada em texto claro. O acesso exige uma senha de aplicação obrigatória com hash Argon2, com 2FA TOTP opcional ou OTP por e-mail, e cada requisição é protegida por um token de máquina somado a uma sessão humana com tempo limitado. Chaves de host SSH e TLS são fixadas no primeiro uso. As credenciais são mascaradas no servidor antes de qualquer resposta sair da máquina, e o acesso a credenciais fica registrado.

Sim, e de forma explícita. As queries de monitoramento de banco são read-only por padrão; ações de escrita são controladas. A limpeza valida cada caminho, exige confirmação forte e é estruturalmente incapaz de remover o produto. Quando incidentes são encaminhados para uma ferramenta externa de resposta a incidentes, um canal de comando pode enviar instruções de volta, mas apenas depois que seis verificações independentes passarem: lista de remetentes autorizados, token HMAC, encadeamento da mensagem, uma regra pré-autorizadora, vinculação ao alvo e um ID de correlação de uso único. Ações reversíveis podem rodar sozinhas; start, stop e restart sempre aguardam aprovação humana. Cada mudança de configuração e cada escrita em banco deixa uma trilha read-only com o comando e a sua origem.

Sim. Observação e detecção não alteram nada no seu ambiente, e muitas equipes operam nesse nível indefinidamente. As capacidades de automação são configuradas deliberadamente, e as ações de real consequência continuam atrás de aprovação humana mesmo depois de habilitadas.

Relatórios que a sua equipe pode entregar para o negócio. O Health Report traz médias móveis de 7, 15 e 30 dias por servidor, com visão do período completo, status de limpeza e um advisor, exportado como uma página HTML autocontida. O Package Report acompanha projetos de build de package contra o cronograma e envia e-mail quando um deles trava. O Server History gera um retrato imprimível de qualquer escopo em um período. O Job Monitor mostra o histórico de UBE filtrado por job, versão, usuário, ambiente e fila, além do que está rodando agora com CPU ao vivo. O Warning Events registra achados não urgentes sem alertar ninguém. Exportações em HTML e Excel estão disponíveis nas telas que importam.

O AlwaysOn audita o próprio comportamento com treze verificações internas na família AON: SMTP desligado ou falhando silenciosamente, um grupo sem destinatários, uma regra mestre desativada, polling parado, métricas desatualizadas, licença próxima do vencimento, ou um auto-kill que ele não conseguiu confirmar. Esses achados aparecem apenas na tela Always Health, nunca por e-mail, porque uma pendência sobre e-mail não pode depender de e-mail para ser vista.

Sim. Um console HTTPS opcional em porta própria e separada, habilitado durante a instalação e desligado por padrão, enquanto o backend do desktop permanece em loopback no 127.0.0.1. As sessões web são multiusuário e independentes do desktop, então um login no navegador nunca derruba o do desktop. Valem as mesmas regras de login: senha de aplicação com Argon2 mais TOTP ou OTP por e-mail.

Comece por um diagnóstico AlwaysOn. Preencha o formulário nesta página, fale com a equipe NovaCon, pelo e-mail info@novaconweb.com ou pelo telefone +1 (646) 663-8667. Mapeamos a sua topologia JD Edwards, os componentes em escopo e as conexões necessárias, e mostramos o que o AlwaysOn revelaria no seu ambiente específico. O horário de atendimento é de segunda a sexta, das 9h às 18h (EST), e normalmente respondemos em até 24 horas úteis.