Buscar este blog

martes, 28 de octubre de 2014

Biztalk 2010 - Debug orchestration code

Situación:
  • Se tiene una solution de Visual Studio 2010
  • Dentro de la solution hay un proyecto C#
  • Se despliega la solution como una aplicación Biztalk 2010

Propósito:
  • Debugear código de un behaviour

Solución:
  • En las propiedades del proyecto, en build, seleccionar configuración Debug.
    Si el proyecto forma parte de una solution, también se puede ir a las propiedades de la solution y en Configuration Properties > Configuration, seleccionar el modo de build de cada proyecto que lo componen.
    Parece que dentro de una solution, prevalece esta configuración superior, así que habrá que cambiarla  aquí
  • Hacer el build del proyecto
  • Ir al directorio en disco y entrar en bin > debug (también obj>debug)
  • Ahí habrá una dll
  • Abrir un Visual Studio Command Prompt. Es una aplicación accesible desde el menú inicio, dentro del directorio de Visual Studio y Visual Studio Tools.
  • Navegar hasta la ruta de la dll.
  • Ejecutar gacutil /if {rutaALaDLL}
  • Reiniciar el servicio de biztalk
  • En Services aparecerá como BizTalk Service BizTalk Group : BizTalkServerApplication
  • También puede hacer falta reiniciar el servicio del host de la aplicación
  • En Visual Studio seleccionar el proyecto
  • En la barra de herramientas superior ir a Debug > Attach to Process...
  • En el panel abierto, seleccionar el proceso BTSNTSvc.exe. En el Type pone T-SQL, Managed(v4.0....), x86
  • Ejectuar la orquestación.
  • Cuando se ejecute ese código parará en los breakpoints.

Nota:
El directorio de caché de Biztalk, donde se guardan las dll, es C:\Windows\Microsoft.NET\assembly\GAC_MSIL\. Se pueden actualizar las dll a mano, pero eso puede dar problemas porque están abiertas por el proces dllHost.exe.

Biztalk 2010 - Debug trace messages


Activar tracking en los puertos:
  • Abrir Biztalk Server Administration Console
  • Navegar a la apliacción que se quiera monitorizar
  • Ir send/receive ports
  • Seleccionar el puerto e ir a propiedades.
  • En la opción tracking, marcar las que correspondan

Consultar mensajes enviados/recibidos:
  • Abrir Biztalk Server Administration Console 
  •  Ir a Biztalk Group [nombreEquipo]
  • Seleccionar New Query
  • En SearchFor, marcar "Tracked Message Eventes"
  • Ejecutar la query
  • Pulstar sobre el mensaje que se quiera consultar y ver sus detalles

viernes, 10 de octubre de 2014

JBOSS CLI


Modo dominio:
/server-group=main-server-group/deployment=UnWar/:undeploy
/server-group=main-server-group/deployment=UnWar/:remove
/server-group=main-server-group/deployment=UnWar/:deploy






Añadir propiedad JNDI

/subsystem=naming/binding="java:/maestros/maestros-negocio.properties":add(value="file:/opt/jboss-eap-6.2/standalone/configuration/maestros.properties", binding-type=simple)

/subsystem=naming/binding="java:/maestros/maestros-negocio.properties":remove

domingo, 5 de octubre de 2014

Weblogic Liferay


Página de descarga de Liferay: http://sourceforge.net/projects/lportal/files/Liferay%20Portal/

Ir a la versión deseada y descargar dos ficheros:

  • El propio war de Liferay: liferay-portal-6.1.x-<date>.war 
  • El fichero de dependencias: liferay-portal-dependencies-6.1.x-<date>.zip


Guía oficial de instalación: https://www.liferay.com/es/documentation/liferay-portal/6.1/user-guide/-/ai/lp-6-1-ugen11-installing-liferay-on-oracle-weblogic-103-0

Guía completa en PDF.


Dejar los jars que hay en el fichero de dependencias, en el directorio Oracle\Middleware\user_projects\domains\${MyDomai}\lib









Configurar el datasource de liferay. Se necesita un fichero portal-ext.properties que estará directamente en el directorio del dominio (Oracle\Middleware\user_projects\domains\${MyDomai}):

jdbc.default.jndi.name=jdbc/LiferayPool

Se necesita indicarle a liferay cuál será su base de datos, y para ello se le pasa el nombre JNDI del datasource que crea weblogic.
Por defecto la base de datos será MySQL, pero se puede cambiar metiendo más propiedades en portal-ext.properties


