Realmente es necesario utilizar multi-parts en los objetos mensajes?

En ocasiones se ha discutido si es necesario definir los objetos tipo mensajes (message object) utilizados en orquestaciones en base a partes de mensajes (multi-part message type) o no, dado que el VS.Net da la posibilidad de definir estos objetos basados en esquemas (schemas) o clases de .net (.net class) directamente.

La respuesta es NO (ver las conclusiones) , excepto si vamos a trabajar con dichas partes explicitamente en nuestra orquestación. Sin embargo es necesario entender que aunque no definamos estas partes explicitamente, BTS nunca trabajará referenciando directamente los mensajes en sus procesos sino con sus partes definidas de acuerdo al esquema o clase que especifican estos. Para entender mejor esta anotacion, a continuacion se representan tres mensajes de objetos definidos asi:

• MsgMultipart: definido con base a una parte (Multi-part message type) con un segemento llamado "parte", y este segmento se define con base en un esquema llamado "EsquemaSalida"
• MsgEsquema: definido con base a un esquema llamado "EsquemaEntrada"
• MsgClase: definido con base a la clase de .net System.String

Como se habla en Explorando un assembly de BTS, cada una de los mensajes son representados dentro de la orquestacion como variables internas definidas de acuerdo al tipo de dato, por consiguiente los mensajes definidos en la orquestacion inicialmente estarían representados así:

internal sealed class Orquestacion : BTXService
{
// Fields
    [UserVariable("MsgEsquema")]
public _tipomensaje1 __MsgEsquema;
[UserVariable ("MsgMultipart")]
internal _tipomensaje2 __MsgMultipart;
[UserVariable ("MsgClase")]
internal _tipomensaje3 __MsgClase;
}

Como se ve existen 3 tipos de mensajes diferentes definidos para cada objeto, ahora veamos como BTS define estos tipos. En el ejemplo los mensajes corresponden a diferentes tipos de datos por lo tanto por cada mensaje se crearán dos clases que definen el tipo del mensaje y el tipo de la parte asociada al mensaje. Esto es:

[Mensaje MsgMultipart]
public sealed class __BtzToNet_Multiparts_EsquemaSalida__ : XSDPart
{
// Methods
....
// Fields
private static EsquemaSalida _schema;
}
internal sealed class Multipart_Salida : BTXMessage
{
// Methods
.....
// Fields
public __BtzToNet_Multiparts_EsquemaSalida__ parte;
}

[Mensaje MsgEsquema]
public sealed class __BtzToNet_Multiparts_EsquemaSalida__ : XSDPart
{
    // Methods
... 
// Fields
private static EsquemaSalida _schema;
}
public sealed class __messagetype_BtzToNet_Multiparts_EsquemaEntrada : BTXMessage
{
// Methods
...
// Fields
public __BtzToNet_Multiparts_EsquemaEntrada__ part;
}

[Mensaje MsgClase]
public sealed class __System_String__ : DotNetPart
{
// Methods
...
// Properties
public static Type PartType { get; }
}
public sealed class __messagetype_System_String : BTXMessage
{
// Methods
...
// Fields
public __System_String__ part;
}

Siempre se define una clase que deriva de BTXMessage que es la clase del framework de BTS que define los objetos mensajes, y tambien se define una clase para la parte que puede derivar de XSDPart o DotNetPart depediendo si esta definida con base en un esquema o en una clase de .Net. Esta segunda clase es utilizada por una variable interna publica de la clase del mensaje que se define con base en esta. De esta forma, cuando invocamos una mapa de transformación (map) se toman como referencia las partes del mensaje basados en sus propias clases. Por último, la orquestación realmente quedaría representada así:

internal sealed class Orquestacion : BTXService
{
// Fields
    [UserVariable("MsgEsquema")]
public __messagetype_BtzToNet_Multiparts_EsquemaEntrada __MsgEsquema;
[UserVariable("MsgMultipart")]
internal Multipart_Salida __MsgMultipart;
[UserVariable("MsgClase")]
internal __messagetype_System_String __MsgClase;
}

Conclusión:
Como se dijo inicialmente, NO es necesario definir las partes ya que VS.Net en el momento de la construccion (build) realizar la autogeneracion necesaria de las partes (utilizanxsharpp.exe) que no fueron definidas explicitamente por le desarrollador asignandole nombres generados automaticamente de acuerdo a su procedencia para evitar su repeticion. La definicion de estas partes nos ayuda a que este proceso llevado a cabo por VS.Net sea menos costoso en el momento de la construccion, ademas que los nombres de las clases serian mas consistentes en el momento (de ser necesario) de explorar el codigo interno.

Autor: Carlos Medina

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