JAVA + JMS + BIZTALK.
Testei o JMS Adapter da JNBridge, funciona! Mas, nem tudo são flores então vou contar as dificuldades que encontrei. Antes de tudo o adaptador integra o Biztalk ao serviço de mensagens do JAVA, vulgo JMS (Java message service), esse serviço está presente na maioria dos servidores JAVA, como: JBOSS, Websphere, Glassfish entre outros, a lista completa que o adapter suporta está aqui. Outra coisa boa é que o adapter suporta todas as versões do Biztlalk a partir do Biztalk Server 2006.
Pra quem tiver afim de testar o cara, é possível baixar e testar por 30 dias, link.
A JNBridge, fornece exemplos de como configurar o adapter para cada tipo de servidor java suportado, mas não fornece nenhum exemplo de aplicativo java e nem como configurar o servidor java. Então perguntei para o google e ele me contou varias coisas! Alguns links que usei para criar um servlet java e um client: Exemplo1, exemplo2 e exemplo3.
Criei uma applicarion no Biztalk que recebe uma mensagem via JMS, mapeia e devolvi para o JMS. A mensagem era consumida e enviada pela mesma ConnectionFactory que criei no JMS "jms/ConnectionFactory", configurei a ReceiveLocation e a SendPort com essa ConnectionFactory e!
Quando enviava a mensagem recebia esse erro na testa :
Pesquisei no google e encontrei varias possíveis causas e soluções, rsrsrs, falou !
A SOLUÇÃO:
Dei um chute de fora da área e a bola foi no ângulo. Criei outro Host Instance e configurei o Send Adapter com o novo Host Instance e funcionou! Não sei se é uma limitação do Adapter 32 bits não testei no ambiente 64 bits, mas se alguém testar e o erro não acontecer avise por favor!
RESPOSTA JNBridge:
O Suporte da JNBridge enviou um mail dando explicações mais precisas sobre esse problema, segue a explicação:
Looks like you are using GlassFish/OpenMQ. There is a known problem in GlassFish v3.0.1 with supporting stand-alone JEE clients such as the adapter. GlassFish v2.1.1 is more stable. I’m afraid Oracle is not committed to GlassFish.
The error you experienced is common to stand-alone JEE clients (where “stand-alone” means the client is not in a JEE container running in an application server). It is a side-effect of JNDI naming environments and class loader isolation. The receive adapter uses JNDI to instance and obtain the connection factory. When the send adapter also uses JNDI to obtain the connection factory, the lookup fails because the naming environment can't locate the object in its cache even though it’s been loaded. This is what is known as "class loader hell" by those who write JEE applications. Some JEE app servers are better than others when using a stand-alone client (for the record, JBoss is the worst).
As you discovered, by placing the send and receive sides in separate processes, this problem can be avoided. It can also be solved by adding the GlassFish/OpenMQ JAR files to the JVM's boot class path using the JVM argument "-Xbootclasspath/a:". Please see the transport handler property "JVM Arguments" for more information.
O PULO DO GATO:
Uma coisa que me salvou foi configurar o Adapter para logar os erros. Porque ? Como o adapter usa classes java para se conectar, caso ocorra alguma exception do lado do java ou se o adapter não estiver encontrando alguma classe java. "Você recebe uma mensagem bem objetiva no Event Viewer dizendo exatamente onde e como solucionar o problema" Abraça, Os erros do lado do java o adapter salva no arquivo que você configurar, é uma boa pratica configurar tanto para o Receive quanto para o Send Adapter, sem isso você está rendido, rsrsrs!
O Google te contou várias coisas? Mas ele é mesmo um amigo e tanto! kkkkk.
Parabéns pelo post. Gostei!
Muito bom, muito bom!!!
Você não chegou a testar com portas dinâmicas, chegou?
Testei também com porta dinâmica e funcionou, o pessoal da JNBridge enviou um e-mail explicando a causa do problema e outras informações, logo compartilho tudo!
Postar um comentário