1°)Queda na integração dos protocolos do Dunamis:

• Verificar se o serviço do MKR na tela de serviços do windows esta ativo. Caso o usuário que normalmente fica logado no servidor do MKR não tenha privilégios de adm, é necessário configurar o logon do serviço com um que seja.

• Parar o serviço do MKR, abrir 2 cmd como adm e rodar os comando de execução com argumentos obtidos no MKR no botão de argumentos. Pois dessa forma, se houver algum erro local vai gerar um log no próprio cmd.

• Se não houver erros locais, entrar no MCA, aba de broadcast e clicar no botão referente para todas as filas. Depois, conectar na aba de ping e verificar se terá resposta o ping para a fila MAXYSBalanca. Se não tiver, é porque há problema com a fila de comunicação com o maxys. (No geral, verificar com alguém do P&D para corrigir).

OBS: Como a integração do LogTime funciona diretamente com o Dunamis pelos mesmos meios, essas soluções atendem da mesma forma.

2°)Queda no acesso do LogTime, MCA e BC:

• O LogTime funciona em comunicação direta com a BC. Então, se cai um, derruba os dois. Se a base centralizada e o MCA não estiverem acessando no navegador, a primeira coisa a se verificar é se consegue acessar o console do wildfly pelo navegador, usando o ip de acesso da BC ou MCA, trocando a porta para 9990. Se acessar, provável que o Server Group tenha caido apenas. Então, conectar em Runtime>Server Groups, selecionar os grupos em questão que estão off e dar start.
  
  

• Caso o console do wildfly não acesse no navegador, provavelmente é problema no serviço do mesmo no linux. Se for uma empresa cloud, o ideal é acionar alguém do P&D para verificar. Caso seja uma empresa com servidor próprio, verificar o ip de acesso do linux, usuario, senha e acessar via ssh (putty). Depois de logar, tentar subir o serviço do wildfly que deve esta off usando o comando "service wildfly start". Caso só isso não resolva, parar o serviço com o comando "service wildfly stop" e acessar o caminho: "cd /opt/juser/wildfly/domain/servers/ServerProd/". Depois, utilizar os comandos rm -rf log e rm -rf tmp, para deletar as pastas de logs e temporários. Em seguida, acessar a pasta data (cd data) e deletar as seguintes pastas:
  
  
  
  As pastas destacadas na imagem acima devem ser apagadas. As pastas messagingbindings, messagingjournal, messaginglargemessages devem ser mantidas. Após isso, subir novamente o serviço do wildfly. 
  
  OBS: O caminho da pasta do ServerProd pode ser criada com a descrição diferente, então conectar na pasta servers e usar o comando "ls" para verificar todas as pastas que há dentro dele e acessar. Se for necessário obter os logs para verificar a causa da queda, não deletar a pasta log.