BizTalkLATAM's Blog : Base de Conocimiento BTS 2006

Usando el adaptador de WSS

BizTalkLATAM — Wed, 30 Apr 2008 02:09:43 GMT

El adaptador de WSS es utilizado para enviar información desde BizTalk hacia liberias de SharePoint. Una de las funcionalidades que soporta el adaptador, además de enviar un mensaje como tal, es la posibilidad de asignar valores a columnas definidas en dicha libreria (ya sean nativas de Sharepoint o definidas por el usuario).

Estas columnas pueden ser especificadas de 3 formas:

La primera forma es especificando las columnas a las que se desea dar valores directamente en la configuración del puerto mismo, como muestra la siguiente figura:

Una segunda forma es definiendo las columnas programaticamente en una orquestación de BizTalk o un componente del Pipeline. Para esto, el adaptador de WSS soporta una propiedad del contexto del mensaje WSS.ConfigPropertiesXml, la cual contiene un XML con la definición y valores de las columnas:

strConfig = "<ConfigPropertiesXml>";
strConfig = strConfig + "<PropertyName1>Error Message</PropertyName1>";
strConfig = strConfig + "<PropertySource1>" + sDescription + "</PropertySource1>";
strConfig = strConfig + "<PropertyName2>Batch Size</PropertyName2>";
strConfig = strConfig + "<PropertySource2>" + sBatchSize + "</PropertySource2>";
strConfig = strConfig + "<PropertyName3>Invoice Number</PropertyName3>";
strConfig = strConfig + "<PropertySource3>" + sInvoice + "</PropertySource3>";
strConfig = strConfig + "</ConfigPropertiesXml>";
Msg(WSS.ConfigPropertiesXml) = strConfig;

La tercera opción es utilizar una combinación de ambos escenarios para definir las columnas: definir una parte de las columas en la configuración del puerto y otra parte en la orquestación. Se debe tener cuidado de no especificar una misma columna en ambos lugares para evitar conflictos, en el siguiente ejemplo se adiciona una columna al puerto estático de envío configurado en la primera opción.

strConfig = "<ConfigPropertiesXml>";
strConfig = strConfig + "<PropertyName4>Source</PropertyName4>";
strConfig = strConfig + "<PropertySource4>" + sSource + "</PropertySource4>";
strConfig = strConfig + "</ConfigPropertiesXml>";
Msg(WSS.ConfigPropertiesXml) = strConfig;

Esta última opción es muy util cuando una parte las columnas son relativamente estáticas, mientras que otra parte son dinámicas y bien sea las columnas mismas o sus valores solo pueden ser calculados en tiempo de ejecución.

Posters de BizTalk 2006

BizTalkLATAM — Tue, 18 Mar 2008 00:25:00 GMT

En la siguiente dirección pueden encontrar todos los posters que Microsoft ha generado para BizTalk 2006 R2 explicando todas sus características.

http://www.microsoft.com/biztalk/techinfo/guides.mspx

También existe un poster acerca de la arquitectura en BizTalk 2006 y puede ser descargado aquí

Un escenario de mensajeria sin orquestaciones

BizTalkLATAM — Wed, 23 Jan 2008 18:19:44 GMT

En ocasiones es necesario utilizar BizTalk Server para un escenario de mensajería el cual debe consultar información a una aplicación externa y luego enviar ésta a otra aplicación externa sin necesidad de aplicar alguna logica de negocio durante su proceso.

En ocasiones se utilizan orquestaciones en este tipo de escenarios lo cual algunas veces puede resultar innecesario. Para ilustrar esta situación se puede tomar el ejemplo HTTPSolicitResponse que viene en SDK de BizTalk Server 2004/2006/2006r2. HTTPSolicitResponse muestra una forma de cómo usar BizTalk Server para consultar un servicio HTTP y luego enviar la respuesta el FileSystem. Los artefactos usados en esta solución son:

