12.07.2014

El desarrollador o el usuario

En muchas situaciones me preguntan cual framework es el mejor para x tarea, o cual framework utilizo yo para desarrollar una aplicación. Algunas veces son mas puntuales y preguntan cosas como utilizas el Entity Framework? Usas Sencha para las apps o Apache Cordova? Estas preguntas van acompañadas siempre con el “en que te basas para escoger un framework” donde quizás la pregunta es mas orientada al tipo de preguntas que un arquitecto de software tiene que hacerse y ayudar a responder a los equipos de desarrollo con los cuales trabaja.

Personalmente utilizo algunos frameworks para desarrollar aplicaciones tales como Dapper de stackoverflow; sin embargo, normalmente trato de utilizar la tecnología recomendada por el vendedor para desarrollar aplicaciones en su plataforma. Aquí es cuando los desarrolladores “levantan” la mano y dicen pero porque o usas x o y framework si al final te ayuda a terminar tus aplicaciones de forma más rápida? La respuesta es sencilla: Yo hago aplicaciones para usuarios y no para desarrolladores y no puedo sacrificar al usuario final para beneficiar al desarrollador.

Enfoque desde el punto de vista de un arquitecto: Es bueno terminar en tiempo y en forma los proyectos en los cuales trabajamos, pero no debo entregar aplicaciones con menos capacidades al usuario final por el simple hecho de utilizar un framework que permite que los desarrolladores escriban menos código; es decir, la aplicación debe tener el máximo desempeño que puede dar en la plataforma seleccionada en temas tales como velocidad de ejecución, interacción con repositorio de datos, consumo de energía – para dispositivos móviles, consumo de datos – para dispositivos móviles, manejo de transacciones, manejo de errores, manejo de esquemas de auditoria, seguridad e interacción con el usuario final. Este tema es relevante tanto para aplicaciones locales (on premises), aplicaciones móviles y aplicaciones que corren en la nube.

Etiquetas de Technorati: ,

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

3.09.2014

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

En una arquitectura Hibrida siempre vamos a tener componentes “on premises” y componentes en la nube. En este post vamos a conectar el bus de integración BizTalk Server con el Azure service bus.

Escenario

Normalmente en una arquitectura hibrida, los componentes que se dejan “on premises” son los que están relacionados con datos sensibles o los sistemas legacy que no se pueden correr o integrar directamente con los servicios o endpoints en la nube. Estos sistemas por lo general no tiene todas las características para integrarse a la nube o es muy complicado integrarlos de manera integrar (con transaccionabilidad, tolerancia, seguridad, etc.) a las buses que exponen los endpoints en la nube. En estos casos debemos usar un bus de integración para poder conectar estas aplicaciones con los endpoints a través de la nube. Cuando hablamos de endpoints hablamos de puntos de acceso para consumir servicios SOAP y REST ya sea directamente o través de aplicaciones utilizando servicios en la nube tales como los “mobile services” de azure.

Para este post vamos a imaginar una aplicación que la única interface al mundo exterior ( dentro de un mismo datacenter) que tiene disponible son archivos de texto. Esta aplicación graba un archivo de texto en un folder y espera la respuesta en otro archivo de texto en otro folder. Este archivo será tomado por BizTalk Server y enviado al bus de azure apenas la aplicaciones lo escriba. Seguidamente otro adaptador de BizTalk lo traerá de vuelta de la nube lo pondrá en el folder definido para la respuesta.

Demo

No vamos a hacer una aplicación que grabe un archivo en un folder, pero si vamos a definir un folder y vamos a poner un archivo en este folder para que BizTalk server lo consuma. Como se ve en la siguiente imagen, el adaptador define un uri de donde recoger los archivos para que BizTalk los procese.

image

Luego procedemos a configurar el puerto de envío. Lo primero que tenemos que hacer es crear el filtro para que el mensaje se pueda rutear desde el puerto de recibo al puerto de envío.

image

El siguiente paso es seleccionar el adaptador para el bus de servicios como se muestra en la siguiente figura.

image

Ahora procedemos a configurar el adaptador para que se pueda conectar al bus. El primero paso es establecer el uri de la cola que vamos a utilizar.

image

Luego procedemos a configurar la autenticación de la conexión a la cola del bus de servicios de azure. En primera instancia el uri del ACS lo tomamos del portal de de seguridad de Azure. Este portal lo podemos acceder del dialogo que nos presenta la clave y el usuario para conectarnos al namespace donde reside la cola. El detalle desde donde se toma la dirección de la autenticación se ve en la siguiente figura.

image

