Serviço de Conexão de Teste

Verificando as Configurações de Escopo

Associar as variáveis do WebSphere com suas configurações de origem de dados pode elencar resultados de conexão de teste que são incongruentes com o comportamento de tempo de execução de sua aplicação. Em alguns casos, uma operação de conexão de teste falha, mas a origem de dados física funciona normalmente durante o tempo de execução do aplicativo. A causa do conflito potencial é a diferença entre como o seu servidor de aplicativos manipula as configurações de escopo de variáveis do WebSphere em tempo de execução e como ele manipula essas mesmas configurações de escopo para uma operação de conexão de teste. Entender a diferença ajuda a criar configurações bem-sucedidas da origem de dados.

No entanto, o Application Server testa as conexões apenas em um escopo; ele executa a operação de teste na JVM do mesmo escopo daquele da configuração da origem de dados. O produto tenta resolver a variável de caminho de classe do driver apenas nesse escopo.

Tabela 1. Correlação de escopo de origem de dados com a JVM de conexão de teste . A correlação do escopo da origem de dados Célula, Cluster e Servidor com a JVM de conexão de teste correspondente onde a operação ocorre.

Escopo da Origem de Dados	JVM em que ocorre a operação de conexão de teste
Célula	processo do gerenciador
Nó	Processo do agente de nó (do nó relevante)
Cluster	Agente do nó para cada nó que contém um membro de cluster
Servidor	Servidor; se o servidor não estiver disponível, a operação de conexão de teste será tentada novamente no agente do nó que contém o servidor de aplicativos.

Restriction: Em uma implementação de implementação de rede do servidor de aplicativos, não é possível testar conexões para as seguintes fontes de dados no nível do nó ou nível de cluster. Portanto, ao criar essas origens de dados no escopo do nó ou no escopo do cluster, você pode querer criar temporariamente as mesmas configurações no escopo do servidor para fins de teste. Execute a operação de conexão de teste no nível do servidor para determinar se as configurações da origem de dados são válidas para sua configuração geral.

• Origem de dados do IBM Data Server Driver para JDBC e SQLJ com driver do tipo 2
• Origem de dados Provedor de DB2 Universal JDBC Driver com o driver tipo 2

É possível criar configurações no nível do nó ou no nível do cluster das origens de dados para uso do aplicativo; essas configurações funcionam adequadamente no tempo de execução. Para executar com êxito a conexão de teste nas origens de dados, no entanto, você deverá testar as origens de dados apenas no nível do servidor. O servidor de aplicativos emitirá a seguinte exceção para uma conexão de teste no nível do nó:

java.sql.SQLException: Falha no carregamento do T2 biblioteca nativa db2jcct2DSRA0010E:
 Estado SQL = null, Código de Erro = -99.999

Em alguns casos, porém, o erro pode ser semelhante a uma das mensagens a seguir:

T2zOS exception: [jcc][T2zos]T2zosReusableConnection.flowConnect:initRRSAFAttach
:2528: Connection dead

Falha no carregamento da biblioteca nativa db2jcct2zos4_64,                       
java.lang.UnsatisfiedLinkError: db2jcct2zos4_64 (Não localizado em            
java.library.path):  ERRORCODE=-4472, SQLSTATE=null DSRA0010E: SQL State 
= null, Error Code = -4,472. 

As duas origens de dados têm como base os drivers JDBC do tipo 2, que precisam acessar as bibliotecas nativas T2. O ambiente de tempo de execução para o servidor de aplicativos fornece esse acesso às origens de dados em um processo do servidor, porém o serviço de conexão de teste não fornece acesso a esses arquivos nativos quando ele for executado no processo do agente do nó.

Portanto, ao criar essas origens de dados no escopo do nó ou no escopo do cluster, você pode querer criar temporariamente as mesmas configurações no escopo do servidor para fins de teste. Execute a operação de conexão de teste no nível do servidor para determinar se as configurações da origem de dados são válidas para sua configuração geral.

Se o escopo da variável WebSphere for menor do que o da fonte de dados, a operação de conexão de teste falha. A tabela a seguir mostra os cenários que produzem essa falha e também os que produzem o sucesso.

Contrário às expectativas, essas falhas de conexão de teste geralmente não se convertem em falhas de tempo de execução. Certifica-se de que o local de seus arquivos do driver JDBC esteja acessível a cada cliente que deve usar a fonte de dados, e configure sua variável WebSphere com o caminho completo desse local.

Conexão de teste com sucesso, mas falha no tempo de execução