Si la base de datos no es oracle, también hay que dejar en el directorio lib del domain el jar con el driver.
Además, si es weblogic 11g (10.3.5) hay que referenciar ese jar desde el propio classpath, seguramente debido a un bug del servidor.
Se edita el fichero setDomainEnv.cmd, que está en el directorio bin del domain y se añade la siguiente línea al final:

set CLASSPATH=C:\Oracle\Middleware\user_projects\domains\${MyDomain}\lib\mysql-connector-java-commercial-5.1.14-bin.jar;%CLASSPATH%


Crear un fichero portal-setup-wizard.properties y dejarlo también en el raíz del dominio, junto al portal-ext.properties.


setup.wizard.enabled=true

Este fichero lo lee la primera vez que arranca para inicializar la base de datos. Más adelante habrá que cambiarlo para que no haga esto siempre, y además inidicarle donde está el directorio de autodeploy.



Actualizar descriptor en weblogic.xml dentro del war de liferay (el que se descargó de su página).

<?xml version="1.0"?>

<weblogic-web-app
 xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"
>
 <jsp-descriptor>
  <keepgenerated>true</keepgenerated>
  <page-check-seconds>60</page-check-seconds>
  <precompile>true</precompile>
  <precompile-continue>true</precompile-continue>
 </jsp-descriptor>
 <container-descriptor>
  <prefer-application-packages>
   <package-name>org.mozilla.*</package-name>
  </prefer-application-packages>
  <optimistic-serialization>true</optimistic-serialization>
  <show-archived-real-path-enabled>true</show-archived-real-path-enabled>
 </container-descriptor>
 <context-root>/</context-root>
 
 <library-ref>
  <library-name>jsf</library-name>
  <specification-version>1.2</specification-version>
  <implementation-version>1.2</implementation-version>
  <exact-match>false</exact-match>
 </library-ref>
</weblogic-web-app>


Desplegar jsf-1.2.war como una librería.
Este war está en C:\Oracle\Middleware\wlserver_10.3\common\deployable-libraries\.


Después desplegar liferay como una aplicación web.

Una vez iniciado, para entrar en el portal hay que ir a http://localhost:7001/.

Liferay habrá creado unos directorios en la carpeta de dominio de weblogic (!!), además de un fichero properties de configuración:











Hay que copiar el fichero portal-setup-wizar.properties de este directorio, al que ya hay en el directorio del domain y sobreescribirlo. Con esto se evita que liferay esté inicializando el portal cada vez que arranca.

admin.email.from.name=Test Test
liferay.home=C:/Oracle/MIDDLE~1/USER_P~1/domains
admin.email.from.address=test@liferay.com
setup.wizard.enabled=false


Para desplegar un portlet el procedimiento será el siguiente:

  1. Generar el war del portlet.
  2. Dejarlo en el directorio deploy de liferay, el que está en en user_projects/domains.
  3. Añadirlo al portal desde liferay.
Al dejar el portlet en el directorio de deploy de liferay, se lee automáticamente, se le cambia el fichero web.xml y se envía al directorio de autodeploy de weblogic, que está dentro del domino.






sábado, 4 de octubre de 2014

WS integration in multimodule Maven Project

Objetivo:

  • Tener un módulo maven común (módulo api) con el modelo y la definición de un servicio web.
  • Tener un projecto maven de tipo WAR que implemente el servicio y lo publique como un web service.
  • Tener un proyecto maven de tipo WAR que consuma ese servicio web.




La forma habitual de trabajar con web services es disponer del modelo de clases en el servidor y generar una copia, por ejemplo con wsimport, en los distintos clientes. 
Con esto se tiene replicada la misma clase en cada cliente.

Lo ideal es tener esas clases en un único sitio, un jar, y que tanto el servidor como los clientes importen esa dependencia, sin tener que volver a crearla.

La ventaja de no replicar clases es que si el servidor publica dos fachadas de servicios, pero cuyos métodos comparten alguna clase de modelo en común, los clientes podrán hacer invocaciones entre ambos con la misma clase.


En este escenario, los dos WAR tendrán como dependencia común el módulo api 

Para la generación de los clientes se usará Spring WS, que únicamente necesita la dirección del WSDL e información de marshall/unmarshall para generar el cliente.
Esta informarción de marshalling también estará en el módulo api.


También hay un portlet que actúa como cliente de ese servicio web, y con spring-ws. La idea es no implementar lógica de negocio en los portlets y emplearlos únicamente como capa vista.

El código fuente de los proyectos está en:


El cliente WS proviene de la siguiente post de Krams:: Thanks for sharing!!!!