BizTalkLATAM's Blog : Base de Conocimiento BTS 2004

Depurando información en la DTA en BizTalk 2004

BizTalkLATAM — Fri, 14 Mar 2008 05:15:23 GMT

El proceso de depuración de la base de datos de tracking "DTA" en BizTalk 2004 o BizTalk 2004 SP1 puede tardar horas o tal vez días, depende de la cantidad de información en la BD, debido a la lógica del procedimiento dtasp_PruneTrackingdatabase(). Este inconveniente no sucede en BizTalk 2006 y BizTalk 2004 SP2 por que se hicieron unas correcciones a estos procesos de depuración de las bases de datos.

Sin embargo, parte del proceso de instalación de BizTalk 2004 SP2 es limpiar la BD de tracking por lo tanto si esta tiene mucha información dicho proceso podra tardarse mas horas de lo previsto ya que utiliza este procedimiento.

Para evitar este inconveniente, ES NECESARIO instalar el Hotfix 894253 antes de instalar BizTalk 2004 SP2. Este hotfix contiene un script que elimina toda la información relacionada exclusivamente a las instancias completadas de la BD de tracking, con la única salvedad que todos los registros serán borrados sin tener en cuenta su fecha de almacenamiento.

De igual forma, este hotfix puede aplicarse a BizTalk 2004 o BizTalk 2004 SP1 para depurar información de la BD y evitar su constante crecimiento.

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.

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

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

BizTalk Server 2004 SP2

BizTalkLATAM — Thu, 26 Oct 2006 21:15:14 GMT

Microsoft ha liberado BizTalk Server 2004 SP2. Este nuevo Service Pack contiene muchos hotfix que mejoran el rendimiendo de la plataforma y una nueva caracteristica llamada Archiving and Purging que puede hacer mantenimiento automatico a las bases de datos de seguimiento.

El Service Pack puede ser descargado desde Microsoft BizTalk Server 2004 Service Pack2, y una lista de todos los bugs que este soluciona en List of bugs that are fixed in BTS2004 SP2.

Autor: Carlos Medina

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

BizTalk Server 2004 y WCF

BizTalkLATAM — Wed, 11 Oct 2006 08:12:48 GMT

Actualmente Microsoft esta desarrollando BizTalk Server 2006 R2, el cual involucra un adaptador para WCF. Pero, se pueden invocar Web Service de WCF desde BizTalk Server 2004 sin SP1? La respuesta es SI y basta con agrega un Web Reference al *.svc deseado, sin embargo no es posible utilizar todas las ventajas que ofrece WCF si se desea invocar desde BTS2004.

Aunque WCF implementa muchos estandares de WS-*, estos no son soportados por el adaptador de SOAP para BTS2004 sin SP1. Por lo tanto, la primera restriccion es no utilizar estandares como WS-Security, WS-Routing, etc.

Otro error que se tiene, se ejecuta al establecer un Namespace al atributo ServiceContract que especifica la interfaz de los metodos a implementar. Por ejemplo:

namespace WCF.Ejemplos
{
    [ServiceContract]
    public interface IMetodos
    {
        [OperationContract]
        bool ProcesarMensaje(string mensaje);
    }
}

Cuando esto se hace, el wizard de Web Rerence para BTS2004 en VS2003 no es capaz de importar los metodos a invocar, y mostrara un error de esta forma:

Could not generate BizTalk files. Unable to import WebService/Schema. A schema with the namespace 'MyNamespace' has already been added.

Como se ve, se debe de tener un poco de cuidado al tratar de referenciar Web Services de WCF desde BTS2004 sin SP1. Pero una ves se tomas los respectivos cuidados, a la final se puede invocar un absteniendose de implementar cualquier caracteristica avanzada de WCF.

Autor: Carlos Medina

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

Transacciones en Biztalk con .NET y COM+ (Terminado)

BizTalkLATAM — Tue, 18 Apr 2006 17:50:00 GMT

Versión Final!!!

