Trabajando JSON en BizTalk Server 2016 – Parte 2

Continuando con los post acerca de trabajar documentos JSON en BizTalk Server 2016, vamos a proceder a crear un ejemplo donde se recibe un documento XML y se rutea a un folder donde lo vamos a dejar convertido a un documento JSON.

Ejemplo

En este ejemplo, vamos a crear un puerto de ingreso donde se recibe un documento XML (el mismo que convertimos en el ejemplo del post anterior) tal y como lo muestra la siguiente figura.

Iniciamos creando un puerto de una vía por donde ingresará este documento XML utilizando el pipelines estándar de PassThru.

Ahora procedemos a crear el puerto de salida de una vía con dos condiciones importantes. La primera de esas condiciones es utilizar el pipeline de envío JSON que creamos en el proyecto JSONPipelines del post anterior tal y como se muestra en la siguiente figura.

La segunda condición es agregar un filtro para rutear el mensaje XML desde el puerto de recibo al puerto de envío utilizando la propiedad ReceivePortName tal y como se ve en la siguiente figura.

Seguidamente procedemos a activar los puertos de envío y recibo y enviamos el mensaje XML de prueba mostrado al inicio de este post. Como vemos en la siguiente figura, el documento fue enviado al puerto especificado en formato JSON.

Trabajando JSON en BizTalk Server 2016 – Parte 1

Uno de las nuevas características en BizTalk 2016 es la adición de componentes para pipeline para manejar el formato JSON(codificar/decodificar) tanto para consumir como para enviar mensajes JSON. En este post vamos a ver como trabajar el formato JSON en BizTalk Server 2016 a nivel de pipelines.

Ejemplo

Inicialmente, vamos a crear una pequeña orquestación que recibe un documento JSON y lo decodifica a un documento XML para direccionarlo a otro puerto en formato XML. Por facilidad del ejemplo, la orquestación funcionara con adaptadores FILE tanto para iniciar la orquestación como para enviar la respuesta.

Primero vamos a crear un proyecto que solo va a contener todos los pipelines (los que vamos a ir usando en esta serie de posts) y creamos un pipeline para decodificar un mensaje JSON a XML y otro para codificar un mensaje XML en un mensaje JSON. El primer pipeline se puede ver en la siguiente figura.

En el siguiente paso procedemos a publicar el aplicativo BizTalk para que estos pipelines queden disponibles para otras aplicaciones. Seguidamente procedemos a crear una aplicación BizTalk y agregamos como referencia el aplicativo recientemente publicado.

Ahora procedemos a crear un puerto de recibo donde vamos a configurar el pipeline para recibir el documento JSON tal y como se ve en la siguiente figura.

El primer paso es configurar el adaptador FILE(1), seguidamente seleccionamos el pipeline que creamos en el proyecto común y agregamos como referencia(2),  luego vía el botón elipse procedemos a configurar el pipeline(3). En este caso debemos definir el nodo raíz y seguidamente proceder a crear un namespace ya que el documento XML así lo va a requerir(4).

Ahora procedemos a crear un puerto de envío que tiene la particularidad de que utiliza un filtro para rutear el mensaje recibido JSON, solo que vamos a usar el pipeline passthru para grabarlo en el directorio tal y como viene decodificado.

Luego de este paso ya estamos listos, arrancamos el aplicativo y procedemos a realizar la prueba con el siguiente archivo.

La salida resultante será en formato XML tal y como se ve en la siguiente figura.

Invocar una orquestación en otro assembly

Una de las preguntas más frecuentes en el desarrollo de aplicaciones en BizTalk Server es como invocar una orquestación que reside otro assembly. Esta pregunta se da principalmente porque aunque hayamos publicado la orquestación en otro proyecto, cuando agregamos la referencia no podemos ver la orquestación en el cuadro de invocar orquestación.

Para poder ver las orquestaciones disponibles en otro Assembly el modificador del tipo debe de estar en público tal y como se ve en la siguiente imagen.