Un Receive Port llamado HTTPSolicitResponseReceivePort que recibe la información desde el FileSystem
Una orquestacion que procesa la información
Un Send Port llamado HTTPSolicitResponseTwoWayPort que envía hace la petición al servicio HTTP
Un Send Port llamado HTTPSolicitResponseSendPort que envía el resultado al FileSystem

Sin embargo, en su ejecución esta solución utiliza más recursos de los estrictamente necesarios, debido aque se usa una orquestacion como enrutadora sin procesar ningun tipo de proceso de negocio real tal como puede observar en la siguiente figura.

De acuerdo a la arquitectura de BizTalk Server (ver figura) todos los mensajes deben pasar por el MessageBox para poder ser instanciados por las orquestaciones o puertos de envio.

Mejorando la solución

Para mejorar el performance de la solución podría eliminarse la orquestación lo que permitiría reducir su ejecución a los siguientes pasos:

1. HTTPSolicitResponseReceivePort envía el mensaje a MessageBox

2. HTTPSolicitResponseTwoWayPort recibe el mensaje desde MessageBox y envía la solicitud HTTP, una vez recibe la respuesta vuelve a enviar el mensaje a MessageBox

3. HTTPSolicitResponseSendPort recibe el mensaje desde la MessageBox y lo envía al FileSystem

De igual forma, al eliminar la orquestación el gráfico de arquitectura también sería modificado así.

El nuevo escenario presenta estas ventajas:

1. Se evita una ejecución innecesaria de la orquestación

2. Menor utilizacion del MessageBox, lo que significa menor consumo de recursos

Para lograr este nuevo escenario se debe configurar los puertos de salida (Send Ports) para que sean instanciados una vez el mensaje el publicado en el MessageBox. A continuación se muestra la forma de como configurar la nueva solución:

1. Poner en estado Unenlist la orquestación MultiplyTwoIntegers

2. Editar las propiedades del Send Port llamado HttpSolicitResponseTwoWayPort y establecer este filtro:

BTS.ReceivePortName == HttpSolicitResponseReceivePort

3. Editar las propiedades del Send Port llamado HttpSolicitResponseSendPort y establecer este filtro:

BTS.SPName == HttpSolicitResponseTwoWayPort

4. Probar el nuevo escenario copiando el archivo en la carpeta de recepción

También se puede hacer undeploy del assembly HttpSolicitResponse.dll y probar nuevamente. Sin embargo, al realizar este cambio también se debe cambiar los pipelines utilizados en los puertos de la siguiente forma:

1. Los pipelines XmlReceive por PassThruReceive en el Receive Location HttpSolicitResponseReceiveLocation y en el Send Port HttpSolicitResponseTwoWayPort

2. Los pipelines XmlTransmit por PassThruTransmit en los Send Ports HttpSolicitResponseTwoWayPort y HttpSolicitResponseSendPort

El anterior cambio sería necesario ya que los pipelines Xml* generarían un error al procesar los mensajes intentando obtener su MessageType desde la BizTalkMgmtDb.

Conclusión

Lo anterior indica que NO se deberia utilizar orquestaciones que solo sirvan como reenrutadoras de la informacion y NO ejecuten alguna logica de negocio real en un escenario de mensajeria.

De igual forma estos escenario de mensajeria se pueden utilizar para consultar información a SQL Server con el adaptador de SQL, consultar un Servicio Web usando el adaptador de SOAP (ver ejemplo Consumming Web Services with Messaging-Only Scenario), u otro escenario de estas características.

Cuidado al construir multiples mensajes con XmlDocument

BizTalkLATAM — Tue, 15 Jan 2008 01:32:18 GMT

Una de las técnicas utilizadas para definir mensajes al desarrollar orquestaciones es usar objetos System.Xml.XmlDocument. Sin embargo, es necesario tener cuidado al momento de utilizar el mismo objeto para definir mas de un mensaje usando un sólo "Construction Shape" ya que los mensajes pueden no almacenarse en la base de datos con la información esperada.