Esta es una duda que decidí aclarar y que mejor manera que hacer un laboratorio para verlo con mis propios ojos. Este artículo abarca muchos temas que serán brevemente explicados y con referencias para un mayor detalle acerca de como aprovechar el motor de transacciones de BTS usando componentes de .NET con COM+.

Este post esta dividido de la siguiente forma:

Pueden bajar el código final aquí.

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

Assembly no soportado: Microsoft.BizTalk.Databases.dll

BizTalkLATAM — Fri, 10 Feb 2006 20:49:00 GMT

Microsoft.BizTalk.Databases.dll es un assembly no soportado por Microsoft en el framework de BizTalk Sever que provee funcionalidad para consultar los servidores existentes en la red y las bases de datos existentes en estos. Para ello este assembly provee 5 clases: BizTalkDatabaseInfo, Database, DatabaseCollection, Server, y ServerCollection.

Por ejemplo, para consultar los servidores de SQL Server existentes se puede utilizar las clases ServerCollection y Server.

foreach (string name in Microsoft.BizTalk.Databases.ServerCollection.GetSqlServerNames())
{
   Microsoft.BizTalk.Databases.Server server = new Microsoft.BizTalk.Databases.Server(name);
   System.Console.WriteLine("Server name: " + server.Name);
   System.Console.WriteLine("Platform Identifier: " + server.PlatformIdentifier.ToString());
   System.Console.WriteLine("Type: " + server.Type.ToString());
   System.Console.WriteLine("Version: " + server.Version.ToString());
}

Y para consultar las bases de datos de cada servidor basta con utilizar el siguiente código, así mismo por cada base de datos es puede consultar si pertenece o no a BizTalk Server:

Microsoft.BizTalk.Databases.Server server = new Microsoft.BizTalk.Databases.Server("server_name");
bool isBtsDb = true;
foreach (Microsoft.BizTalk.Databases.Database database in server.GetDatabaseCollection())
{
   System.Console.WriteLine("Database: " + database.Name);
   try
   {
      isBtsDb = database.IsBizTalkDatabase;
      if ( isBtsDb )
      System.Console.WriteLine("///// Begin - BizTalk Database ");
   }
   catch
   {
      isBtsDb = false;
   }
   System.Console.WriteLine("Is BizTalk database: " + isBtsDb.ToString());
   if (isBtsDb)
   {
      System.Console.WriteLine("BizTalk Db name: " + database.BizTalkDatabaseInfo.Name);
      System.Console.WriteLine("BizTalk Db version: " + database.BizTalkDatabaseInfo.Version.ToString());
      System.Console.WriteLine("BizTalk Db description: " + database.BizTalkDatabaseInfo.Description);
      System.Console.WriteLine("///// End - BizTalk Database ");
   }
}

Nota: aunque se puede consultar si una base de datos pertenece o no a BizTalk Server, esta funcionalidad no es valida y solo se presenta en el código a nivel de ejemplo. Lo anterior se da por que al consultar la información de la base de datos solo revisa la ManagementBizTalkDb y no otras como BizTalkMsgbDb.

Autor: Carlos Medina

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

Usando Load Generador (LoadGen) Parte I

BizTalkLATAM — Tue, 17 Jan 2006 19:00:00 GMT

Microsoft ha liberado recientemente una nueva versión de su herramienta Load Generator, esta versión requiere del Framework de .Net 2.0 para su ejecución. Pueden bajar esta herramienta desde BizTalk Server 2004 Load Generation Tool.

Conocida también como "LoadGen", esta herramienta permite hacer pruebas de estrés a nuestros procesos de BizTalk Server por medio del envió de mensajes en forma continua (limitado por tiempo o número de mensajes) a destinos predeterminados de BTS (Receive Locations), igualmente la herramienta provee un mecanismo que permitirá monitorear este envió (y recepción) de mensajería para determinar la optimización de nuestros proceso de EAI diseñados.

Para hacer posible la generación de mensajería, la definición del destino, y la monitorización de la mensajería LoadGen utiliza la información almacenada en un Xml de configuración que nosotros mismos definimos de acuerdo al escenario de prueba establecido