Ahora procedemos a configurar el adaptador en su parte de autenticación. El owner y el issuer key son los mismos que usamos para consumir la cola desde las aplicaciones que normalmente desarrollamos y que se comunican con el el Azure Service Bus.

image

Listo!!! si ponemos un archivo en el folder especificado, veremos que el mensaje llega a la cola en el bus de servicios de Azure – en este caso podemos ver que hay un mensaje en la cola llamada queuereportes.

SNAGHTML1d460a9

En el siguiente post vamos a configurar el adaptador de recibo de mensajes de BizTalk Server para el Azure Service Bus para ir a obtener el mensaje enviado anteriormente.

Etiquetas de Technorati: ,,,

2.23.2014

Los protocolos de SQL Server y BizTalk Server

Existen varios escenarios en donde el uso del protocolo de memoria compartida de SQL Server podría causar impacto en el desempeño de BizTalk Server. Un ejemplo típico es el acceso al SQL Server por parte de usuarios o clientes desde la misma maquina en donde reside el SQL Server. Para solucionar este posible problema se recomienda el uso de los protocolos “Named Pipes” y TCP/IP, además de deshabilitar el protocolo de memoria compartida.

Para realizar este cambio primero procedemos abriendo el SQL Server Configuration Manager

image

Seguidamente buscamos la opción SQL Server Network Configuration y en los protocolos para MSSQLSERVER habilitamos los “Named Pipes” y TCP/IP y deshabilitamos el protocolo de memoria compartida “Shared Memory” tal y como se ve en la siguiente figura.

image

Para que los cambios tengan efecto, debemos reiniciar el servicio de SQL Server.

Etiquetas de Technorati: ,,

1.02.2014

Configurando el portal de Azure localmente con el Windows Service Bus–parte 2

Continuando con el post anterior, vamos a configurar el servicio del bus de servicios a través del portal para que los usuarios puedan administrar sus objetos del bus directamente desde el portal.

Configurando el aprovisionamiento del service bus

Una vez configurado el service bus en el portal del Azure Pack, procedemos a crear los planes de forma tal que los usuarios del mismo puedan administrarlo directamente desde el portal. Para iniciar vamos al portal del Azure pack y seleccionamos planes, en esa opción seleccionamos crear plan.

image

Seguidamente procedemos a crear el plan y el primer paso es ponerle un nombre descriptivo al mismo.

image

Seguidamente seleccionamos los servicios que serán parte del plan, como se ve en la siguiente pantalla, seleccionamos service bus y el service bus recién agregado.

image

En la ultima pantalla procedemos con la finalización de la configuración del servicio.

image

Una vez creado el plan, este aparece en la consola del portal.

image

El siguiente paso es asegurarnos que el numero de conexiones en el sitio sea ilimitado.

image

Como podemos ver en la siguiente figura, el plan esta configurado y el sitio de estadísticas listo para recabar información de uso.

image

Una vez creado el plan, ahora se procede a asociar los inquilinos del servicio con el plan. Con esta asociación los inquilinos pueden asociarse al portal y solicitar nuevos planes, o interactuar con el service bus haciendo tareas como crear colas, suscripciones, namespaces, etc.

Para que los inquilinos puedan acceder al service bus configurado en la nube privada, debemos crear una cuenta para el usuario que va a proceder con su uso. Para eso vamos a la opción de cuentas de usuario y seleccionamos crear un nuevo usuario.

image

Agregamos los datos solicitados, asociamos el nuevo usuario al plan del service bus, y procedemos a crearlo.

image

El siguiente paso es verificar si el usuario se creo correctamente y si se asocio al plan que estábamos configurando, para esto procedemos dando clic al usuario en el portal y viendo los detalles del mismo verificamos si el usuario esta activo y si tiene asociado el plan.

image

Ahora procedemos a ingresar al sitio de inquilinos con el nuevo usuario creado. Para esto vamos a la dirección https://drojasmwin8:30081/ y procedemos a digitar las credenciales creadas.

image

Una vez ingresados al sitio web, podemos ver que el usuario inquilino tiene permisos para manipular el bus de servicios del plan (o la instancia que le corresponde). Inicialmente podemos crear un namespace y dentro del namespace podemos crear colas y tópicos.

image

Si ingresamos al namespace vemos que ya tenemos las opciones de creación antes mencionadas.

image

El resultado de dicha acción es la creación de una cola de mensajes en el service bus.

image

Para conectarnos al bus, podemos usar la cadena de conexión que nos brinda directamente el namespace del bus de servicios.

image

Incluso podemos acceder a la cola desde el Service bus Explorer (con la versión compatible con el Windows Service bus)

image

El resultado final de la conexión se ve en la siguiente figura.

image