Después vez instalada en el servidor, ya podemos referenciar la orquestación desde el GAC y seguidamente invocar la orquestación desde una forma para iniciar la orquestación sincrónica o asincrónicamente.

Una vez seleccionada la orquestación deseada, esta aparece seleccionada en la forma de invocación.

Mapas en BizTalk: Obteniendo solo el primer registro de una colección

Uno de los problemas mas comunes que enfrentamos cuando desarrollamos en BizTalk se da cuando recibimos una colección de elementos, pero solo requerimos el primer elemento de la colección. Existen varias formas de obtener ese elemento, pero la forma mas sencilla de llevarlo a cabo es utilizando un mapa. En este post vamos a ver como solucionar este problema utilizando mapas en BizTalk.

El problema

En una aplicación BizTalk recibimos una colección de registros desde una base de datos y debemos procesar el primero registro únicamente. El mensaje recibido se presenta en la siguiente figura:

La Solución

Vamos a obtener el primer registro utilizando un mapeo y lo vamos a manera a otra estructura. En este caso la estructura destino es la que se muestra en la siguiente imagen.

Como se ve en la figura anterior, el esquema de persona espera únicamente una persona y requiere el nombre concatenado; es decir, el nombre debe de quedar como "Nombre Apellido1 Apellido2".

Para lograr esto vamos a utiilzar un mapa con una combinación de functoids que nos van a permitir obtener convertido el primero nodo. El mapa se puede ver en la siguiente figura:

Como se puede ver en la figura anterior, estamos utilizando un mapa con 4 tipos de functoids. Vamos a detallar cada uno de los functoids a continuación.

(1) Iteración

El primer functoid que vamos a utilizar es la iteración. Este functoid nos da el indice actual del registro en una operación cíclica iniciando el contador en 1. 

Para nuestro ejemplo, necesitamos procesar el registro cuando el indice que nos devuelve el functoid es igual a 1. 

(2) Equal

El segundo functoid nos permite hacer una comparación entre dos parámetros y nos retorna "true" si la comparación es verdadera o "false" si la comparación es falsa.

En nuestro caso, cuando el functoid de iteración nos retorna uno, entonces la condición será  verdadera, con lo cual vamos a proceder a copiar el valor en el nuevo nodo.

(3) Value Mapping (Flattening)

Este functoid copia registros de una estructura repetitiva a una estructura destino plana. En nuestro caso estamos copiando de una lista de personas a una única persona, esta acción se ejecuta si el primer parámetro que recibe el functoid es verdadero. 

La configuración de este functoid se ve en la siguiente figura. Como se ve en la figura, inicialmente se recibe el resultado del functoid "equal", si este es verdadero, entonces el valor de la concatenación del mapeo (nombre + apellido1 + apellido2) se copiara en la estructura destino.

Resultado

El resultado al aplicar el mapa al archivo mostrado al final del articulo se puede ver en la siguiente figura.

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.

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

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

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.

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

Etiquetas de Technorati: Biztalk Server,ESB Toolkit

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: BizTalk Server,Host,Host Instance

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.

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.

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

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.

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.

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.

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.

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: BizTalk Server,Azure Service Bus,Azure,ACS

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

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.

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

Etiquetas de Technorati: BizTalk,SQL Server,Perfomance

error X2003: #error: "Errors exist for one or more children." BizTalk Server

Creando un demo para un webcast me dio el siguiente error

Errors exist for one or more children

Este error aparecía en el output de visual studio y si le daba doble clic al error, me llevaba al código XLANG de la orquestación, tal y como se ve en la siguiente figura:

El error se da por un trozo de código mal escrito en un “Expression Shape” que sin embargo fue corregido pero por alguna razón el compilador no lograba detectar el cambio; entonces daba el error y no permitía construir la orquestación aunque no decía cual era el mismo.

Para solucionarlo simplemente se borra la línea que contiene el mensaje de error y se procede a recompilar. Con esto ya podemos generar el dll y hacer deployment de la solución.

Technorati Tags: BizTalk Server,C#,XLANG