En su ejecución, LoadGen basa su arquitectura en 3 capas (ver imagen): Presentation, Framework y Component; a continuación se da una breve explicación de ellas.

Capa Presentation

Esta capa contiene la interfaz del programa. En LoadGen la interfaz se define como una aplicación de Consola, la cual al ser ejecutada recibe un parámetro de entrada que especifica la ruta del archivo Xml con la configuración de la ejecución de la plataforma.

Capa Framework

Esta capa es el "núcleo" de todo el LoadGen y esta representada en solamente una librería. Esta librería traduce el archivo Xml entregado por la capa Presentation y lo utiliza para inicializar todos los componentes necesarios para la generación de mensajes, envío de mensajería y monitorización.

Capa Component

Por último, la capa de componentes contiene todos los elementos necesarios para la generación de nuevos mensajes (Message Creators), envío de mensajes (Load Generators), y monitorización de mensajes (Throttle Controllers).

Este diseño permite que la capa Component pueda ser extendida creando nuevos elementos Load Generators, Message Creators y/o Throttle Controllers. Para extender estos componentes, LoadGen expone 4 interfaces: IMonitor, ITransport, IConfigurable y IMessageCreator.

IMonitor: interfaz utilizada para la creación de un nuevo componente de monitorización.
ITransport: interfaz utilizada para la creación de un nuevo componente de transporte el cual sera invocado en el envio de la mensajeria hacia el destino predeterminado.
IConfigurable: interfaz utilizada para la definición de la configuración del elemento de transporte.
IMessageCreator: interfaz utilizada para la creación de nuevos mensajes en forma personalizada.

LoadGen por defecto provee elementos que pueden ser utilizados para las pruebas de estrés, estos son:

Load Generators

Nombre	Descripción
File Transport	Almacena como archivos en el destino predeterminado.
HTTP Transport	Envía los mensajes a URL’s predeterminadas, soporta Request-Response y el envío de mensajes asíncronos.
SOAP Transport	Envía los mensajes a Servicios Web predeterminados previamente, soporta Request-Response y el envió de mensajes asíncronos.
MSMQ Transport	Envía mensajes a colas de mensajería MSMQ. Estas colas pueden ser privadas transaccionales o no.
MQ-Series Transport	Envía mensajes a colas de IBM-MQ Series.
WSE Transport	Envía mensajes a Servicios Web predeterminados que soporten WSE, soporta Request-Response y el envió de mensajes asíncronos.
WSS Transport	Envía mensajes a Windows SharePoint Services.

Throttle Controllers

Nombre	Descripción

File Monitor	Monitoriza el numero de archivos creados en una carpeta
SQL Monitor	Monitoriza el numero de filas creadas en una base de datos SQL Server
MQSeries Monitor	Monitoriza el numero de mensajes en una cola MQ-Series
MSMQ Monitor	Monitoriza el numero de mensajes en una cola MSMQ

Como se menciona anteriormente, la ejecución de LoadGen esta guiada por el archivo Xml que se pasa en la ejecución de LoadGenConsole.exe en la capa Presentation. Este archivo contiene dos secciones específicamente: <CommonSection /> y <Section />, la primera sección especifica los valores para todos los elementos utilizados como Load Generators, Message Creators y Throttle Controllers.

Por su parte la segunda sección contiene toda la configuración para los elementos Load Generator y en ocasiones puede sobrescribir la información de la sección <CommonSection />

Definir el archivo de configuración es fácil, para ello cuando se instala el LoadGen se escriben unos archivos Xml de configuración de ejemplo.

