BizTalk Server: Como estructurar mis soluciones y proyectos Visual Studio
Este es mi post pendiente, por lo que ya es hora de cumplir promesas ;)
En esta ocasión voy a compartir con vosotros la forma en que suelo estructurar las soluciones y proyectos de BizTalk en Visual Studio, para explicarme mejor creemos un escenario inmaginario donde sea necesario emplear todos los artefactos de BizTalk Server.
Lo primero es elegir el espacio de nombre (namespace) a emplear, en mi caso suelo utilizar como prefijo el nombre de la compañía del cliente, seguido del nombre o código del proyecto. Un ejemplo ilustrativo: "Contoso.MiApp". No obstante, como siempre, si nuestro cliente dispone de una politica para esto hay que respetarla.
A continuación creo una solución en blanco denominada igual que el namespace elegido, en este caso "Contoso.MiApp". Ahora puedo incluir mis proyectos, y dado que en este escenario utilizo todos los tipos de artefactos de BizTalk Server mi propuesta sería:
- Contoso.MiApp. Schemas
- Proyecto: BizTalk
- Extensión: btproj
- En este proyecto guardo todos los esquemas utilizados en la aplicación que estamos creando, incluyendo los documentos de propiedades utilizadas para promocionar información en contexto.
- Contoso.MiApp. Functoids.Utils
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- En esta librería incluyo las clases y métodos que incorporar la lógica de las functoids.
- Contoso.MiApp. Functoids
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- Repositorio que incluye las functoids utilizados en los mapas de la aplicación. En este caso, en lo posible, intento incluir solo la descripción de las functoids dado que la lógica de estas la separo en otra librería.
- Contoso.MiApp. Maps.Utils
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- En esta librería recopilo todos las clases y métodos utilizados desde las functoids de tipo Script.
- Contoso.MiApp. Maps
- Proyecto: BizTalk
- Extensión: btproj
- Repositorio de los mapas utilizados desde la aplicación.
- Contoso.MiApp. Logic
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- En esta librería incluyo la implementación de toda la lógica de negocio de la aplicación.
- Contoso.MiApp. Orchestrations
- Proyecto: BizTalk
- Extensión: btproj
- Recopilación de las orquestaciones que componen la aplicación, incluida las de gestión de errores de la aplicación.
- Contoso.MiApp. Pipelines.Components.Utils
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- Librería que incluye las clases y métodos con el código de uso común necesarios por los componentes de pipeline.
- Contoso.MiApp. Pipelines.Components
- Proyecto: C# o VB.net
- Extensión: csproj o vbproj
- Contendrá los componentes de pipeline creados a medida para la aplicación.
- Contoso.MiApp. Pipelines
- Proyecto: BizTalk
- Extensión: btproj
- Recopilación de los pipelines personalizados que podrán ser utilizados por la aplicación.
Por supuesto, esta aproximación la considero adecuada en aplicaciones con muchos componentes. Esto quiere decir, que en pequeños proyectos o pruebas de concepto no es necesario ser tan estrictos. Como mínimo, sería interesante disponer de dos librerías de C# o VB.net, una con los componentes de pipeline y otra con el resto de código.
¿Pero que pasa con los proyectos que incluyen nuestras pruebas unitarias? Mi recomendación es no mezclar en una misma solución proyectos de C# o VB.NET con proyectos de TEST y proyectos de BizTalk Server 2006.
NOTA: Recordar que existe un límite de tamaño máximo assembly de 75 Mb, esto es importante que sea tenido en cuenta en las aplicaciones muy grandes. Por ejemplo, una vez me encontre con un cliente que tenia más de 30 esquemas donde cada esquema tenía un tamaño aproximado de 2 Mb y por tanto, tuvimos que dividir el proyecto en varios, en este caso eran esquemas EDI por lo que decidimos estructuramos por normativa soportada: EDIFACT, ODETTE, ANSI, etc.