Registering multiple adapter types within the same process is not a supported configuration – BizTalk Server

Trabajando en un proyecto de BizTalk Server, me encontré un error un poco peculiar, ya que al parece toda la configuración estaba correcta. El mensaje de error que recibía era el siguiente:

The Messaging Engine failed to register an adapter "WCF-BasicHttp". Details: "Registering multiple adapter types within the same process is not a supported configuration.

Buscando un poco la causa del problema, me di cuenta que el fondo del asunto andaba en el IIS  - ya que era un proceso de ruteo a través de un servicio WCF y que guardaba en una base de datos SQL Server utilizando un WCF-Custom adapter. Al estar el sitio web funcionando normalmente – se podía obtener el WSDL sin ningún problema -, supuse que el problema estaba en el application pool ya que el puerto de recibo estaba funcionando correctamente en el servidor BizTalk y además la indicación del error hacia referencia al proceso en donde escuchaba el adaptador.

El problema radica en que no se puede tener adaptadores diferentes corriendo en el mismo proceso; y en este caso, ya tenia otro servicio WCF exponiendo otro adaptador en el mismo sitio web pero en una aplicación web diferente y ambos utilizaban el mismo application pool. En este escenario, estaba registrando dos adaptadores en el mismo application pool y por lo tanto se generaba el error antes descrito.

La solución al problema es simplemente crear otro aplication pool y asignarlo al nuevo sitio web en donde se esta exponiendo el servicio.

Technorati Tags: BizTalk Server

Webcast de Arquitectura

La serie de web cast acerca de arquitectura de software que finalizaron el mes pasado, está disponible en Channel9. Ahí los pueden ver o bajarlos en el formato de su gusto. Les dejo los links de cada uno de los webcasts:

Webcast 1 – Arquitectura de Software – definición y Evolución

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-1-Definicin-y-Evolucin

Webcast 2 – Arquitectura Distribuida

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-2-Arquitectura-Distribuida

Webcast 3 – Workflows de Negocio en la arquitectura de software

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-3-Los-workflows-de-negocios-en-la-arquitectura-de-softwar

Webcast 4 – Diseño y polimorfismo

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-4-Diseo-y-Polimorfsmo-en-nuestras-aplicaciones-de-softwar

Webcast 5 – Seguridad a nivel de software

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-5-Seguridad-a-nivel-de-software

Webcast 6 – Gobernabilidad

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-6-Gobernabilidad-en-la-Arquitectura-de-Software

Webcast 7 – SOA

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-7-Arquitectura-Orientada-a-Servicios-SOA

Webcast 8 Pruebas Unitarias

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-8-Pruebas-Unitarias

 

Technorati Tags: .NET,Arquitectura de software

WebCast de Arquitectura

Los invito a participar en una serie de webcast que estaré brindando acerca del tema de arquitectura de software. En el mismo se van a estar tocando temas tales como:

• ¿Qué es arquitectura?
• ¿Que hace un arquitecto de software?
• Arquitectura distribuida
• Buses de Servicio
• BPM
• Seguridad
• Gobernabilidad
• Computación en la nube
• Pruebas

y muchos temas más. Son 10 sesiones, las cuales quedarán grabadas y se podrán ver en el mismo url. El link de registro es el siguiente:

http://msdn.microsoft.com/es-ar/jj920131(es-ar) 

Etiquetas de Technorati: Arquitectura de Software

Memorias - Arquitectura de Software: Hágalo todo con SOA !!!

Una de las afirmaciones más temerarias que esucho con mucha frecuencia, esta relacionado con el hecho de que las empresas creen que por el simple hecho de implementar una arquitectura orientada a servicios – SOA – todos sus problemas están resueltos. Esto también se ve reforzado por la idea que venden los proveedores de productos SOA cuando dicen: “Pasálo todo por el BUS de servicios y todo listo”. Esto por supuesto es incorrecto ya que aunque SOA como arquitectura ayuda a paliar los dolores normales de una organización en materia de sistemas, hay que recalcar que el fuerte de SOA va más por un tema de integración de aplicaciones heterogeneas y por extender la vida de un producto de software, que por un tema de arquitectura de dominio – ejemplo de que no se debe de pasar por un bus es el pago de tarjeta de crédito, ya que el timeout de una transacción del lado del cliente puede tener resultados inesperados en la transaccionabilidad del sistema.

