Procesamiento en la orquestación OrderBroker
En esta sección se describe cómo la orquestación OrderBroker toma pedidos y los prepara para un administrador de procesos. La sección empieza con una descripción del funcionamiento general de la orquestación. A continuación, se explica cómo la orquestación procesa un mensaje. Por último, se indica cómo la orquestación usa una transacción atómica para mejorar el rendimiento.
Nota
Debido a la longitud de la longitud del código OrderBroker , es posible que quiera leer esta sección con la orquestación abierta en Microsoft® Visual Studio.
¿Por qué utilizar un agente de pedido?
El propósito de la orquestación OrderBroker es preprocesar un pedido y enrutarlo al administrador de procesos correcto. El preprocesamiento conlleva crear mensajes informativos para la base de datos de historial y el sistema de servicio, así como para confirmar la recepción del pedido. OrderBroker también crea un mensaje de pedido genérico a partir de la solicitud de servicio al cliente. Esta normalización del pedido permite que los elementos del proceso empresarial consuman de forma genérica el pedido.
El mensaje de pedido es un mensaje de varias partes en el que la información de enrutamiento está separada de la información de pedido. La información de enrutamiento también es genérica y está diseñada para que la consuma cualquier administrador de pedidos. Esto a su vez facilita la ampliación de la solución. Para obtener información sobre los mensajes de varias partes, vea Cómo usar tipos de mensajes de varias partes.
El aislamiento de la función de agente también le permite moverla a otro grupo de BizTalk. Dado que OrderBroker publica en la base de datos MessageBox (es decir, está enlazado directo), también facilita la colocación del agente en otro grupo, puede mover el agente sin cambiar la orquestación. Para obtener más información sobre cómo colocar OrderBroker en otro grupo, vea Comunicación entre OrderBroker y OrderManager.
Nota
La orquestación OrderBroker , porque solo tiene un OrderManager con el que comunicarse, simplemente asigna una cadena constante al campo OrderMgrType en el mensaje del administrador de pedidos. Normalmente, en una aplicación en la que haya varios administradores de pedidos, la aplicación utilizará el motor de reglas de negocios para determinar el valor adecuado para este cambio y el enrutamiento del pedido. Para obtener más información sobre el motor de reglas de negocios, consulte Creación y uso de reglas de negocios.
Procesamiento de pedidos
La orquestación OrderBroker comienza con dos formas de recepción dentro de una forma De escucha . Una forma De recepción toma mensajes del sistema de atención al cliente; el otro, mensajes del sistema de proveedor. Los mensajes tienen el mismo esquema ya procedan de uno u otro origen.
La orquestación extrae la dirección de retorno del mensaje y la usa para establecer la dirección para el puerto dinámico , CSRPort. La orquestación usa este puerto para enviar mensajes de confirmación y error.
Los pasos siguientes de la orquestación OrderBroker crean el mensaje de historial, el mensaje de servicio, el mensaje de confirmación y el mensaje de pedido que se va a enviar a la orquestación OrderManager . La orquestación usa la función de utilidad InsertOrderBody para agregar el mensaje de pedido al mensaje del historial.
Nota
En algunas situaciones, la solución puede producir mensajes que se entregan pero que no se consumen. La orquestación OrderBroker utiliza un puerto de envío para insertar información en la base de datos de historial. Este puerto de envío usa la característica de notificación de entrega. La configuración asigna el puerto de envío a un grupo de puertos de envío que contiene dos puertos: un puerto para la configuración de prueba (HistoryInsert-Test-SP), uno para la configuración normal (HistoryInsert-SP). Si deja ejecutando los dos puertos del grupo, la solución envía mensajes en los dos puertos. Por consiguiente, solicita dos notificaciones de entrega, pero solamente procesa una.
Para evitar esta situación, anule la lista del puerto de prueba (HistoryInsert-Test-SP) o detenga la versión de prueba de la aplicación, BTSScn.BPM.OrderBrokerApp.Test. Para obtener más información sobre las notificaciones de entrega, consulte Uso de confirmaciones.
Al construir el mensaje que se va a enviar a la orquestación OrderManager , la orquestación OrderBroker crea un mensaje de varias partes con dos partes. Una parte contiene la información de enrutamiento y la otra parte incluye el propio pedido. La parte de enrutamiento del mensaje , OrderMgrMsg.Routing, usa un esquema definido por una clase de C# en el ensamblado SchemaClasses . El agente trata la parte de orden del mensaje como un documento XML genérico o independiente del tipo (System.Xml. XmlDocument) y lo asigna a OrderMgrMsg.Order.
Hay dos campos en la información de enrutamiento que son especialmente importantes para el administrador de pedidos, OrderMgrMsg.Routing.OrderMgrType y OrderMgrMsg.Routing.Status. El agente establece OrderMgrType en el tipo del administrador de pedidos que se va a controlar el pedido. En la solución, sólo hay un administrador de pedidos y el campo está establecido en CABLEORDER. El agente también establece el campo Estado en ACCEPTED. Éste es el valor que indica al administrador de pedidos que el mensaje es un nuevo pedido. El administrador de pedidos de la solución, orquestación OrderManager , usa una forma Receive que filtra el tipo de pedido igual a CABLEORDER y el estado igual a ACCEPTED.
Los pasos restantes de la orquestación OrderBroker envían los distintos mensajes a los puertos adecuados.
Mejorar el rendimiento con ámbitos anidados
Una de las cosas notables sobre la orquestación OrderBroker es su uso de ámbitos anidados. Uno de los objetivos de los ámbitos anidados es mejorar el rendimiento a través de la limitación de los puntos de persistencia.
El motor de orquestaciones guarda periódicamente el estado de toda la orquestación en puntos de ejecución que se denominan puntos de persistencia. El motor de orquestación trata automáticamente varias formas de orquestación, incluidas las formas De envío, como puntos de persistencia. Para obtener una lista de puntos de persistencia y más información sobre ellos, consulte Persistencia y motor de orquestación.
Con cinco formas Send , la orquestación OrderBroker debe tener cinco puntos de persistencia. Sin embargo, al agrupar Enviar formas dentro de un ámbito de transacción atómica, el motor reconoce que solo necesita un punto de persistencia para el ámbito. Dado que cuatro de las formas Enviar en la orquestación OrderBroker no forman parte de los controladores de excepciones y no es necesario hacer nada después del envío, pueden ir en un ámbito de transacción atómica. Esto reduce el número de puntos de persistencia. Para obtener más información sobre las transacciones atómicas, consulte Transacciones atómicas.
Además, el motor de orquestaciones utilizará un único punto de persistencia para las transacciones anidadas si todas las transacciones finalizan al mismo tiempo. Por lo tanto, la forma en que orderBroker orchestration anida las transacciones reduce aún más los puntos de persistencia: la orquestación tiene un único punto de persistencia debido al uso de formas scope .
Sugerencia
Se puede mejorar el rendimiento si se reduce al mínimo el número de puntos de persistencia de una orquestación. Puede agrupar Enviar formas en una transacción atómica para generar un único punto de persistencia para todas las formas De envío . Si se finalizan a la vez los ámbitos de transacciones anidadas, se creará un único punto de persistencia para las transacciones.
Un ámbito de transacción atómica no puede tener un controlador de la excepción. Por ello, la orquestación anida el ámbito atómico dentro de una transacción de larga ejecución. Esta transacción externa puede tener un controlador de excepciones y es este controlador que procesa una excepción de las formas Enviar .
Sugerencia
El anidamiento de una transacción atómica dentro de una transacción de larga ejecución es un patrón habitual para permitir para el control de excepciones.
Consulte también
Procesamiento en la solución de administración de procesos empresariales
Lógica del administrador de procesos
Control de interrupciones en la solución de administración de procesos empresariales
ExceptionHandler (orquestación)