El siguiente escenario (ver figura) pretende explicar con más detalle lo comentado.

En la figura se observa como la orquestación construye dos mensajes: Msg2 y Msg3, usando el mismo "Construction Shape" y para ambos mensajes usa el mismo objeto xmlDoc de tipo System.Xml.XmlDocument. Asi, en el primer Message Assigment Shape el siguiente codigo define el Msg2:

// carga xml y asigna el Msg2
xmlDoc.LoadXml("<Root><Field>Field_2</Field></Root>");
Msg2 = xml;

Y en el segundo Message Assigment Shape este codigo define el Msg3:

// carga xml y asigna el Msg3
xmlDoc.LoadXml("<Root><Field>Field_3</Field></Root>");
Msg3 = xml;

En teoria el resultado deberia ser dos archivos diferentes, sin embargo el resultado al ejecutarse la orquestación no es el esperado ya que ambos archivos contienen la misma informacion.

Este inconveniente se debe a dos razones:

El mensaje de BizTalk guarda una referencia al objeto XmlDocument asignado.
El objeto XmlDocument fue modificado en el mismo Construction Shape por lo que no fue posible hacer persistente el mensaje.

Por lo tanto, el objeto xml que se utilizo para definir el Msg2 fue modificado para construir el Msg3 antes de que el mensaje Msg2 se hiciese persistente. Esto ocasiono que el contenido de ambos mensajes en la base de datos sea el mismo.

Esta característica esta presente en las versiones de biztalk 2004/2006/2006r2.

Desplegando soluciones de BTS usando Targets

BizTalkLATAM — Wed, 21 Nov 2007 19:18:45 GMT

Una de las principales características al crear archivos .MSI para instalar aplicaciones de BizTalk Server 2006 en otros ambientes, es poder adicionar archivos de configuración (binding files) y especificar en cual ambiente van a ser utilizados.

Esta funcionalidad permite generar un solo instalador que sirve para los diferentes ambientes como desarrollo, precalidad, calidad, QA, y producccion, entre otros (depende de las politicas de la empresa).

Este proceso es sencillo, basta con adicionar un archivo de configuración como recurso desde la consola administrativa y especificar el ambiente (target) en el cual se quiere ejecutar.

De esta forma se pueden tener todos los archivos de configuración necesarios para los diferentes ambientes en un solo instalador.

Por último, al momento de importar el archivo simplemente se debe seleccionar el ambiente correcto para aplicar la configuración deseada.

Sin embargo, cuando se importa un archivo .MSI la configuración se aplica de acuerdo al siguiente orden:

Se crea la configuración generada automáticamente cuando se exporto el archivo .MSI. Esto si la aplicacion tenía puertos de envío, recepción, u otros.
Aplica los archivos de configuración que se adicionaron como recursos pero a los cuales no se especificó un ambiente (target).
Aplica los archivos de configuración de acuerdo al ambiente seleccionado.

Este orden de ejecución puede causar algunos inconvenientes en la instalación de la aplicación ya que se puede crear configuración como puertos de envios u otros en ambientes no deseasdos, p. ej. un ambiente de producción. Por lo tanto se recomienda tener en cuenta:

Cuando se exporte el archivo .MSI, asegurarse de no seleccionar la opcion Binding que se presenta en la ventana Select Resources. Esta opción indica que no se genere la configuración por defecto de la aplicación.

Especificar siempre un ambiente (target) a los archivos de configuración asociados como recursos, de esta forma la configuración siempre sera aplicada de acuerdo al ambiente seleccionado.

De esta forma no se tendran inconvenientes en el momento de la realizar los despliegues de las aplicacion de BizTalk Server 2006.

Autor: Carlos Medina
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

Donde puedo almacenar las BR?

BizTalkLATAM — Wed, 18 Jul 2007 07:29:58 GMT