Respecto a este tema, es importante diferenciar los tipos de arquitectura a los que nos vemos enfrentados todos los días. Esto principalmente porque no tienen sentido hacer una aplicación en .NET, pero como ahora estoy utilizando SOA le voy a poner un “overhead” innecesario a la transacción – no solo .NET Java, PHP o cualquier otra plataforma.

Nuestras aplicaciones de dominio – ejemplo RRHH, ERP, CRM, etc. – deben ser expuestas a través de servicios pero a través de un servidor de aplicaciones o un bus de dominio – tal como el Windows Service Bus – sin tener que ir a pasar por un bus de SOA que te va a solicitar transformar tus esquemas SOAP a un formato neutral – por lo general XML – para que pueda ser consumido desde cualquier aplicación en otro formato. 

Ahora bien, para los que ya se están preguntando porque a través de servicios si no va a pasar por un bus de datos la respuesta es muy sencilla: nunca sabemos quien va a necesitar nuestra funcionalidad. Esta es una premisa que todo arquitecto debe de tener en cuenta a la hora de desarrollar sus aplicaciones “esperar lo inesperado”. Para entender un poco mejor el escenario vamos a poner un ejemplo:

Supongamos que tenemos una aplicación financiera que se va a utilizar entre otros roles, por oficiales de servicio al cliente. Considerando que los agentes de servicio al cliente ya utilizan un CRM, no existe necesidad de parte de la institución de tener dos aplicaciones corriendo y poniendo a la agente a digitar en dos lados distintos con una alta posibilidad de error, además de incrementar la superficie de ataque ( a nivel de seguridad ). Es casi seguro que la solución óptima y que atraerá más a los clientes es el poder desarrollar sobre el CRM las interfaces contra la aplicación recién adquirida, lo cual justifica el uso de servicios para que al final solo sea pintar pantallas y consumir servicios.

Y entonces cuál es el rol de una arquitectura orientada a servicios? SOA nos va a permitir integrar nuestras aplicaciones sin importar la plataforma, y para ganarme esa versatilidad en la integración puedo darme el lujo de tener esa latencia en la transacción.

El escenario antes descrito desde el punto de vista de arquitectura se puede ver en la siguiente figura:

¿Que tecnologías debo utilizar?

En una arquitectura de dominio desarrollada en tecnologías microsoft lo mejor es utilizar el Windows AppFabric y el Service Bus de Windows – tema a tratar en otro post. En una arquitectura SOA si la tecnología que se utiliza es microsoft lo recomendado es utilizar Biztalk Server.

Technorati Tags: SOA,Arquitectura de Dominio

BPM y Workflow Foundation – Parte 1

Mucho se habla en estos días de la implementación de procesos de negocio utilizando BPM’s, y con este aparecen muchos “toolsets” para implementar BPMs en el negocio. ¿Pero qué es un BPM?¿Qué características tiene?¿Qué NO es un BPM?¿Puedo implementar un BPM en tecnologías Microsoft? Esta es una nueva serie de post orientadas a clarificar – o desenredar – un poco más el tema de los BPMs.

¿Qué es un BPM?

BPM – Business Process Management -  es la especialidad para el modelaje, automatización, administración, monitoreo y optimización de un proceso de negocios para aumentar su flexibilidad, su eficiencia, y su eficacia. En esta definición hay que destacar que BPM es una especialidad o disciplina y no una tecnología o herramienta. BPM no es solo software, si no que también la gente juega un rol muy importante; de hecho, la diferencia más importante entre un workflow y un BPM es que el BPM va más allá de la simple automatización de tareas para ayudar a la gente a llevar a cabo tareas de forma repetitiva.