Nombre	Descripción
FileToFileLG.xml	Envia mensajes como archivos
HttpToHttpOneWayLG.xml	Envía mensajes por HTTP
HttpToHttpTwoWayLG.xml	Envia mensajes por HTTP en Request-Response
MQSeriesLG.Xml	Envía mensajes a colas MQ-Series
MsmqLG.Xml	Envía mensajes a colas MSMQ
SoapToSoapOneWayLG.xml	Envia mensajes SOAP a Servicios Web
SoapToSoapTwoWayLG.xml	Envía mensajes SOAP a Servicios Web en Request-Response
TwoWayLatencyLoopbackHTTPLG.Xml	Envia mensajes por HTTP y calcula su latencia
TwoWayLatencyLoopbackSOAPLG.Xml	Envia mensajes SOAP a Servicios Web y calcula su latencia
TwoWayLatencyLoopbackWSELG.Xml	Envia mensajes a Servicios Web con WSE y calcula su lantencia
WseToWseOneWayLG.xml	Envia mensajes usando WSE a Servicios Web
WseToWseTwoWayLG.xml	Envia mensajes usando WSE a Servicios Web en Request-Response

Esta es una corta descripción de las utilidades de LoadGen, así mismo este es el primer post (Parte I) de una serie de artículos acerca del uso de LoadGen, como desarrollar nuevos componentes y como utilizar al máximo este para probar todos nuestros procesos.

LoadGen puede ser utilizado tanto probar los procesos en las versiones BizTalk Server 2004 y BizTalk Server 2006 Beta 2.

Autor: Carlos Medina

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

Artículos acerca de SSO

BizTalkLATAM — Fri, 13 Jan 2006 19:20:00 GMT

Tomas Restrepo ha escrito dos muy buenos documento acerca de SSO en BTS 2004, en ellos Tomás da una pequeña introducción a los beneficios de SSO y posteriormente nos explica de buena forma una forma de administrar este sistema

Introducción al Enterprise Single Sign-On

Administración del Enterprise Single Sign-On

Estos documentos pueden complementar los anteriores artículos de Christian Carnero acerca de SSO publicados el año pasado:

Otro articulo interesante artículo publicado por Tomas (aunque no trata directamente a BizTalk), nos habla de por que NO debemos utilizar el paso de cadenas de texto con XML mediante Servicios Web dando una mayor optimización y mantenimiento a los servicios. El documento lo pueden encontrar en Servicios Web y Strings XML

Autor: Carlos Medina

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

¿Problemas al invocar una orquestación como Servicios Web?

BizTalkLATAM — Mon, 26 Dec 2005 19:27:00 GMT

Muchos de nosotros hemos pasado muchas horas frente al computador tratando de solucionar problemas al no poder invocar orquestaciones expuestas como Servicios Web desde otros aplicativos, para tratar de evitar esto Microsoft ha publicado un articulo donde expone los 3 errores mas comunes al consumir un Servicio Web de BTS 2004:

Problema 1

Se registra los siguientes mensaje de error en el registro de sucesos de aplicación en el servidor que ejecuta BizTalk Server 2004:

La Mensajería Motor no podría registrar el adaptador de "SOAP" para la ubicación de recepción " / VirtualDirectory / .asmx Nombre ". Vuelva a comprobar que la ubicación de recepción es válida y que el adaptador aislado se ejecuta con una cuenta que tiene acceso a las bases de datos BizTalk.

Un intento de que se conecta a base de datos de SQL Server "BizTalkMgmtDb" en el servidor en el que falló " Servidor" con error:" no se puede abrir la base de datos solicitada en inicio de sesión "BizTalkMgmtDb"." No se puede iniciar sesión . " . "

Problema 2

En un servidor remoto que ejecuta BizTalk Server 2004, se registra el mensaje de error siguiente en el registro de sucesos de aplicación al llamar a la orquestación que se expone como un servicio Web:

" : " < / > " . " el adaptador "SOAP" suspende unos mensajes salientes que van en dirección URL de destino http:// VirtualDirectory .asmx Nombre Detalles:" servidor no podría procesar solicitud." - > . " . " no se encontraron Archivo, .dll de nombre de ensamblado FileName o una de sus dependencias

Cuando llama a la orquestación que se expone como un servicio Web desde un equipo de cliente que no ejecuta BizTalk Server 2004, puede recibir un mensaje de error que es similar a lo siguiente:

SoapException: SOAP interno que procesa error

