Un escenario de mensajeria sin orquestaciones
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.