Características de un BPM

Un BMP tiene cuatro características principales que vamos a discutir en esta sección:

1. Un BPM tiene un designer: Todo BPM debe de tener un modelador de procesos visual que permita implementar el proceso de forma práctica y con rapidez.Hay que recordar que una de las ventajas de llevar a cabo BPMs es que son flexibles y permiten cambios de forma rápida, sin un diseñador esto sería una tarea prácticamente imposible.
2. Un BPM tiene un motor de ejecución: Los BPMs corren sobre un motor de ejecución que se encarga de su ejecución de forma automática. Este motor se encarga entre otras cosas de persistir o cargar el proceso de acuerdo a las condiciones de su ejecución.
3. Un BPM se puede monitorear: Todo BPM tiene que ser monitoreable, es decir debo saber que sucede con el mismo. Esto incluye saber si el proceso se completó, si está suspendido, o tuvo algún error, etc.
4. Un BPM se puede optimizar: Todo BPM tiene la posibilidad de ser optimizado. Esto normalmente se logra con herramientas que permiten hacer simulación de procesos para verificar que sucedería si se le cambia, agrega o se le quita algo al proceso.

¿Qué no es un BPM?

Existen muchas herramientas en el mercado que se venden como herramientas BPM pero en realidad son flujos de trabajo básicos que dependen de la interfaz de usuario para poder ser utilizados. Un BPM no depende de ningún tipo de interfaz gráfica y puede ser activado desde una página Web, un servicio (Web o no), un servicio del sistema operativo, una aplicación de escritorio etc. Si un flujo de trabajo depende de una interfaz o de algún tipo de tecnología de presentación entonces no se considera un BPM, ya que ningún flujo de trabajo sin que haya tecnología de por medio depende intrínsecamente de la forma de activarse o de proseguir con una actividad determinada.

¿Existen BPMs en tecnologías Microsoft?

Esta pregunta es muy común cuando se habla de arquitectura de software y la empresa hace sus desarrollos en .NET. Considerando las cuatro características anteriores podemos decir que tenemos una solución BPM si utilizamos Workflow Foundation y el AppFabric. En este contexto, el workflow Foundation tiene un designer en Visual Studio –bastante completo por cierto – ,  puedo ejecutar los procesos en el motor de workflows de WF y por último con el AppFabric obtengo monitoreo, seguimiento y persistencia del Workflow. La única característica que no se cumple con el WF es la optimización del proceso, puesto que no existe una herramienta dentro del stack de Microsoft para llevar  a cabo esta tarea –> que basándome en mi experiencia es muy poco utilizada (He visto muy pocas empresas invertir en simulación de procesos para la optimización de los mismos, pese a que las herramientas que lo utilizan si lo permiten).

¿Y Biztalk Server?

Biztalk Server es un servidor de EAI –> Enterprise Application Integration –> y los wokflows que se construyen en él son workflows de integración. Biztalk Server al igual que WF tiene un diseñador, un motor de workflow y tiene monitoreo para los mismos. Sin embargo, la naturaleza de los workflows de Biztalk está dirigida hacia integrar aplicaciones a través de adaptadores permitiendo que los protocolos de comunicación y los formatos de los mensajes puedan ser dispares entre aplicaciones. Básicamente los workflows de WF son para dominios únicos de aplicación ( integración entre componentes del propio dominio ) y los workflows de Biztalk Server son para dominios externos en combinación con el dominio propio ( Integrar componentes de diversos dominios de aplicación).

Etiquetas de Technorati: WF,Biztalk,BPM

Biztalk: Error WCF-SqlAdapter–> The requested operation could not be performed because OLE DB provider does not support the required transaction interface

Trabajando en un proyecto con Biztalk server 2010 y los adaptadores WCF para sql server me encontré con un error muy interesante y algo complejo de comprender –> no de arreglar como sucede con la mayoría de los errores.

El problema