BizTalk Server a través del Business Rule Engine (BRE) ofrece la posibilidad de almacenar las reglas de negocio (BR) implementadas en archivos xml o en bases de datos para su posterior invocación y ejecución. Cada almacenamiento ofrece sus ventajas y desventajas, y adicional su invocación difiere en cada uno.

Archivos XML

Una BR se puede almacenar e invocar desde un archivo plano usando la clase FileRuleStore.

void SaveToFile()
{
    RuleStore ruleStore = new FileRuleStore("filename");
    ruleStore.Save(new RuleSet("rulesetname"));
}

void LoadFromFile()
{
    RuleStore ruleStore = new FileRuleStore("filename");
    RuleSetInfoCollection rsInfo = ruleStore.GetRuleSets("rulesetname", RuleStore.Filter.Latest);
    RuleSet newRS = ruleStore.GetRuleSet(rsInfo[0]);
}

Este almacenamiento ofrece las siguientes ventajas:

No es necesario tener una base de datos (como SQL Server) para su almacenamiento y ejecución.
El instanciamiento de la BR es mas rápida ya que evita el acceso a la base de datos.
La BR puede ser modificada con un editor como Bloc de Notas (notepad) y no es necesaria su publicación (publish) y despliegue (deploy) posterior.

Las desventajas son:

Estas BR no pueden ser invocadas desde un orquestación con el Call Rules Shape, sólo desde .net assemblies utilizando la clase FileRuleStore.
Si una BR va a ser accedida por varias aplicaciones se debe copiar el archivo en una ruta compartida o crear una copia en cada aplicación.
No se puede editar con el Business Rule Composer.

Base de datos

Una BR puede ser almacenada e invocada desde una base de datos usando las clases SqlRuleStore o OleDbRuleStore

using Microsoft.BizTalk.RuleEngineExtensions;

static void DeployRuleSet(RuleSet ruleset)
{
    RuleSetDeploymentDriver dd = new RuleSetDeploymentDriver();
    SqlRuleStore sqlrs;
    sqlrs = (SqlRuleStore) dd.GetRuleStore();

    sqlrs.Add(ruleset, true);
    dd.Deploy(new RuleSetInfo(ruleset.Name, 
            ruleset.CurrentVersion.MajorRevision, ruleset.CurrentVersion.MinorRevision));
}

static void GetRuleStore(string rulesetname)
{
    RuleSetDeploymentDriver dd = new RuleSetDeploymentDriver();
    SqlRuleStore sqlrs = (SqlRuleStore) dd.GetRuleStore();

    RuleSetInfoCollection rss = new RuleSetInfoCollection();
    rss = sqlrs.GetRuleSets(rulesetname, RuleStore.Filter.Latest);
}

Las ventajas de utilizar una base de datos se enumeran en:

Las BR quedan almacenadas en forma centralizada, por lo tanto las aplicaciones que la consuman tendran siempre un repositorio único
Se puede utilizar el Business Rule Composer para administrar las BR, publicarlas (publish) o desplegarlas (deploy).
La BR puede ser invocada desde un .net assembly utilizando las clases provitas por el framework de BRE.
Las BR pueden ser invocadas desde orquestaciones usando Call Rules Shapes.

Las desventajas son:

El instanciamiento inicial de la BR puede ser lenta dependiendo de la conexion a la base de datos
Se debe tener una base de datos para el almacenamiento de las BR
La administracion y modificaciones a las BR tienen que hacerse por medio de un editor de BR, ejemplo el Business Rule Composer.

En ambos casos se puede exportar facilmente una BR de un archivo xml a la base de datos y viceversa, para ello se puede utilizar el framework de BRE o el Business Rule Engine Deployment Wizard que provee BizTalk Server.

Autor: Carlos Medina
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

Error: Compiler for file type '*.btm' failed

BizTalkLATAM — Tue, 08 May 2007 07:42:00 GMT

Sintoma

