9.10.2014

Configuración BizTalk ESB Toolkit - Error: The remote server returned an error ( 400 Bad Request)

Configurando el ESB Toolkit para BizTalk Server se me presento un error a la hora de configurar el portal del bus de servicios. Luego de compilar y hacer el deployment correspondiente del portal me aparecía el error:

The remote server returned an error (400 Bad Request)

Como ven el error es poco descriptivo y si iba a al visor de eventos aparecía exactamente la misma información. Debugueando el portal en el Visual Studio pude ver que el problema era en la base de datos, desde donde verificando varias cosas pude llegar a la solución del problema. Inicialmente verificando las bases de datos que el toolkit crea me di cuenta que la base de datos EsbExceptionDb no tenia estructuras de tablas ni de procedimientos almacenados por lo que la configuración del ESB había fallado.

image

Antes de reconfigurar el ESB Toolkit, procedí a borrar todas las tablas que este había creado:

image

Seguidamente reconfigure el ESB toolkit y listo, las bases de datos se generaron correctamente.

image

Luego de esto, el portal me apareció pero con errores, ya que había modificado el manejo de excepciones para que me presentara las excepciones en los segmentos de la pagina correspondiente.

Seguidamente procedí a reinstalar el portal; sin embargo, aún aparecían errores en la ejecución del script donde se creaba la base de datos ESBAdmin. Verificando el script de creación y configuración que se ejecuta automáticamente me di cuenta que los grupos y usuarios de BizTalk Server a los que se les da acceso a la base de datos vienen “quemados” en ingles y yo estaba configurando el servidor en español, por lo que procedí a cambiarlos.

image

Luego de esto el portal apareció correctamente en el navegador, aunque claro, sin datos todavía.

image

Etiquetas de Technorati: ,

8.18.2014

Webcast Implementando SOA con el Windows Service Bus–Grabación

Para los que me consultaron, el link con el webcast del primer webcast es el siguiente: https://www149.livemeeting.com/cc/wwe_us/view.asx?scan=scanhff 

Lo pueden ver en línea o descargarlo

Etiquetas de Technorati:

8.13.2014

Windows Service Bus: Mejora del Mensaje

Una de las ventajas de los buses de servicio es que permiten mejorar los mensajes que pasan por el “middleware”. En los buses de integración como BizTalk Server se usan “mappers” los cuales a través de XSLT y otros elementos mejoran o convierten un mensaje. En el Windows Service Bus esto se logra a través de los tópicos y las acciones a partir de cada subscripción al tópico. En este post vamos a ver como mejorar un mensaje que ingresa al service bus usando un tópico.

Creación del Tópico

Lo primero que vamos a hacer es crear un tópico y agregarle 3 subscripciones tal y como se ve en la siguiente figura.

SNAGHTML2ea4d48

El primer tópico recibe todos los mensajes y por lo tanto no tiene ningún filtro especial ni ninguna acción especial sobre el mensaje.

SNAGHTML2f0e584

El segundo tópico si tiene un filtro particular y una acción para ese filtro. En este filtro vamos a recibir los mensajes que tengan en la propiedad país el código ´CRC´de Costa Rica y cuando el filtro se cumpla vamos a establecer la propiedad del mensaje código con el numero 506.

image

Algo similar llevaremos a cabo con el siguiente filtro, en el cual vamos a filtrar los mensajes con código de país PTY de Panamá y vamos a establecer el código con el numero 507.

image

Código de envío y recibo del mensaje

Ahora procedemos a enviar los mensajes a la cola del bus de servicios. Para esto creamos un nuevo mensaje y le agregamos el país y el código que luego se modificara se inicializa con el valor 0.

image

El siguiente paso es programar el recibo de mensajes de la subscripción donde llegan todos los mensajes y no tiene acción.

image

Ahora procedemos a programar el recibo de mensajes desde la subscripción con un filtro de código de país = a ‘CRC’.

image

Por ultimo, programamos el recibo de los mensajes que llegan a la subscripción de PTY.

image

El código del método desplegar mensaje es el siguiente:

image

Si ejecutamos la forma anterior, podemos ver que los mensajes se reciben de acuerdo a su destino y que el código de país se modifica como corresponde en la acción asociada al filtro.

image

Etiquetas de Technorati:

7.17.2014

Nueva serie de Webcast de arquitectura

Gracias al excelente recibimiento de la serie de webcast de arquitectura producida el año pasado se ha decidido hacer una nueva serie con temas relacionados y que están presentes en los temas a diario que enfrentamos arquitectos y desarrolladores. La nueva serie de webcast será en vivo igual que la anterior y los videos también serán hosteados en Channel9. Esta serie inicia el próximo 6 de agosto y a continuación pueden ver la información y le link de registro para el evento.