Problema 3

Se registra el mensaje de error siguiente en el registro de sucesos de aplicación en el servidor en el que se expone el servicio Web:

Fue que un error ejecuta la canalización de recepción : Source "Microsoft.BizTalk.DefaultPipelines.XMLReceive" : Recibir Ubicación "Microsoft.BizTalk.Messaging" : " / VirtualDirectory / .asmx Nombre " Motivo : especificó que la conversión no es válida.

Adicionalmente, da la explicación de las causas a cada uno de estos problemas y la solución para el correcto funcionamiento de los Servicios Web. Realmente es un buen artículo que vale la pena dedicarle un momento para leerlo y tenerlo en cuenta para nuestros desarrollos.

El articulo puede ser consultado en No se puede llamar una orquestación que se expone como un Servicio Web en un servidor que ejecuta BizTalk Server 2004

Autor: Carlos Medina

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

¿Donde guardo mis parámetros de configuración?

BizTalkLATAM — Thu, 24 Nov 2005 19:39:00 GMT

Muchas veces he escuchado preguntar a los desarrolladores de BizTalk Server: ¿Donde puedo guardar mis parámetros de configuración? Bien, desde un punto de vista práctico existen tres lugares donde se pueden almacenar:

El archivo BTSNTSvc.exe.config.
Un archivo Xml de configuración propietario
Una aplicación externa. A continuación se evaluara cada uno de los casos.

BTSNTSvc.exe.config

Este es el archivo de configuración del servicio que ejecuta BizTalk Server (BTSNTSvc.exe) el cual generalmente se localiza en la carpeta de configuración (muchas veces la misma de instalacion) de BTS.

NOTA: si no se conoce donde esta el servicio de BizTalk Server, este puede localizarse en la ruta del Registro de Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\ConfigFramework\Path

El Registro de Windows es de suprema importancia para el buen funcionamiento del sistema operativo, por lo que la utilización de este es de riesgo personal.

Este archivo corresponde a un archivo de configuración del framework de .Net, por lo tanto soporta la sección de <appSettings /> en la cual se pueden guardar las varias de configuración, por ejemplo:

<?xml version="1.0" ?>
<configuration>
   <runtime>
      ………
   </runtime>
   <appSettings>
      <add key="ConnectionString1" value="SQL Server 1" />
   </appSettings>
   ………
</configuration>

Luego, leer dichos valores resulta sencillo bien sea desde la misma orquestación o desde un assembly .Net no BTS referenciado desde la orquestación, así:

Assembly:BizTalk 2004 ó Assembly:.Net 1.1

System.Configuration.ConfigurationSettings.AppSettings.Get("ConnectionString1");

Assembly:BizTalk 2006 ó Assembly:.Net 2.0

System.Configuration.ConfigurationManager.AppSettings.Get("ConnectionString1");

Las ventajas de esta primera es la que se ofrece con el mismo framework de .Net ya que actúa de igual forma, lo cual significa que todos los datos son cargados a memoria la primera ves que se crea una instancia del servicio BTSNTSvc.exe.

La gran desventaja notable de esta opción, es que si es requerido cambiar un valor de alguna de las variables seria necesario detener el servicio y volverlo a iniciar para que este nuevo valor tomase efecto dentro de nuestra ejecución, dando la opción de interrupción de los servicios y por ende posible perdida de información.

En forma adicional, otra desventaja de esta solución es el proceso de despliegue del aplicativo, ya que se hace necesario modificar el archivo de configuración BTSNTSvc.exe.config en la instalación de los elementos de BizTalk Server y este es una modificación de cuidado ya que cualquier daño que sufra dicho archivo afectara todo el funcionamiento de nuestro servicio de BizTalk Server.

Archivo Xml de configuración propietario

Esta es otra técnica muy conocida y consiste en tener un Xml con una configuración propietaria donde se almacena toda la información, posteriormente con la ayuda de una clase Helper desarrollada o con XmlDocument e instrucciones xpath se obtienen los datos solicitados.