Tu recibes el siguiente error al tratar de compilar proyectos de BizTalk Server 2006 que contienen mapas:

Error: Build failed. Compiler for file type '*.btm' failed. Unable to load wrapper:C:\Program Files\Microsoft BizTalk Server 2006\Developer Tools\Mapper Extensions\Microsoft.BizTalk.Security.SSPI.dll.

Solución

El assembly Microsoft.BizTalk.Security.SSPI.dll está por defecto registrado en el GAC y el compilador de BizTalk Server 2006 lo carga desde allí, por lo tanto es necesario eliminar la copia de éste assembly de la carpeta %install_bts%\Developer Tools\Mapper Extensions\.

Autor: Carlos Medina
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

BizTalk Services CTP

BizTalkLATAM — Tue, 24 Apr 2007 18:49:37 GMT

Microsoft ha liberado BizTalk Services CTP al público, BizTalk Services es una nueva propuesta de Microsoft ofreciendo integracion de servicios como Identity Services y Connectivity Services con BizTalk Server inicialmente; otros servicios como ServiceBus Services y Workflow Services aún no estan disponibles.

Más información acerca de los servicios y el SDK para desarollo puede ser descargado desde http://labs.biztalk.net.

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

BizTalk Server R2 Beta 2

BizTalkLATAM — Tue, 03 Apr 2007 16:53:00 GMT

Microsoft ha liberado BizTalk Server 2006 R2 Beta 2, este nuevo build corrige muchos de los problemas encontrados en las versiones anteriores y contiene todo el motor de ejecución de BizTalk Server, templates para Visual Studio, interceptor para BAM, soporte a RFID y EDI, BizTalk Accelerators para HL7, SWIFT y RosettaNet, LOB Adapters, y documentacion y ejemplos acerca del producto, entre otros.

Adicionalmente, una nueva versión del Net Lob Adapter ha sido liberado correspondiente a la versión Beta 2. En esta nueva versión se podrán descargar los adaptadores para Siebel, SAP y Oracle, además de encontrar el SDK para el desarrollo de adaptadores WCF para BizTalk Server.

Estas nuevas versiones se pueden descargar desde BizTalk Server 2006 R2 Program. Anteriormente todas estas versiones solo podían se accedidas por usuarios registrados, pero ahora Microsoft ha puesto el programa de BTS R2 publico, y si aún no estas registrado puedes seguir los siguientes pasos para bajar BTS y comenzar a probarlo:

Ve a la direccion http://connect.microsoft.com/
Ingresa utilizando tu cuenta passport
Selecciona la opcion Available Connections en el menu Connect Home
Revisa la tabla de Programs que alli aparece
Selecciona el programa BizTalk 2006 R2 Beta

De igual forma ya existen foros públicos acerca de BizTalk Server 2006 R2, mas información en BizTalk Server 2006 R2 Forums.

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

BizTalk Server 2006 en PDF

BizTalkLATAM — Wed, 28 Mar 2007 15:38:00 GMT

Con un tamano de casi 120 mb y mas de 15 mil paginas, Microsoft ha publicado en formato PDF la documentacion de BizTalk Server 2006. Esta nueva documentacion puede ser descargada desde Microsoft BizTalk Server PDF.

BizTalk Server 2006 R2 y WCF

BizTalkLATAM — Wed, 28 Feb 2007 21:15:00 GMT

Con el lanzamiento de WCF una nueva generacion de como los desarrolladores implementan software y luego es expuesto como servicio a otros aplicativos (service-oriented applications) se ha ido desarrollando, por ello y como estaba anunciado, la proxima version de BizTalk Server 2006 (llamada BizTalk Server 2006 R2) tendra soporte para WCF. En este soporte se incluyen nuevos adaptadores para el acceso a servicios WCF existentes, un framework para desarrollar adaptadores como WCF, y herramientas para los desarrolladores puedan referenciar servicios WCF desde y hacia BizTalk Server.

