Una vez que extendemos el uso de Biztalk Server en la organización y lo utilizamos para resolver un conjunto de desafíos extenso, es normal que exista un equipo de desarrolladores o hasta varios equipos que generan soluciones para la plataforma.

Más allá de la obvia necesidad de acordar en el modelo de desarrollo, es necesario trabajar de acuerdo a las "mejores prácticas" para cada caso, incluso cuando estas mejores prácticas no solamente incluyen "mejores prácticas" para el producto, sino "mejores prácticas" para la organización.

Capturar esto en el momento de creación de los artefactos de software es fundamental, y todo aquello que nos lleve a representarlo no solamente en el papel y los manifiestos de estándares, sino en la herramienta de desarrollo, adquiere gran valor.

En este sentido, Biztalk Server Pattern Wizard (http://www.codeplex.com/PatternWizard/) es un utilitario que permite capturar las decisiones de uso de un determinado patrón o conjunto de patrones en una plantilla (template) de biztalk que mediante interacción con el desarrollador puede generar un esqueleto completo de la solución de orquestación a generar.

Debo confesar que al principio estaba escéptico, pero luego de verlo funcionar y extenderlo para un ejemplo propio, creo que es una herramienta fundamental en el desarrollo "ordenado" con Biztalk Server.

Su uso es simple: tenemos una solución de ejemplo de lo que queremos "padronizar", un asistente que forma parte del propio wizard, genera los archivos para poder generar nuevas soluciones a partir de la solución de ejemplo; estos archivos son representaciones XML de los archivos originales, que deben modificarse de manera de poder sustituir aquellos artefactos que cambiarán en cada una de las instancias de la solución. Luego catalogaremos los diferentes diálogos (páginas del asistente) que pedirán los datos a sustituir en la solución original, esto puede ser cualquier cosa, un mapa, un esquema, una referencia, etc; no hay límite, aunque están implementadas páginas del asistente para un conjunto limitado de artefactos. De cualquier manera es fácil agregarlos; como ejemplo, el formulario que pide mapas no funcionaba, pero yo pude hacer un formulario que lo pide en menos de 30 minutos (si alguien lo quiere me manda un mail).

Hay videos de cómo usarlo y explicación de cada patrón de los que vienen pre-armados; pero también un video explicativo de cómo extenderlo que es realmente útil.

http://support.microsoft.com/?kbid=938194

http://support.microsoft.com/?kbid=938979

Uso sugerido: Se debe crear un proxy en una clase C# mediante "agregar referencia web" en el IDE y luego crear una clase "wrapper" que hereda de este proxy autogenerado y expone las primitivas necesarias para que se puedan agregar comportamientos desde el llamador (ej: agregar un certificado al proxy). Este wrapper se usará desde la orquestación en un Shape de tipo "Expression" donde se asignarán los parámetros de entrada, se hará el llamado al proxy y se tomarán los datos de salida.

Limitaciones: No se usa el SOAP adapter de Biztalk (y todo lo que esto implica, por ej: la imposibilidad de poder usar distintos hosts para el envío y recepción de los mensajes vía SOAP, la no configuración administrativa del adaptador, etc.)

Explicación:

El problema comienza (como dice el título) con que el WSDL que emite nuestro socio de negocios, no puede ser usado por el generador de proxy y webport. Esto sucede en muchas circunstancias, con varios tipos de WSDL ya documentados (ej: con arrays en los tipos).

¿Cómo funcionan el "add web referencce" en Biztalk?

Biztalk examina el WSDL y realiza las siguientes acciones:

1. Genera un proxy al estilo del proxy que genera un add web reference común (pero lamentablemente no es igual)
2. Genera un .odx "hidden" que tiene "message types" y "web port types" de acuerdo al WSDL examinado. Este .odx, además, en los ".NET types" usa los tipos del proxy referido en a)

(Nota: si quiere entender más de lo anterior, puede revisar ésta http://geekswithblogs.net/mtex/articles/68626.aspx entrada)

Estos tipos de web messages no es posible crearlos manualmente desde la interfaz, aunque pueden generarse multipart messages con la misma estructura que podrían usarse en puertos solicit-response asociados a SOAP, pero lo que no es posible en BTS2004 es asociar cual es el proxy al cual corresponden los tipos en el .odx.

Lo anterior sí es posible en BTS2006.

Utilizar el WSE adapter para BTS2004 no mejora las opciones dado que el WSE adapter utiliza gran parte del a infraestructura del SOAP adapter y le agrega funcionalidad, por lo que, la misma limitación que tenemos en este sentido en el SOAP adapter está en el WSE adapter en BTS2004.