Rastreio e criação de log do Rational Connector

O Rational Connector fornece recursos de criação de log e rastreio para muitas de suas principais operações.

Por padrão, a criação de log é ativada e todos os erros que o conector encontra durante sua operação são gravados no arquivo connector.log no diretório Tomcat_directory/logs. A única exceção é blueprintLogger, que grava em seu próprio log, blueprint.log, no mesmo diretório.

O rastreio fornece mais informações sem erro sobre as operações do conector para fins de depuração. Por padrão, o rastreio é desativado. Ele pode ser ativado usando um console JMX. Se o servidor estiver configurado corretamente, qualquer console JMX poderá ser usado para ativar o rastreio. As instruções são para um jconsole, que é um console JMX fornecido com um SDK Java™.

Configuração do servidor

O servidor de aplicativos Tomcat deve estar configurado para aceitar conexões de um console JMX.

  1. Pare o servidor de aplicativos Tomcat.
  2. Para ativar recursos JMX, inclua as linhas a seguir na seção JAVA_OPTS do arquivo catalina.bat do Tomcat, que geralmente está localizado no diretório Tomcat_install_dir/bin.
    Dcom.sun.management.jmxremote
    Dcom.sun.management.jmxremote.port=9004
    Dcom.sun.management.jmxremote.authenticate=false
    Dcom.sun.management.jmxremote.ssl=false

    A primeira linha ativa o login remoto JMX. A segunda linha especifica a porta na qual atender às solicitações do console JMX recebidas. As duas linhas a seguir desativam a autenticação e a criptografia, que podem ser indesejáveis nos ambientes de produção.

  3. Reiniciar o servidor.

Para obter configurações JMX mais avançadas, consulte a documentação do Tomcat em http://Tomcat.apache.org/tomcat-5.5-doc/monitoring.html#Enabling_JMX_Remote

Iniciando o jconsole para Conectar-se ao WebSphere Application Server

Nenhuma mudança nas propriedades da JVM do WebSphere Application Server é necessária para usar o jconsole para conectar-se. No entanto, você deve criar um script de inicialização e um arquivo de propriedades. Este é um exemplo de script de inicialização:

@echo off

set WAS_HOME=C:\PROGRA~2\IBM\SDP\runtimes\base_v7
set HOST=localhost:2809

set PROPS_DIR=c:\temp

:: properties

set PROPS=
set PROPS=%PROPS% -Dcom.ibm.CORBA.ConfigURL=file:/%PROPS_DIR%/sas.client.props
set PROPS=%PROPS% -Djava.naming.provider.url=corbaname:iiop:%HOST%

:: classpath

set CLASSPATH=
set CLASSPATH=%CLASSPATH%;%WAS_HOME%\java\lib\tools.jar
set CLASSPATH=%CLASSPATH%;%WAS_HOME%\runtimes\com.ibm.ws.admin.client_7.0.0.jar
set CLASSPATH=%CLASSPATH%;%WAS_HOME%\runtimes\com.ibm.ws.ejb.thinclient_7.0.0.jar
set CLASSPATH=%CLASSPATH%;%WAS_HOME%\runtimes\com.ibm.ws.orb_7.0.0.jar
set CLASSPATH=%CLASSPATH%;%WAS_HOME%\java\lib\jconsole.jar

:: start jconsole using was jdk

start %WAS_HOME%\java\bin\javaw.exe -classpath %CLASSPATH% %PROPS% sun.tools.jconsole.JConsole service:jmx:iiop://%HOST%/jndi/JMXConnector

O script de exemplo foi escrito como um script Windows .bat. É necessário alterar os valores de WAS_HOME para o caminho 8.3 para o diretório de instalação do WebSphere Application Server e PROPS_DIR para o diretório com o seguinte arquivo de propriedades, denominado sas.client.props:

com.ibm.CORBA.securityEnabled=true

com.ibm.CORBA.authenticationTarget=BasicAuth
com.ibm.CORBA.authenticationRetryEnabled=true
com.ibm.CORBA.authenticationRetryCount=3
com.ibm.CORBA.validateBasicAuth=true
com.ibm.CORBA.securityServerHost=
com.ibm.CORBA.securityServerPort=
com.ibm.CORBA.loginTimeout=300
com.ibm.CORBA.loginSource=prompt