La única y gran incógnita de esta opción es donde almacenar el archivo Xml de configuración, en este caso tendríamos muchas opciones, entre las cuales se describen las 3 mas utilizadas:

Almacenarlo en una ruta específica que siempre será la misma, por ejemplo: D:\EAI\Proyecto\Archivo.xml.

Esta opción seria muy buena, pero… ¿cuál es la realidad? En los servidores de producción no se pueden almacenar archivos de configuración en cualquier ubicación sino en la establecida por la arquitectura de la compañía, por lo tanto esta primera opción no es la muy práctica.
Otra opción crear una entrada en la sección <appSettings /> del archivo de configuración y en dicha entrada almacenar la ruta del archivo de configuración. De esta forma, antes de leer la información solicitada se consultaría primero la ruta del archivo desde la entrada de <appSettings /> y posteriormente la información requerida de dicho archivo.
Esta es una opción práctica, y comúnmente muchas de nuestras aplicaciones .Net funcionan así. Sin embargo, esta alternativa tiene un único defecto que se basa en el proceso de despliegue ya que es necesario editar el archivo BTSNTSvc.exe.config y por consecuente cualquiera edición mal realizada podría traer consecuencias fatales para la ejecución de BizTalk Server.
Por ultimo, también se puede almacenar el archivo Xml de configuración en la misma localización donde se almacenan los assemblies de .Net tanto BTS como no-BTS. De esta forma, desde el interior del assembly por medio de la clase System.Reflection.Assembly y la propiedad GetExecutingAssembly().Location podemos obtener la ruta actual de ejecución del assembly y de esta forma conocer fácilmente la localización del archivo.
Esta opción es buena, sin embargo (si, también tiene su pero… L) muchos se preguntaran… ¿Cuál es la carpeta de ejecución del assembly? Bien, si registramos el assembly en el GAC la carpeta sería %windir%\assembly\GAC\Assembly\version_publictoken\Assembly.dll, luego de saber esto la pregunta obligada es, ¿entonces ya se empieza a complicar el asunto, como grabo el archivo Xml en esa carpeta? La respuesta es SI y NO. No por que en este caso no es se registraría el assembly en el GAC para que BizTalk Server pueda reconocerlo, y SI por que de alguna forma es necesario mostrarle el assembly a BizTalk Server para que lo reconozca.

Entonces, ¿como hacer que BizTalk Server reconozca el assembly? Nuevamente esta solucion involucra la modificacion del archivo BTSNTSvc.exe.config, en esta ocasión se especificaria una nueva carpeta en la cual el servicio buscaria assemblies relacionado con la ejecución de BizTalk Server. Para ello seria necesario modificar la seccion del <probing /> archivo, asi:

En esta ocasión, se ha especificado que también busque los assemblies en la carpeta Nuevos Assemblies la cual deberá crearse como subdirectorio de la carpeta donde se encuentra el servicio BTSNTSvc.exe.config. Por lo tanto, bastaría guardar nuestro assemblie de lectura de información en dicha carpeta junto con el archivo Xml de configuración.

Esta alternativa de resolución de assemblies hace parte de la arquitectura de .Net para la localización de assemblies, para mayor información visitar Assembly Placement y <probing> Element.

Un servicio externo

Una tercera opción, es tener una aplicación externa que almacene todos los parámetros o variables de configuración, llámese Web Service, SQL Server, Oracle, Web Page, entre otros. En esta oportunidad, podríamos tener un proceso de orquestación que se pueda invocar desde otros procesos de orquestación y obtener los datos requeridos.

Esta opción seria la mejor para un compañía con una arquitectura SOA, ya que basados en servicios se podrían obtener los parámetros ya centralizados para las demás aplicaciones. En este caso, el despliegue seria de una manera sencilla ya que se utilizarían los elementos nativos de BizTalk Server (puertos) para la localización del repositorio de parámetros y su mantenimiento seria por medio de las mismas herramientas de BizTalk Server en caso tal que la ubicación del servicio cambiase (consola administrativa u otros).