image

El link de registro para el evento es el siguiente:

Serie - Arquitectura de Software: Implementando SOA con el Windows Service Bus

Para los que desean información de los links del año anterior los pueden ver en channel 9 en esta dirección.

5.14.2014

BizTalk Hosts y Host Instances

Uno de los términos que mas confunde dentro del vocabulario utilizado a la hora de utilizar BizTalk Server es el concepto de Host y su relación y diferencia con el concepto del Host Instance. En este post vamos a definir que es cada uno de ellos y cual es su función dentro de BizTalk Server.

BizTalk Host

Un grupo de BizTalk puede tener muchos host. Los Host son contenedores lógicos donde varias tareas de BizTalk Server pueden ser asignadas. Existen dos tipos de Host:

  • Isolated Host
  • In-Process Host

El host de tipo in-process es utilizado por la mayoría de las tareas de BizTalk Server y esto quiere decir que todas las tareas a ejecutar, se van a llevar a cabo dentro del mismo proceso de BizTalk –> es decir, el mismo proceso de Windows asignado para BizTalk Server. Por otra parte, el Isolated Host va a llevar a cabo su trabajo por medio de otro proceso; por ejemplo, IIS. Cuando el IIS recibe un mensaje, el host de IIS utiliza los módulos de BizTalk Server y procesa el mensaje siguiendo los mismos pasos que cuando se utiliza un “Host in-process”; es decir, pasando por el adaptador, el pipeline y llegando al “Message Box”.

Los Isolated Host disponibles por defecto en la instalación del BizTalk Server son los siguientes:

  • HTTP Receive
  • SOAP Receive
  • WCF-BasicHttp Receive
  • WCF-CustomIsolated Receive
  • WCF-WSHttp

Estos adaptadores reciben los mensajes a través del IIS y no a través de un servicio de Windows. Cada host debe tener al menos un “host instance” ejecutándose.  Un host instance del tipo “in process” no es mas que un servicio Windows ejecutándose en uno o mas servidores BizTalk y llevando a cabo las tareas asignadas al host.

Cuando se crea un “host instance” se crea tanto en el servidor de BizTalk y en las bases de datos de datos de BizTalk Server.

Etiquetas de Technorati: ,,

5.01.2014

AMQP 1.0 se convierte en estándar internacional

En los últimos meses he tenido la oportunidad de trabajar en proyectos usando el protocolo AMQP el cual como explique en un post anterior tiene una serie de ventajas a la hora de desarrollar aplicaciones distribuidas. Sin embargo, el día de hoy me encontré con esta noticia la cual creo que es de sumo interés para los desarrolladores que nos dedicamos al tema de arquitectura y capa media – middleware.

Hoy se anuncio por parte de OASIS, ISO y IEC que el protocolo AMQP se ha convertido en un estándar internacional. Este anuncio es un gran paso para lograr estandarizar la forma en que comunicamos aplicaciones dispares usando métodos asíncronos o broadcasting de transacciones, ya que nos da la posibilidad de crear capas medias estandarizas en donde podemos cambiar  de componente intermedio (servidor de colas o tópicos) y nuestras aplicaciones solamente tendrían que cambiar la forma en que se comunican con el componente, dejando el consumo de mensajes intacto.

RabbitMQ, Azure Service Bus, Windows Service Bus y otras marcas de componentes del mercado ya soportan este estándar de manera natural por lo que los insto a utilizarlo para crear capas medias eficientes y estandarizadas, en donde el lenguaje de programación no incide en el comportamiento de la aplicación.

Igualmente, el grupo de Apache Qpid tiene en su roadmap soportar clientes en diversas tecnologías tales como php, Ruby y C, además de las ya soportadas.

Esperamos mucha evolución positiva en estos temas en los próximos meses.

4.05.2014

Que es AMQP?

“Advanced Message Queuing Protocol ” es un estándar abierto para enviar mensajes entre aplicaciones y/o organizaciones. Este estándar nos permite eliminar el “vendor lock” en lo que respecta a la creación de arquitecturas distribuidas ya que podemos utilizar cualquier intermediario y cambiarlo cuando así lo queramos sin tener necesidad de cambiar el código que escribimos para enviar o recibir los mensajes. Como es un estándar abierto, nos permite conectar aplicaciones que están en distintas plataformas sin necesidad de utilizar un intermediario que le ponga mucho overead a la transacción tal como un bus de servicios de integración en donde normalmente se tiene que enviar para ser procesado en XML y en el peor de los casos usando HTTP.