com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=

com.ibm.CORBA.krb5ConfigFile=
com.ibm.CORBA.krb5CcacheFile=

com.ibm.CSI.performStateful=true

com.ibm.CSI.performClientAuthenticationRequired=false
com.ibm.CSI.performClientAuthenticationSupported=true

# tudo falso a partir daqui

com.ibm.CSI.performTLClientAuthenticationRequired=false
com.ibm.CSI.performTLClientAuthenticationSupported=false

com.ibm.CSI.performTransportAssocSSLTLSRequired=false
com.ibm.CSI.performTransportAssocSSLTLSSupported=false

com.ibm.CSI.performMessageIntegrityRequired=false
com.ibm.CSI.performMessageIntegritySupported=false

com.ibm.CSI.performMessageConfidentialityRequired=false
com.ibm.CSI.performMessageConfidentialitySupported=false

# não necessário
#com.ibm.ssl.alias=DefaultSSLSettings

com.ibm.CORBA.requestTimeout=180

Configuração da conexão do cliente

  1. Com o servidor configurado corretamente, inicie o jconsole. A localização padrão é java_home>\bin\jconsole.exe
  2. Na guia Remoto, insira o nome do host ou o IP do seu servidor e o número da porta (por exemplo, 9004) e clique em Connect.
  3. Na guia MBeans, expanda a pasta log4j. Você verá uma lista de todos os componentes log4j em uso pelo servidor de aplicativos. Qualquer nome do criador de logs que comece com com.ibm.rational.connector.sap pertence ao Rational Connector.
  4. O conector usa uma convenção de nomenclatura de com.ibm.rational.connector.sap.*Logger e com.ibm.rational.connector.sap.*Tracer, em que o asterisco * indica o componente específico do conector que é controlado pelo criador de logs ou pelo rastreador.
  5. Clique no rastreador no qual você está interessado. Para ativar o rastreio para o criador de logs selecionado, no campo de prioridade, exclua o texto INFO padrão e digite TRACE.

    Por padrão, os rastreadores são configurados com um nível INFO, que é uma prioridade baixa no log4j. Um nível de rastreio de INFO significa que as instruções de rastreio dentro dos conectores não são gravadas no arquivo connectorTrace.log.

  6. Repita a etapa 5 para todos os outros rastreadores do seu interesse. As alterações entrarão em vigor imediatamente e não necessitam da reinicialização de servidor.
A seguinte é uma lista completa de componentes dos criadores de logs e do rastreador e seus recursos.
  • blueprint - Útil quando você envia um blueprint do Solution Manager. O Criador de Logs de blueprint grava no blueprint.log.
  • certs - Útil quando você tem problemas com certificados.
  • connector - Manipulação de mensagens gerais do connector. Este rastreador deve ser ativado juntamente com outros componentes quando você avalia um problema.
  • cq - Útil para depurar erros entre o conector e o ClearQuest.
  • reqPro - Útil para depurar erros entre o conector e o Rational RequisitePro.
  • rqm - Útil para depurar erros entre o conector e o Rational Quality Manager.
  • rrc - Útil para depurar erros entre o conector e o Rational Requirements Composer.
  • sdAdapter - útil para depurar erros entre a central de serviço e o conector.
  • serviceDesk - útil para depurar erros entre a central de serviço e o conector.
  • testData - Útil para depurar operações em nível de projeto, como associação, desassociação e reassociação entre o Connector e o gerenciador de soluções.
  • testresult - Útil para investigar problemas com resultados de teste que não são exibidos no Solution Manager.

Usar a combinação de vários rastreadores muitas vezes produz melhores resultados. Quando você investigar problemas, certifique-se de que o rastreador do conector esteja ativado. Ao investigar problemas entre o Rational ClearQuest e o Service Desk, ative os rastreadores cq, sdAdapter e serviceDesk. Quando você fizer um envio de blueprint, ative os servidores Rational, como rqm e reqPro, além do rastreador de blueprint.


Feedback