Resulta que estaba integrando equipos mainframe a través de un linked server con Biztalk Server. Cuando hacia consultas a los equipos mainframe la transacción funcionaba perfectamente, pero cuando la transacción tenía que modificar alguna entidad del mainframe entonces obtenía el siguiente error:

The requested operation could not be performed because OLE DB provider  does not support the required transaction interface

Haciendo un esfuerzo de memoria en domingo, recordé que cuando uno utiliza linked servers contra equipos contra los que no se puede realizar transacciones distribuidas de forma automática, se debe configurar el proveedor –> en este caso OleDB –> para que no intente la operación con una interface para obtener la transacción. Esto se logra de manera simple a través de la pantalla de configuración del proveedor y marcando la opción “non transactions updates”.

Sin embargo seguía dando el mismo error en el servidor. Luego de un par de pruebas supuse que el error de configuración podría estar en el endpoint del servicio que se conectaba al linked server del lado de Biztalk, especificamente en el binding. Abriendo la configuración del adaptador pude ver que la configuración para la transacción de ambiente estaba en verdadero, lo cual por supuesto en una transacción distribuida eleva la transacción para que sea manejada por el  DTC y este obliga a todos los involucrados en la transacción a votar en la operación. Siendo que el mainframe contra el que estábamos interactuando no soporta el tipo de interface que solicitaba el DTC, se debió establecer esta propiedad en false y listo …problema solucionado  

 

Etiquetas de Technorati: Biztalk,WCF-Adapter,useAmbientTransaction

SQL Adapter Wizard Desaparece Generando Orquestación: Biztalk Server 2010

Me encontré con un errro atípico en Visual Studio 2010 a la hora de generar una orquestación a partir de un procedimiento almacenado. Resulta que cuando estaba generando la orquestación el Wizard se cerraba y no se generaba nada ni aparecía ningún mensaje de error error. Luego de “Googlear” en “Bing” el error logre dar con el problema.

Resulta que el wizard se estaba cerrando porque tenía una instalación corrupta del SQLXML 4.0 SP 1 el cual es necesario para generar los tipos desde SQL Server y así poder generar los esquemas con los que Biztalk Interactúa con la base de datos. Al final la solución es reinstalar el SQLXML que esta disponible en el archivo CAB de los redistribuibles para instalar Biztalk Server 2010, los cuales pueden obtenerse desde acá – muy buena referencia por cierto.

El archivo a instalar es el siguiente:

Espero les ayude

Technorati Tags: Biztalk,SQLAdapter

Error Configurando el Enterprise SSO con Biztalk Server 2009

Resulta que tenía una instalación de Biztalk Server 2009 en mi máquina con Vista Enterprise y Visual Studio 2008 la cual funcionaba perfectamente – en especial para demos o pruebas antes de llevar la orquestación a producción. Por una razón de negocio, tuve que desinstalar el Biztalk SErver 2009 de mi máquina por un tiempo, y por lo tanto desinstalar el SSO. Hoy trato de instalar Biztalk en mi máquina de nuevo y me encuentro con el siguiente error de configuración

“Failed to connect to SQL Database SSODB”

Resulta que aunque reinstalé el SSODB – que es necesario para la configuración de Biztalk, no me permitía seguir con la configuración del servidor y me pedía que configurara correctamente el SSODB.

Después de luchar un poco – desinstalar un par de veces – y buscar en la web, me encontré que lo que sucedía era que tenía que registrar de nuevo el componente de SSO llamado SSOSQL.DLL – el cual estaba registrado con la configuración anterior – y listo. Tal y como se ve en la siguiente figura, para registrarlo se utiliza el comando regasm ssosql.dll.

Una vez registrado, el Enterprise SSO se configura correctamente y la configuración de Biztalk Server continúa normalmente.

Technorati Tags: Biztalk Server,SSO

Alternativas para Iniciar con una Arquitectura Orientada a Servicios - SOA

Cuando en una empresa se habla de establecer una arquitectura orientada a servicios surgen muchas dudas respecto a como implementar este tipo de arquitectura. Una de las primeras preguntas que me hacen dentro de la organización cuando llego a ayudar en este tipo de tareas es:

Pero si al prinicipio vamos a tener unos cuantos servicios, por que tenemos que comprar un ESB, que por lo general cuesta mucho dinero.

Efectivamente, una de las principales limitantes a la hora de implementar una arquitectura orientada a servicios – aparte de las limitaciones técnicas – es la compra del software requerido para poder iniciar en SOA.

Normalmente, las empresas empiezan teniendo unos pocos servicios Web, los cuales brindan información ya sea a lo interno o a lo externo; estos servicios se hostean en el IIS. Aunque suene tentador, el hecho de tener solamente servicios web que son consumidos por clientes internos y externos, no implica que tengamos una arquitectura SOA; en realidad estamos creando una arquitectura punto a punto, en donde los clientes consumen directamente los servicios expuestos y quedan totalmente dependientes de la configuración de estos servicios; ya que por ejemplo, si cambian el servidor donde se hostean estos servicios, los clientes tienen que ser actualizados o no funcionarán del todo.

Ahora, conforme crecen la cantidad de servicios que estamos utilizando, empieza a crearse la necesidad de darles seguimiento, de tener un inventario para saber cuales servicios tengo disponibles y puedo reutilizar, de tener métricas de los servicios para poder medir mis SLAs con otros clientes, y muchas otras características típicas de una arquitectura SOA las cuáles nos indican que es hora de ir pensando en un ESB – ver el post de ESB para entender más a fondo que es un ESB – La pregunta que surge es ¿ Cuando debo migrar a un ESB ? ¿por que tengo que pasar de un modelo donde solo tengo que preocuparme por el IIS a un modelo donde tengo que tener otro servidor y debo comprar Biztalk Server y agregarle el ESB guidance? ¿ Por qué no existe un paso intermedio entre ambos, que me de el Governance necesario para poder iniciar con mi arquitectura SOA para poder demostrarle a la gerencia los beneficios de esta arquitectura?

Estas preguntas son totalmente válidas y aplican practicamente en cualquier tecnología sobre la cual estemos interesados en “montar” una arquitectura orientada a servicios. En general cuando me hacen este tipo de preguntas, me pregunto por que no existe un contenedor liviano para ese tipo de soluciones.

Pues resulta que ahora, el equipo de Microsoft Services SOA Solution Team ha creado un producto que viene a llenar ese vacío. Este producto es algo así como el paso intermedio entre la arquitectura punto a punto y la arquitectura SOA en toda su expresión, utilizando un ESB, orquestando servicios y todos los demás beneficios que vienen con una arquitectura orientada a servicios – bien aplicada. Esta herramienta esta en versión CTP y se llama el Microsoft Service Engine – MSE. Esta herramienta es una herramienta para facilitar la adopción de SOA en la empresa, todo a través de algo que se conoce como virutalización de servicios. El MSE esta construida sobre WCF y la plataforma de Windows Server. Se integra de forma natural con Biztalk y el ESB Guidance para cuando en etapas posteriores se desea aumentar la capacidad de governance, ruteo, transformación, etc.

El siguiente screen shot es una muestra de este tool.

Este tool tiene otras 2 ventajas externas a lo técnico: Es Open source y es gratis. El sitio web donde se puede obtener información al respecto esta aquí en codeplex.

En post posteriores voy a profundizar acerca de las funcionalidades de esta herramienta, como configurarlo y como ponerlo a funcionar para poder adoptar una arquitectura SOA dentro de nuestras organizaciones.

Technorati Tags: MSE,SOA,ESB,C#

¿Qué es un ESB – Enterprise Service Bus?

Cuando se habla de arquitecturas orientadas a servicios, se habla intrínsicamente de los componentes necesarios para tener una arquitectura SOA. Sin duda alguna, uno de los componentes más importantes de una arquitectura orientada a servicios es el Enterprise Service Bus - ESB.