Porém, uma das combinações de escopo listadas na Tabela 2 pode produzir o cenário reverso: a operação de conexão de teste é bem-sucedida, mas a origem de dados falha no tempo de execução. Esta anomalia ocorre no caso de uma fonte de dados com escopo de célula que usa uma variável do WebSphere com escopo de célula. O teste de conexão é bem-sucedido porque a operação ocorre no processo do gerenciador de implementação (conforme indicado na Tabela 1), em que o Application Server pode resolver a variável com escopo de célula. Essa origem de dados pode falhar no tempo de execução porque a variável com escopo de célula pode ser substituída por um valor nulo.

Quando você cria um nó, o Application Server cria variáveis de ambiente para todos os drivers JDBC suportados no escopo do nó e inicializa cada variável com uma cadeia vazia. Como um servidor de aplicativo tenta resolver variáveis do low end do espectro do escopo até o high end, a variável do escopo do nó substitui a variável do escopo da célula no tempo de execução. O servidor lê a cadeia vazia e a aceita como o caminho de classe do driver JDBC. O caminho de classe nulo leva a uma exceção classNotFound quando o servidor tenta utilizar a origem de dados.

Utilizando qualquer uma das opções administrativas do Application Server, você pode evitar que uma cadeia vazia se torne o valor final para a variável de caminho de classe do driver.

• Usando o console administrativo WebSphere Application Server : O programa do assistente de origem de dados copia o valor da variável de escopo celular (que você especifica no assistente de criação do provedor JDBC ) para a variável de escopo do nó de mesmo nome. O programa do assistente executará esta operação de cópia apenas se a variável com escopo de nó tiver o valor de cadeia vazia; assim, o programa não altera um caminho de classe válido especificado anteriormente.
  Para garantir que a origem de dados funcione com a variável com escopo de nó no tempo de execução, siga estas etapas:

  1. Instale os arquivos do driver JDBC no nó do gerenciador de implementação e também em cada nó em que a origem de dados deve funcionar.
  2. Use o caminho de arquivo do driver no gerenciador de implementação para definir a variável WebSphere para um provedor JDBC no escopo do celular.
  3. Certifique-se de que a origem de dados esteja associada ao provedor JDBC do gerenciador de implementação e tenha o mesmo escopo da célula.
     Importante: Garantir o sucesso instalando os arquivos do driver em locais com nomes de full-path idênticos em todos os nós, incluindo o nó do gerenciador de implementação. Caso contrário, é provável que ocorra novamente o mesmo cenário de sucesso da conexão de teste, mas de falha no tempo de execução.
• Usando a ferramenta de script wsadmin: Para fazer com que a origem de dados funcione para a operação de conexão de teste e para o tempo de execução, crie as mesmas configurações de caminho de classe do driver no escopo da célula e em todos os escopos de nós relevantes. Execute as etapas a seguir:
  1. Instale os arquivos do driver JDBC no nó do gerenciador de implementação; utilize esse nome do caminho para definir a variável de caminho de classe do driver para um provedor JDBC no escopo da célula.
  2. Certifique-se de que a origem de dados esteja associada ao provedor JDBC do gerenciador de implementação e tenha o mesmo escopo da célula.
  3. Em cada nó onde a fonte de dados deve funcionar, instale os arquivos do driver JDBC e use o caminho para definir a variável WebSphere para um provedor JDBC no escopo do nó. Cada um desses provedores deve ter a mesma configuração.
     Importante: Garantir o sucesso instalando os arquivos do driver em locais com nomes de full-path idênticos em todos os nós, incluindo o nó do gerenciador de implementação. Caso contrário, é provável que ocorra novamente o mesmo cenário de sucesso da conexão de teste, mas de falha no tempo de execução.

Utilize os recursos do escopo da célula apenas se todos os nós que precisam de acesso para a origem de dados, incluindo o nó do gerenciador de implementação, forem executados na mesma plataforma e tiverem os drivers JDBC instalados no mesmo local. Caso contrário, utilize o escopo do nó como a configuração do escopo maior para as origens de dados.

Ignorando Consultas de Variáveis

É possível ignorar as consultas de variáveis de ambiente alterando as entradas do caminho de classe do provedor JDBC para valores com hardcode designado. No entanto, essa estratégia será bem-sucedida apenas se o caminho de classe for configurado de forma idêntica em todos os nós em que a origem de dados tiver que funcionar.

Ativando o Serviço de Conexão de Teste

Existem três maneiras de ativar o serviço de conexão de teste: através do console administrativo, da ferramenta wsadmin, ou um programa independente Java. Cada processo chama os mesmos métodos no mesmo MBean.

Console administrativo