AMQP en la vida real

Aun sin existir el estándar para manejo de mensajes vías un servidor de colas, este tipo de servidores nos permiten crear aplicaciones distribuidas que nos ayudan a manejar altos volúmenes transaccionales donde no necesariamente alguna de las partes debe de estar disponible para que el envío del mensaje sea exitoso. Este tipo de modelos de operación se aplican de forma común sobre todo en sistemas que procesan transacciones tales como pagos, solicitudes de autorización, manejo de auditorias, etc.

Esta capa intermedia nos permite conectar aplicaciones entre si, dándonos la oportunidad de crear verdaderas aplicaciones distribuidas –> concepto que difiere mucho de tener librerías en un directorio virtual que aunque se podrían utilizar en otras aplicaciones no se hace, porque en realidad al estar en un directorio virtual, están siendo utilizadas de forma local.

Para conectarnos a un servidor AMQP utilizamos diversas librerías disponibles en el mercado, siendo una de las mas comunes Apache Qpid. Esta librería nos permite enviar y recibir mensajes utilizando el estándar AMQP desde cualquier lenguaje soportado y desde el cual se puedan utilizar las librerías; entre los lenguajes incluidos están Java –> JMS, javascript, C++, .NET –> WCF, phyton, Ruby, Perl y una seria de lenguajes que se van agregando a la misma. Igualmente existen otras librerías que nos permiten interactuar con servidores AMQP con otros lenguajes de programación. Es importante destacar que AMQP nos permite interactuar entre diversas plataformas mientras la plataforma se adapte al estándar.

Existen varios servidores que soportan el estándar AMQP, tales como Windows Service Bus, RabbitMQ, Oracle Open Queue, ZeroMQ, etc. Una ventaja con este estándar es que podemos cambiar el servidor sin necesidad de cambiar el código con el cual interactuamos con el servidor, esto nos permite tener una infraestructura distribuida sin estar “amarrado” a una marca en especifico.

Básicamente la forma en que AMQP funciona se puede visualizar en la siguiente figura. Un cliente A tiene una librería en su lenguaje de preferencia que le permite interactuar con un servidor utilizando AMQP; por lo tanto puede enviar mensajes al servidor AMQP. Desde el otro extremo hay otro cliente B que también soporta el estándar AMQP pero no necesariamente utilizan el mismo lenguaje de programación para consumir los mensajes y que puede interactuar con el cliente A sin importar desde que plataforma fue enviado el mensaje.

image

En próximos post vamos a ver como interactúan clientes en plataformas diferentes utilizando AMQP – .NET y Java.

Etiquetas de Technorati:

3.30.2014

Windows Service Bus + AMQP + Java – Parte 1

El Windows service bus no es soportado por el SDK de Java para Azure, solamente funciona con el bus de servicios en Azure. Sin embargo, para conectarnos usando ambientes de Java, tenemos un par de opciones: el API REST y AMQP. En este post vamos a iniciar el tutorial para lograr enviar y recibir mensajes a un bus de servicios corriendo localmente en Windows utilizando Java como lenguaje de programación y utilizando el estándar AMQP.

Exportar Certificados a las maquinas cliente

Java no utiliza el store de certificados de Windows –> es de esperar porque la solución debe de funcionar en todos los SO – sino que tiene su propio almacenamiento. Por lo tanto lo primero que debemos hacer es exportar el certificado SSL auto generado del Windows Service Bus.
El primer paso es abrir el power shell para el Windows Service Bus y ejecutar el comando Get-SBAutoGenerateCA.
image
Cuando ejecutamos este procedimiento se exportan en dos archivos el certificado de la autoridad certificadora y la lista de revocación. Si no especificamos el nombre del archivo, el cmdlet nos generara los archivos con el nombre AutoGeneratedCA.
image
El siguiente paso es verificar que la herramienta bin\keytool.exe existe, y que lib\security\cacerts existe. Este proceso se debe llevar a cabo desde la consola en modo administrador. Como podemos ver en la siguiente imagen, la herramienta keytool.exe si esta presente.
image
Igualmente cacerts también existe
image
Ahora procedemos a ejecutar el siguiente comando:
image
bin\keytool.exe –list –keystore lib\security\cacerts

Se nos va a pedir la contraseña del almacén de certificados de Java el cual por defecto es changeit. Esto nos muestra el total de certificados que se encuentran almacenados en el almacén de Java.