A continuacion se hara un enumerado de las nuevas caracteristicas en BizTalk Server 2006 R2 referente a WCF:

.Net 3.0 Adapter Framework

El .Net 3.0 Adapter Framework esta dirigido al desarrollo de adaptadores para sistemas LOB, este nuevo framework proveen un conjunto de clases que facilitan la implementacion de nuevos adaptadores que seran expuestos a terceros como canales de Windows Communication Foundation.

.Net 3.0 Adapter Development Wizard

Es un asistente integrado a Visual Studio 2005 que permite a los desarrolladores generar facilmente la estructura inicial de nuevos adaptadores que seran expuestos como canales de WCF.

Consume WCF service

BizTalk Server 2006 R2 adiciona una extension a los proyectos de BizTalk Server 2006 en Visual Studio 2005 para adicionar referencias a servicios de WCF, como actualmente sucede con Web Services. Al adicionar la referencia automaticamente se generaran los esquemas que soportan los mensajes y archivos de binding necesarios en la creacion de los puertos.

WCF Adapters

BizTalk Server 2006 R2 tiene 7 adaptadores por defecto que se instalan y configuran automaticamente, estos son: WCF-BasicHttp, WCF-Custom, WCF-CustomIsolated, WCF-NetMsmq, WCF-NetNamedPipe, WCF-NetTcp, WCF-WSHttp. Estos adaptadores pueden acceder a servicios expuestos en WCF en los canales especificados por cada uno de ellos.

BizTalk WCF Service Publishing Wizard

BizTalk Server 2006 R2 provee la posibilidad de exponer las orquestaciones como servicios de WCF, tal como se hace actualmente para exponer una orequestacion como Web Service.

Add Adapter Reference...

Permite adicionar referencias de adaptadores expuestos como canales de WCF (desarrollados con el .Net 3.0 Adapter Framework) a proyectos de Windows desarrollados con C# o Visual Basic .Net.

Este es un pequeno listado de lo nuevo en BizTalk Server 2006 R2 y WCF, en publicaciones posteriores se daran mas detalles de como utilizar cada uno de estas caracteristicas.

Autor: Carlos Medina
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

Procesando diferentes tipos de archivos en el mismo receive location

BizTalkLATAM — Fri, 23 Feb 2007 15:31:00 GMT

Cuando se usa el adaptador FILE (u otros adaptadores) en BizTalk Server no es posible procesar diferentes tipos de archivos texto (flat-file) nombrados de igual forma en la misma ruta. Esta restriccion se da porque no se pueden configurar varios receive locations con el adaptador FILE que lean de la misma ruta los archivos, ya que al procesarlos el adaptador bloquea los archivos prohibiendo que otros procesos (incluidos otros receive locations) accedan al contenido del archivo.

Actualmente en BizTalk Server 2006 se puede resolver este inconveniente, basta con enviar todos los mensajes a una misma orquestacion (orchestration) y usando el metodo XLANGPipelineManager.ExecuteReceivePipeline evaluar el mensaje con diferentes tipos de documentos previamente configurados en Custom Pipelines.

Pero esta solucion no es posible en BizTalk Server 2004 ya que el metodo XLANGPipelineManager.ExecuteReceivePipeline no existe. Sin embargo, si es posible desarrollar un Custom Pipeline Component que valide un mismo archivo de texto recibido contra una coleccion de esquemas de archivos de texto (flat-file schemas) y generar un mensaje valido para redireccionarlo a la plataforma de integracion.

El nuevo componente debe implementar los metodos IProbeMessage.Probe, IDisassemblerComponent.Disassemble, y IDisassemblerComponent.GetNext que corresponden a las interfaces IProbeMessage y IDisassemblerComponents (necesarias para el desarrollo del componente) sobreescribiendo de esta forma la ejecucion del Custom Pipeline Component. Para mas informacion acerca de como desarrollar un Custom Pipeline Component visitar aqui, a continuacion se hara una breve descripcion del codigo utilizado. A continuacion se daran mas detalles del desarrolla de este componente.