WebSphere Application Server permite testar uma conexão a partir do console administrativo simplesmente empurrando um botão: a Coleta de origem de dados, Configurações de origem de dados, Versão 4 fonte de dadose Configurações de origem de dados da Versão 4 todos possuem os botões Conexão de Teste . Após definir e salvar uma origem de dados, é possível clicar nesse botão para assegurar que os parâmetros na definição de origem de dados estejam corretos. Na página da coleção, é possível selecionar várias origens de dados e testá-las todas de uma vez. Observe que há certas condições que devem ser satisfeitas primeiro. Para obter informações adicionais, consulte o tópico, Testando uma conexão com o console administrativo.

A conexão de teste falhou para a origem de dados isagent no servidor server1 no nó 
svtaix24Node01 com a seguinte exceção: java.lang.Exception: 
java.sql.SQLException: JZ006: Caught IOException: java.net.ConnectException: Um 
host remoto recusou uma operação de conexão tentada.DSRA0010E: SQL State = JZ006, 
Código de Erro = 0

Ferramenta WsAdmin

A ferramenta wsadmin fornece uma interface de script para uma gama completa de atividades de administração do WebSphere Application Server . Como a funcionalidade Testar Conexão é implementada como um método em um MBean e wsadmin pode chamar métodos MBean, wsadmin pode ser utilizada para testar conexões para origens de dados. Você possui duas opções para testar uma conexão de origem de dados por meio de wsadmin:

O objeto AdminControl de wsadmin tem uma operação testConnection que testa as propriedades de configuração de um objeto de origem de dados. Para obter informações, consulte o tópico, Testando uma conexão usando o wsadmin.

É possível também testar uma conexão chamando a operação MBean. Use o exemplo no tópico, Exemplo: Testando conexão de origem de dados usando wsadmin, como um guia para esta técnica.

Programa Independente Java

Finalmente, é possível testar uma conexão executando o método testConnection no MBean DataSourceCfgHelper. Esse método permite transmitir o ID de configuração da origem de dados configurada. O programa Java se conecta a um servidor Java Management Extensions (JMX) em execução para acessar o MBean. Em uma instalação do WebSphere Application Server Network Deployment do Application Server, você conecta-se ao servidor JMX em execução no gerenciador de implementação, geralmente rodando na porta 8879.

O valor de retorno dessa chamada é 0, um número positivo ou uma exceção. 0 indica que a operação concluiu com êxito, sem avisos. Um número positivo indica que a operação concluiu com êxito, com o número de avisos. Uma exceção indica que o teste da conexão falhou.

O código de amostra a seguir cria uma instância da origem de dados e uma instância da conexão associada, além de testá-las para assegurar a conectividade do banco de dados.

Este programa utiliza JMX para se conectar a um servidor em execução e chamar o método testConnection no MBean DataSourceCfgHelper. O acrônimo ND em uma linha de comentários indica que o código a seguir se aplica ao WebSphere Application Server WebSphere Application Server Network Deployment. A palavra Base em uma linha de comentários indica que o código a seguir se aplica ao WebSphere Application Server.

/**
 * Description
 * Resource adapter test program to make sure that the MBean interfaces work.
 * Following interfaces are tested
 * 
 *  ---  testConnection()
 * 
 * 
 * We need following to run
 * C:\src>java -Djava.ext.dirs=C:\WebSphere\AppServer\lib;C:\WebSphere\AppServer\java\jre\lib\ext testDSGUI
 * must include jre for log.jar and mail.jar, else get class not found exception
 * 
 * 
 */

import java.util.Iterator;
import java.util.Locale;
import java.util.Properties;
import java.util.Set;

import javax.management.InstanceNotFoundException;
import javax.management.MBeanException;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.RuntimeMBeanException;
import javax.management.RuntimeOperationsException;

import com.ibm.websphere.management.AdminClient;
import com.ibm.websphere.management.AdminClientFactory;
import com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException;

public class testDSGUI {

//Use port 8880 for a Base installation or port 8879 for ND installation
String port = "8880";
// String port = "8879";
String host = "localhost";
final static boolean verbose = true;

// eg a configuration ID for DataSource declared at the node level for Base
private static final String resURI = "cells/cat/nodes/cat|resources.xml#DataSource_1";

// eg a 4.0 DataSource declared at the node level for Base
//    private static final String resURI = "cells/cat/nodes/cat|resources.xml#WAS40DataSource_1";

// eg Apache Derby DataSource declared at the server level for Base
//private static final String resURI = "cells/cat/nodes/cat/servers/server1/resources.xml#DataSource_6";

// eg node level DataSource for ND
//private static final String resURI = "cells/catNetwork/nodes/cat|resources.xml#DataSource_1";

// eg server level DataSource for ND
//private static final String resURI = "cells/catNetwork/nodes/cat/servers/server1|resources.xml#DataSource_4";

// eg cell level DataSource for ND
//private static final String resURI = "cells/catNetwork|resources.xml#DataSource_1";