El siguiente paso es importar los certificados autogenerados por el bus de servicios ejecutando el siguiente comando desde la consola donde probamos el acceso al almacén de certificados de Java.

bin\keytool.exe –importcert –alias AppServerGeneratedSBCA –file %temp%\AutoGeneratedCA.cer –keystore lib\security\cacerts –v

La aplicación nos va a preguntar si confiamos en el certificado, le decimos que si y el certificado queda guardado en el almacén.

image

En el siguiente post vamos a crear el cliente Java para enviar un mensaje a una cola en el bus de servicios de Windows.

Etiquetas de Technorati: ,,

3.29.2014

Request–Response con el Windows Service Bus

El bus en su versión de Windows no tiene “relay service” disponible como si sucede en el bus de servicios de Azure, por lo tanto solo se soportan transacciones asíncronas. En este sentido solo tenemos como opción utilizar colas o tópicos ya que no podemos conectar servicios creados en WCF y hosteados en el IIS al Windows Service Bus para que sean atendidos en un patrón solicitud y respuesta.

Sin embargo, como bien lo definimos en el titulo de este post, si existe una forma de crear solitudes de dos vías en el Windows Service Bus y es utilizando correlación, sesiones y colas.

El Cliente

El primer paso es crear el cliente del servicio es decir, el que envía la solicitud. Para esto primero creamos variables para tener acceso a la cola de envío y a la cola de respuesta.

  1: var _requestQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "RequestQueue");
  2: var _responseQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "ResponseQueue", ReceiveMode.ReceiveAndDelete);

Luego creamos un while para presentar la consola hasta que el cliente digite una tecla que sea diferente a “n” o “N”, en cuyo caso el cliente nos estará diciendo que no quiere enviar mas mensajes.


Dentro de este While vamos a crear un Id de sesión único utilizando un Guid de sistema y procedemos a solicitar el numero de cliente que el usuario desea ingresar; por ultimo establecemos la sesión utilizando el id de sesión único que acabamos de generar.

  1: var _replyToSessionId = Guid.NewGuid().ToString();
  2: Console.WriteLine("Digite el numero de cliente: ");
  3: string _numeroDeCliente = Console.ReadLine();
  4: var _messageSession = _responseQueue.AcceptMessageSession(_replyToSessionId);
  5: 

El siguiente paso es crear el mensaje que vamos a enviar. Este contendrá el numero de cliente ingresado por el cliente, pero además tendrá el valor de la sesión y la propiedad ReplyToSessionId establecidos por el Id de sesión único creado anteriormente con el Guid del sistema. Después de esto enviamos el mensaje.

  1: var _mensaje = new BrokeredMessage(_numeroDeCliente)
  2: {
  3:     SessionId = _replyToSessionId,
  4:     ReplyToSessionId = _replyToSessionId,
  5:     MessageId = DateTime.Now.ToBinary().ToString()
  6: };
  7: _requestQueue.Send( _mensaje );
  8: Console.ForegroundColor = ConsoleColor.Cyan;
  9: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);

Por ultimo esperamos la respuesta del mensaje y lo desplegamos en la consola.

  1: Console.ForegroundColor = ConsoleColor.Cyan;
  2: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);
  3: 
  4: var _responseMessage = _messageSession.Receive(TimeSpan.FromSeconds(20));
  5: if (_responseMessage != null)
  6: {
  7:     Console.ForegroundColor = ConsoleColor.Green;
  8:     Console.WriteLine("Mensaje recibido: {0}. El nombre del cliente es {1}", _responseMessage.MessageId, _responseMessage.GetBody<string>());
  9: }

El Servidor


Seguidamente creamos el servidor que va a procesar la solicitud enviada por el cliente y va a responder a la instancia del cliente. El primer paso es crear dos colas, una hacia donde se envía la solicitud, y otra hacia donde se envía y se busca la respuesta a la solicitud.

  1:         private QueueClient _requestQueue;
  2:         private QueueClient _responseQueue;