Design Time Properties

Esta region implementa la propiedad publica por medio de la cual el usuario selecciona los tipos de documentos (flat-file schemas) a validar en tiempo de diseno. Los documentos se almacenan en la variable schemaList.

Pueden encontrar mas informacion de esta implementa aqui.

#region Design Time Properties
private SchemaList schemaList = new SchemaList();
public SchemaList DocumentSchemaList
{
get { return this.schemaList; }
set { this.schemaList = value; }
}
#endregion Design Time Properties

IProbeMessage and Private Members

El metodo IProbeMessage.Probe implementa la logica que recorre cada uno de los tipos de documentos previamente configurados en la variable schemaList. Por cada tipo de documento se invoca el metodo FFDisassembler quien valida el tipo de documento contra el contenido del archivo, y en caso de ser exitosa la validacion se almacenaran los mensajes de BizTalk resultantes en una nueva coleccion llamada baseMessages.

El codigo a continuacion presenta las varialbes privadas utilizadas y los metodos Probe y FFDisassembler.

#region IProbeMessage and Private Members
public bool Probe ( IPipelineContext pContext, IBaseMessage pInMsg )
{
bool isValid = false;

// probe the disassembler for-each messageType
foreach(Schema schema in schemaList)
{
    try
    {
      FFDisassembler(pContext, pInMsg, schema);
      goto EndProbe;
    }
    catch(Exception e)
    {
      System.Diagnostics.Trace.WriteLine(e.ToString());
      // create a NACK message
    }
}
// eval the isValid variable
if (!isValid)
    throw new ApplicationException("The message doesn't have a valid flat-file format");

EndProbe:
return true;
}

private object disassembler = null;
private ArrayList baseMessages = new ArrayList();
private int idxBaseMessages = 0;
private string XmlNormNamespaceURI = "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties"
private string DocumentSpecNamePropertyName = "DocumentSpecName"
private void FFDisassembler(IPipelineContext pContext, IBaseMessage pInMsg, Schema schema)
{
disassembler = new FFDasmComp();

string messageType = string.Format("{0}#{1}", schema.TargetNamespace, schema.RootName);
IFFDocumentSpec docDefinition = (IFFDocumentSpec) pContext.GetDocumentSpecByType(messageType);
string docSpecStrongName = docDefinition.DocSpecStrongName;
pInMsg.Context.Write(DocumentSpecNamePropertyName, XmlNormNamespaceURI, docSpecStrongName);
pInMsg.BodyPart.GetOriginalDataStream().Seek(0, SeekOrigin.Begin);

((FFDasmComp) disassembler).DocumentSpecName = new SchemaWithNone(docSpecStrongName);
((FFDasmComp) disassembler).Disassemble(pContext, pInMsg);

IBaseMessage baseMessage = null;
while ((baseMessage = ((FFDasmComp)disassembler).GetNext(pContext)) != null)
baseMessages.Add(baseMessage);
}
#endregion IProbeMessage and Private Members

IDisassemblerComponent

El metodo Disassemble no debe implementar ninguna logica, esto se debe a que previamente ya se habia hecho el desensamble del mensaje.

A continuacion, en el metodo GetNext se implementa la logica necesaria para retornar uno a uno los mensajes de la coleccion baseMessages y enviarlo automaticamente a la MessageBox para que continue su proceso.

#region IDisassemblerComponent
public IBaseMessage GetNext ( IPipelineContext pContext )
{
if (idxBaseMessages < baseMessages.Count)
return baseMessages[idxBaseMessages++] as IBaseMessage;
return null;
}

public void Disassemble ( IPipelineContext pContext, IBaseMessage pInMsg ) { }
#endregion IDisassemblerComponent