 public static void main(String[] args) {
  testDSGUI cds = new testDSGUI();
  cds.run(args);
 }

/**
 * This method tests the ResourceMbean.
 * 
 * @param args
 * @exception Exception
 */
 public void run(String[] args) {

  try {

	System.out.println("Connecting to the application server.......");

        /*************************************************************************/
        /**    Initialize the AdminClient                                        */
        /*************************************************************************/	
	Properties adminProps = new Properties();
	adminProps.setProperty(AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP);
	adminProps.setProperty(AdminClient.CONNECTOR_HOST, host);
	adminProps.setProperty(AdminClient.CONNECTOR_PORT, port);
	AdminClient adminClient = null;
	try {
	    adminClient = AdminClientFactory.createAdminClient(adminProps);
	} catch (com.ibm.websphere.management.exception.ConnectorException ce) {
  	    System.out.println("NLS: Cannot make a connection to the application server\n");
	    ce.printStackTrace();
	    System.exit(1);
	}

       /*************************************************************************/
       /**    Locate the Mbean                                                  */
       /*************************************************************************/
	ObjectName handle = null;
	try {
                // Send in a locator string 
                // eg for a Base installation this is enough
                ObjectName queryName = new ObjectName("WebSphere:type=DataSourceCfgHelper,*");

                // for ND you need to specify which node/process you would like to test from
                // eg run in the server
//ND: ObjectName queryName = new OjectName
				("WebSphere:cell=catNetwork,node=cat,process=server1,type=DataSourceCfgHelper,*");
                // eg run in the node agent
//ND: ObjectName queryName = new ObjectName
				("WebSphere:cell=catNetwork,node=cat,process=nodeagent,type=DataSourceCfgHelper,*");
//ND: eg run in the   Manager
//ND: ObjectName queryName = new ObjectName
			("WebSphere:cell=catNetwork,node=catManager,process=dmgr,type=DataSourceCfgHelper,*");
	Set s = adminClient.queryNames(queryName, null);
	Iterator iter = s.iterator();
	while (iter.hasNext()) {
                // use the first MBean that is found
	 	handle = (ObjectName) iter.next();
		System.out.println("Found this ->" + handle);
		}
		if (handle == null) {
			System.out.println("NLS: Did not find this MBean>>" + queryName);
			System.exit(1);
		}
	} catch (MalformedObjectNameException mone) {
		System.out.println("Check the program variable queryName" + mone);
	} catch (com.ibm.websphere.management.exception.ConnectorException ce) {
		System.out.println("Cannot connect to the application server" + ce);
	}

         /*************************************************************************/
         /**           Build parameters to pass to Mbean                          */
         /*************************************************************************/
	String[] signature = { "java.lang.String" };
	Object[] params = { resURI };
	Object result = null;

       	if (verbose) {
		System.out.println("\nTesting connection to the database using" + handle);
	}

	try {
               /*************************************************************************/
               /**  Start to test the connection to the database                        */
               /*************************************************************************/
		result = adminClient.invoke(handle, "testConnection", params, signature);
	} catch (MBeanException mbe) {
		// ****** all user exceptions come in here
		if (verbose) {
			Exception ex = mbe.getTargetException(); // this is the real exception from the Mbean
			System.out.println("\nNLS:Mbean Exception was received contains" + ex);
			ex.printStackTrace();
			System.exit(1);
		}
	} catch (InstanceNotFoundException infe) {
		System.out.println("Cannot find" + infe);
	} catch (RuntimeMBeanException rme) {
		Exception ex = rme.getTargetException();
		ex.printStackTrace(System.out);
		throw ex;
	} catch (Exception ex) {
		System.out.println("\nUnexpected Exception occurred:" + ex);
		ex.printStackTrace();
	}

         /*************************************************************************/
         /**  Process the result.  The result will be the number of warnings      */
         /**  issued.  A result of 0 indicates a successful connection with       */
         /**  no warnings.                                                        */
         /*************************************************************************/

	//A result of 0 indicates a successful connection with no warnings.
	System.out.println("Result=" + result);

  } catch (RuntimeOperationsException roe) {
	Exception ex = roe.getTargetException();
	ex.printStackTrace(System.out);
  } catch (Exception ex) {
	System.out.println("General exception occurred");
	ex.printStackTrace(System.out);
  }
 }
}