Conforme las organizaciones van moviéndose hacia las arquitecturas orientadas a servicios, se dan cuenta que están trabajando con un “mix” entre lo nuevo y lo viejo. Un ESB es básicamente la integración de lo nuevo y lo viejo, brindándo un lugar central para los servicios, las aplicaciones, y recursos de TI en general que se desean conectar. En otras palabras, lo que se busca es una infraestructura y un sistema de eventos que me permitan conectar cualquier recurso de TI sin importar la tecnología que utiliza el recurso. Esta infraestructura debería permitir administrar los cambios en los requerimientos sin causar problemas a los servicios ya instalados. Esta infraestructura debe de ser confiable y robusta. Aquí es donde entra el concepto de ESB.

Un ESB no solamente permite combinar y re ensamblar servicios, sino que también debe permitir conectar nuevas aplicaciones, servicios web y cualquier otro tipo de aplicaciones tales como aplicaciones LOB ( Line of Business ), archivos batch, legacy middleware a través de adaptadores; todo esto manteniendo la abstracción del manejo de mensajes a través del patrón publicar-suscribir.

Siendo más concretos, podemos decir que un ESB ofrece las siguientes funcionalidades:

• Transparencia de Ubicación: El ESB ayuda a desligar el consumidor del servicio de la ubicación del proveedor del servicio. El ESB provee una plataforma central para comunicarse con cualquier aplicación requerida sin ligar el recibidor del mensaje con el que envía el mensaje.
• Conversión de Protocolo de Transporte: Un ESB debe de tener la capacidad de integrar de forma transparente a través de diferentes protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP, etc.
• Transformación de Mensaje: El ESB brinda funcionalidad para transformar mensajes desde un formato hasta otro formato basado en estándares tales como XSLT y XPath.
• Ruteo de Mensajes: El ESB determina el destino de los mensajes entrantes.
• Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar información faltante basado en los datos del mensaje de entrada.
• Seguridad: Autenticación, autorización, y funcionalidad de encriptación se proveen a través del ESB para asegurar los mensajes entrantes. Igualmente estas funcionalidades se aplican a mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a consumir.
• Monitoreo y Administración: Un ambiente de monitoreo y administración del ESB es fundamental para configurar el ESB para que sea confiable y tenga un alto desempeño; al mismo tiempo, nos permite monitorear la ejecución de los mensajes y su flujo dentro del ESB.

La siguiente figura nos muestra un “big picture” de lo que es un ESB.

Dadas estas funcionalidades de un ESB, ¿cuándo necesito utilizar un ESB?

Conforme las organizaciones van adoptando servicios, se va creando la necesidad de una arquitectura orientada a servicios. Hay una gran diferencia entre el uso casual de servicios y llevar la organización a correr sobre servicios. Conforme se avanza hacia una arquitectura orientada a servicios, van a surgir muchos contratiempos, entre los cuales podemos enumerar como manejar una gran cantidad de servicios de una manera adecuada evitando la duplicación de funcionalidad, como medir y forzar los SLA´s –Service Level Agreement –, como forzar politicas organizacionales dentro de la colección de servicios que se tiene y a la cual se le van agregando servicios.

Además, en el mundo Microsoft existe WCF, el cual es un framework excelente para comunicaciones distribuidas, pero es solo eso, un framework.

Normalmente, cuando se empiezan a tener una cantidad de servicios que deja de ser pequeña y más bien podríamos considerarla de mediana a grande, se empiezan a tener problemas que no se tenían cuando solamente se manejaban un grupo pequeño de servicios. Entre los problemas que se dan más comúnmente podemos enumerar proliferación de servicios por toda la organización sin control, los cuales utilizan diferentes protocolos y tecnologías para su desarrollo e implementación. No hay governance, las configuraciones no son estándar, no hay versionamiento de servicios, etc. Cuando se empiezan a tener este tipo de problemas, y la organización empieza a dar un paso más serio hacia el uso de servicios como plataforma para sus aplicaciones, se empieza a necesitar más y más una arquitectura orientada a servicios.