Este nuevo Custom Pipeline Component, puede ser utilizado en Custom Pipelines para las versiones BizTalk Server 2004 y 2006. Si desea el codigo fuente puede enviar un email aqui.

Autor: Carlos Medina
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningun derecho

Acerca de Pipelines en MSDN

BizTalkLATAM — Wed, 14 Feb 2007 09:56:48 GMT

En http://msdn.microsoft.com/biztalk se han publicado dos articulos acerca de la creacion y el diseno de Custom Component Pipelines

Understanding BTS Custom Pipeline Design-Time Properties

Escrito por Saravana Kumar, este articulo explica como utilizar tipos complejos (complex types), interfaces definidas por el usuario (custom user interfaces) y tecnicas de serializacion (serialization techniques) en propiedades de tiempo de diseno (design-time properties) al configurar Custom Pipeline Components en Custom Pipelines cuando estos son creados (Visual Studio) o una vez desplegados (Consola Administrativa). De igual forma, Saravana provee tips y procedimientos para diagnosticar errores al trabajar con propiedades en Custom Pipeline Components. Se puede bajar mas informacion aqui.

Removing Empty Elements with a Custom Pipeline

Este articulo trata el desarrollo de un Custom Component Pipeline que permita modificar el mensaje XML removiendo todos los nodos vacios que no esten excluidos (esta exclusion se da en la definicion misma del nodo), el articulo provee el codigo fuente escrito en Visual Basic.Net. Puedes bajar el contenido desde aqui.

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga

Extendiendo las Consolas de BizTalk Server 2006

BizTalkLATAM — Tue, 13 Feb 2007 07:36:35 GMT

Un nuevo articulo acerca de como extender las consolas adminitrativas que provee BizTalk Server 2006 (BizTalk Console Adminitrator y Enterprise Single Sign-On Console) ha sido publicado en technet.

"Al utilizar la consola administrativa en BizTalk Server 2004 (BTS2004) es común encontrar esta pregunta ¿no tiene más funcionalidad, no puedo agregar más funciones?, la respuesta es NO. La Consola Administrativa en BTS2004 expone pocas opciones de administración a los procesos de BizTalk Server (BTS), además de no permite extender su funcionalidad.

Por su parte, BizTalk Server 2006 (BTS2006) provee nuevas consolas administrativas que ofrecen más opciones de administración que sus antecesoras en BTS2004, las cuales pueden ser extendidas para agregar nueva funcionalidad. Este artículo explicará los requisitos para extender estas consolas."

En el articulo se exponen las tecnologias de desarrollo que se pueden utilizar de acuerdo a la consola a extender, asi como las claves necesarias para extender cada una.

El articulo original puede ser leido desde Extendiendo la Consola Administrativa en BizTalk Server 2006

BizTalk 2006 Context Accessor functoid

BizTalkLATAM — Tue, 13 Feb 2007 07:29:49 GMT

Marvin Smit, instructor de DevelopMentor, ha desarrollado un nuevo componente para BizTalk Server que permite acceder a propiedades del contexto de un mensaje desde un mapa. A diferencia del ya existente functoid "GetContextProperty Functoid Workspace" (que tambien provee la misma funcionalidad), este nuevo componente es utilizado en mapas que se ejecutaran en la recepcion de mensajes desde los puertos de entrada (reveice ports).

El Context Accessor provee dos Custom Components que deben ser utilizados para acceder a las propiedades:

Custom Pipeline Component

Por medio de este Custom Pipeline Component configurado previamente en un Custom Pipeline, el functoid podra accesar al contexto de ejecucion del puerto de recepcion.

Custom Functoid

Este componente representa el functoid que debera ser utilizado desde el mapa para obtener el valor de la propiedad de contexto. Este functoid recibe dos parametros referentes al namespace y nombre de la propiedad.

Para mas informacion acerca del codigo fuente y ejemplos de utilizacion desde "Accessing Context Properties from within a map in BizTalk".