***

Como se puede leer, existen varios lugares donde se puede almacenar los parámetros de configuración de la aplicación. ¿Cuál aplicar? Todo depende del tipo de arquitectura diseñada en la compañía, y que tipo de arquitectura tendrá la solución de EAI con BizTalk Server para que se la decisión a tomar sea la mas adecuada. En cualquier caso, si la decisión es editar el archivo BTSNTSvc.exe.config siempre se hace necesario tener mucho cuidado ya que este archivo, nuevamente, es vital para el correcto funcionamiento de BizTalk Server.

Esta información aplica tanto para la versión BizTalk Server 2004 y BizTalk Server 2006 Beta 2. Sin embargo, no se garantiza su funcionalidad para la versión final de BizTalk Server 2006.

Autor: Carlos Medina

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

Nuevos artículos de KB en el sitio de soporte de MS (Octubre)

BizTalkLATAM — Wed, 02 Nov 2005 23:00:00 GMT

Durante el mes de septiembre MS publicó algunos artículos de soporte para BizTalk Server 2004, estos articulo incluyen correcciones (Fix) o recomendaciones de funcionalidades para mejorar la implementación de nuestros procesos. A la fecha estos son los artículos publicados por MS:

Fix: The Business Activity Services Messaging Adapter does not work as expected in BizTalk Server 2004 after you install Windows SharePoint Services Service Pack 2

Articulo en ingles. Articulo en español.

You may receive a "The following platform components failed to install and will need to be manually installed before setup can proceed Enterprise Single Sign-On Server" error message when you try to install BizTalk Server 2004

Articulo en ingles. Articulo en español.

The Tracking_Spool1 or Tracking_Spool2 tables in the BiztalkMsgBoxDb database become very large in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Fix: An "Enterprise Single Sign-On is offline" error message may be logged in the Configuration log when you try to use the "Configframework /s" command to silently reconfigure BizTalk Server 2004

Articulo en ingles. Articulo en español.

Fix: Event ID 5719 may occur when you use a custom receive pipeline to validate a document structure in BizTalk Server 2004

Articulo en ingles. Articulo en español.

You must run the Configuration Wizard when you move an installation of BizTalk Server 2004 from one domain to another domain

Articulo en ingles. Articulo en español.

Information about handling incoming data streams in pipeline components in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Fix: You may receive a "Failed to create project" error message when you try to publish an orchestration as a Web service in BizTalk Server 2004

Articulo en ingles.

Cualquier duda que se tenga acerca del funcionamiento o rendimiento de nuestras aplicaciones en BizTalk Server 2004 podemos preguntar en el grupo de discusión news:microsoft.public.es.biztalk.server o ir directamente al centro de soporte tal como se explica en el anterior post.

Y para aquellas personas que les gusta mantenerse al día de los artículos de soporte publicados por MS acerca de BizTalk Server pueden registrar en sus blogs este rss http://support.microsoft.com/common/rss.aspx?rssid=1444&ln=en-us que los mantendrá actualizados.

Artículos de KB en el sitio de soporte de MS (Septiembre)

BizTalkLATAM — Thu, 06 Oct 2005 19:35:00 GMT

Durante el mes de septiembre MS publicó algunos artículos de soporte para BizTalk Server 2004, estos articulo incluyen correcciones (FIX) o recomendaciones de funcionalidades para mejorar la implementación de nuestros procesos. A la fecha estos son los artículos publicados por MS:

You may receive a "Repository was locked on host" error message when you try to validate an EDI schema in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Fix: The rule engine may return incorrect values in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Fix: the XLANG engine may not report a failed DTC transaction and may not end the transaction in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Applications that use Enterprise Single Sign-On cannot log on to remote applications if the ENTSSO service cannot communicate with SSO credential database for 5 or more minutes

Articulo en ingles. Articulo en español.

Fix: The performance of a singleton orchestration that contains a Call Orchestration shape may decrease over time in BizTalk Server 2004

Articulo en ingles. Articulo en español.

Autor: Carlos Medina

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