Luego procedemos a crear el método que va a procesar la respuesta. Inicialmente se crea una sesión, luego de esto hacemos un ciclo “while” en donde nos quedamos esperando hasta que llegue un mensaje a la cola de recibo. Como se puede ver en el segundo while, nos quedamos esperando hasta que la variable _messageSession sea diferente de nulo; el estado de esta variable cambiara cuando la operación de solicitud de mensaje devuelva un mensaje recibido en la cola de solicitud _requestQueue.

  1: while (true)
  2: {
  3:   MessageSession _messageSession = null;
  4:   while (_messageSession == null)
  5:   {
  6:       try
  7:       {
  8:           Console.ForegroundColor = ConsoleColor.DarkMagenta;
  9:           Console.WriteLine("Aceptando la sesion del mensaje");
 10:           _messageSession = _requestQueue.AcceptMessageSession();
 11:           Console.WriteLine("Sesion aceptada");
 12:       }
 13:       catch (TimeoutException _e)
 14:       {
 15:           Trace.WriteLine(_e.ToString());
 16:           throw;
 17:       }
 18:   }


Una vez recibido el mensaje procedemos a procesarlo. El primer paso es extraerlo de la cola para que la instancia del mensaje desaparezca de los mensajes a procesar, esto se logra con la operación MessageSession.Receive. Seguidamente obtenemos el contenido del mensaje con la operacion GetBody y procedemos a imprimir lo recibido. Seguidamente procedemos a crear el mensaje de respuesta, para esto creamos un nuevo mensaje – BrokeredMessage –, le agregamos el nuevo contenido el cual es el mismo del anterior pero con el string “el nombre del cliente <mensaje anterior> es XYZ”. Este nuevo mensaje se responde con una particularidad, la variable SessionId es el valor de la variable ReplyToSessionId y el Id del mensaje sera el mismo que el Id del mensaje recibido, para lo cual usamos la propiedad MessageId de ambos mensajes.

  1:  Console.ForegroundColor = ConsoleColor.Yellow;
  2:     Console.WriteLine("Recibiendo mensajes de la session {0} ", _messageSession.SessionId);
  3:     Console.ForegroundColor = ConsoleColor.Green;
  4:     var _message = _messageSession.Receive(TimeSpan.FromSeconds(5));
  5:     if (_message != null)
  6:     {
  7:         var _numeroDeCliente = _message.GetBody<string>();
  8: 
  9:         Console.WriteLine("Cliente numero: {0}", _numeroDeCliente);
 10: 
 11:         var _nombreCliente = string.Format("El nombre del cliente : {0} es XYZ", _numeroDeCliente);
 12: 
 13:         var _responseMessage = new BrokeredMessage(_nombreCliente)
 14:         {
 15:             SessionId = _message.ReplyToSessionId,
 16:             MessageId = _message.MessageId
 17:         };
 18: 
 19:         _responseQueue.Send(_responseMessage);
 20:     } //fin del if
 21: } //fin de while

Para hacer la prueba primero ejecutamos el servidor que se queda esperando por mensajes.
image

Luego iniciamos el cliente que nos solicita la información del cliente a enviar.
image

Luego digitamos los datos del cliente y podemos ver que el servidor recibe la respuesta de forma inmediata. Al mismo tiempo nos despliega los datos digitados del cliente y procede a contestar.
image



En la siguiente pantalla vemos que el cliente envió ABC y que recibió la respuesta por parte del servidor con el mensaje de texto agregado de vuelta.


image


Etiquetas de Technorati:

3.12.2014

Conectar BizTalk Server a una cola en el Azure Service Bus – Parte 2

En el post anterior, conectamos un servidor BizTalk Server con una cola de servicios del Azure Service Bus. En este escenario movimos un mensaje que contiene un documento XML desde un folder hasta una cola llamada reportqueue en el bus de Azure . En este post vamos a completar el ciclo y vamos a obtener el mensaje directamente desde esta cola utilizando otra aplicación del servidor BizTalk.

Demo

En esta ocasión vamos a iniciar creando un receive location en donde configuramos el adaptador para que se conecte al bus de servicios para obtener los mensajes respectivos.

image

La configuración del adaptador es exactamente igual a la configuración del adaptador de envió configurado en el post anterior, tanto a nivel general como a nivel de autenticación.

image

Ahora asociamos la locación de recibo recién creada con el puerto de recibo.

image

El siguiente paso es configurar un send port para que estos mensajes que vienen de la cola del bus de servicios de Azure sean depositados en un folder de recibo en un archivo con un documento XML. Para esto procedemos a crear un puerto de una vía y configuramos la ruta en donde se va a guardar el archivo que contiene el mensaje obtenido.

image

Luego creamos un filtro en el puerto de envío para que recepcione los mensajes que ingresan a través del puerto que tiene configurado la locación de recibo que apunta al bus de servicios de Windows Azure.

image

Ahora cuando iniciamos la aplicación de BizTalk se consumen los mensajes de la cola y se guardan en el folder designado

image

El mensaje retornado contiene los datos tal y como fueron enviados en el post anterior.

image