Flujo de pedidos mediante el administrador de procesos
En esta sección se describe cómo el administrador de procesos de pedidos de Southridge Video, la orquestación OrderManager , procesa los pedidos. Esta sección sigue un pedido nuevo a través de la orquestación. Además, aborda cómo controla la orquestación las actualizaciones de los pedidos.
Nota
La solución de administrador de procesos empresariales incluye sólo un administrador de procesos, pese a que esté diseñado para utilizar más de un tipo.
La orquestación OrderManager coordina las orquestaciones subordinadas que implementan el proceso de negocio para controlar el pedido. OrderManager envía el pedido a través de dos fases que, combinadas, validan el pedido, envían la información al grupo de instalaciones, envían el pedido al sistema de pedidos a través de componentes de comunicación remota y actualizan el historial de pedidos. Puede agregar, eliminar o modificar estas fases sin tener que cambiar OrderManager.
Nota
Debido al tamaño y el ámbito de la orquestación OrderManager , es posible que quiera leer esta sección con la orquestación abierta en Microsoft Visual Studio.
Estructura del administrador de pedidos
La orquestación OrderManager comienza con una forma de recepción que activa la orquestación. En el diagrama siguiente se muestra la estructura general de la orquestación OrderManager .
La primera forma de recepción conduce a dos ramas principales. Una rama, la derecha, procesa pedidos nuevos. La rama izquierda, por su parte, controla las cancelaciones de pedido. Dado que acepta la entrada del usuario, es posible que OrderManager reciba una cancelación de pedido después de que un pedido ya se haya completado. Éste es el caso que controla la rama principal izquierda. La rama controla la cancelación aislada y, para ello, establece indicadores de finalización de procesamientos y agrega advertencias a los registros de sucesos. La orquestación controla las cancelaciones de pedido que recibe mientras se procesa un pedido en la rama derecha.
La rama de procesamiento de pedidos realiza algunas operaciones de inicialización y especifica dos bucles anidados. El bucle externo se ejecuta una vez en cada fase de procesamiento del pedido. El bucle interno se ejecuta durante el procesamiento de la fase. Además, el administrador de pedidos escucha las posibles actualizaciones del pedido dentro del bucle interno. Una vez que terminan los bucles, el administrador de pedidos envía un mensaje de finalización.
Las fases de procesamiento de pedidos usan puertos dinámicos y autocolantes para comunicarse con la orquestación OrderManager . Esto simplifica la correlación del OrderManager con las instancias de fase porque elimina la necesidad de usar un conjunto de correlación. Para obtener más información sobre los puertos auto-correlacionados, consulte Enlaces de puertos.
Recibir pedidos
OrderManager recibe mensajes de pedido de la orquestación OrderBroker a través del puerto FromBrokerPort. Este puerto está vinculado directamente a la base de datos de cuadro de mensajes. La orquestación tiene dos formas de recepción conectadas al puerto: una para nuevos pedidos y otra para pedidos actualizados.
OrderManger determina los mensajes que se van a procesar en función de una expresión de filtro. La expresión de filtro prueba el valor en el campo de estado del mensaje y el campo de tipo de administrador de pedidos , OrderMgrType. Si el campo de estado es igual a ACCEPTED y OrderMgrType es CABLEORDER, el orden es nuevo y está pensado para este administrador de procesos.
El pedido nuevo activa una instancia nueva de la orquestación. OrderManager comprueba el tipo de la solicitud en una forma de decisión. Si el tipo es Finalizar, la orquestación ejecuta la rama izquierda y finaliza el pedido. De lo contrario, la orquestación continúa procesando el pedido. Observe que aquí se incluye la escucha de los mensajes posteriores que estén relacionados con este pedido en concreto.
Inicialización de pedidos nuevos
Una vez que la orquestación OrderManager recibe un mensaje inicial y comienza la rama principal derecha, obtiene su información de configuración de SSOConfigStore. Lo hace a través de un objeto singleton definido en el ensamblado Utilities . Los valores de configuración son propiedades del objeto. El objeto administra una caché local de los valores de configuración parecida a la solución de arquitectura orientada a servicios. Para obtener más información sobre el objeto singleton, vea Using SSO Efficiently in the Business Process Management Solution.
Al igual que ocurre con la solución orientada a servicios, la solución de administración de procesos empresariales utiliza el almacén de secreto (puesto que aparece siempre que BizTalk está instalado) y SSO almacena en caché la información de configuración para que todos los valores estén disponibles con facilidad; además, puede proteger información como, por ejemplo, cadenas y contraseñas de conexión de bases de datos. Por todo ello, el almacén secreto se convierte en la ubicación idónea para la información de configuración, aunque no se esté utilizando el inicio de sesión único para administrar las conexiones a las aplicaciones de servidor.
Nota
La orquestación recupera información de configuración antes de iniciar el procesamiento. De esta manera, se garantiza que la orquestación utilice la misma configuración en caso de que se deshidrate y recupere la hidratación. Para obtener más información sobre la deshidratación, consulte Orquestación Dehidratación y Rehidratación.
El administrador de pedidos usa un valor de los datos de configuración: TotalStages, el número total de fases en el proceso de control de pedidos. El administrador asigna este valor a una variable local, numStages. También establece dos variables más conectadas al bucle externo, la fase y la detención. La fase indica la fase actual y es el contador del bucle externo; detenga el valor de detención.
Por último, el administrador establece la variable orderStatus en STARTED y entra en el bucle de procesamiento externo.
Nuevos bucles de procesamiento de pedidos
El bucle externo se ejecuta siempre que el valor de la variable stage sea menor que el valor de la variable numStages . Los bucles externos dirigen el procesamiento de cada fase. El bucle interno se ejecuta siempre que se esté procesando una fase. También escucha los cambios posibles del pedido.
Bucle externo
La orquestación comienza el bucle externo asignando el mensaje recibido (NewOrderMgrMsg) a una variable OrderMgrMsg. A continuación, copia la fase y el estado a la parte de enrutamiento del mensaje. La orquestación también establece la dirección de retorno en el mensaje en la dirección de StageCompletionPort:
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
A continuación, la orquestación envía el pedido a StagePort, un puerto de solicitud-respuesta. La orquestación espera la confirmación de la fase que ha iniciado el procesamiento del pedido. La fase envía un mensaje OrderAck cuando comienza a procesar el pedido.
Nota
El mensaje OrderAck es uno de los varios de la solución definida por las clases de .NET en lugar de un esquema. Para obtener más información sobre el uso de clases de .NET para definir mensajes, vea Construcción de mensajes en código de usuario.
Cuando la orquestación recibe la confirmación, asigna la fase a la variable currentStage y entra en el bucle interno.
Bucle interno
El bucle interno se ejecuta siempre que la variable currentStage sea igual a la variable stage; es decir, siempre que se procese la fase actual. El cuerpo del bucle es una forma de escucha con tres formas de recepción . La forma situada más a la izquierda en la orquestación, Solicitud de pedido, forma parte del mecanismo de actualización de pedidos, que se describe en la sección siguiente.
Cuando finaliza una fase de procesamiento de pedidos, envía un mensaje al puerto StageCompletion de la orquestación OrderManager . Si la fase finaliza abruptamente debido a un error, envía un TerminatedMessage. En este caso, OrderManager produce una excepción. El controlador de excepciones más externo detecta la excepción y envía un mensaje de error a OperatorPort.
Si la fase envía un OrderMgrMsg, OrderManagerincrementa la variable stage. Si hay más fases (fase menor o igual que numStages), las orquestaciones establecen el estado del orden en OrderMgrMsg en STAGE_n_COMPLETED donde n es el número de la fase actual. Si no hubiera más fases, establece el estado del pedido como COMPLETED y sale de los bucles.
Actualizaciones de pedido
La orquestación OrderManager escucha las actualizaciones de pedidos dentro del bucle de procesamiento interno. Observe que la forma Receive que usa para esto, OrderRequest, también usa FromBrokerPort. El empleo de una segunda forma de recepción en el mismo puerto de un bucle, junto con los conjuntos de correlaciones, constituyen un patrón habitual de BizTalk Server, el patrón de convoy. El patrón de convoy se utiliza para garantizar que la misma instancia de una orquestación procesa todos los mensajes conectados con una operación determinada.
Cuando el administrador de pedidos recibe el primer mensaje conectado a un pedido, inicializa dos conjuntos de correlaciones. La primera, OrderCorrelation, usa el identificador de cliente (CustID) y el identificador de pedido (OrderID). El administrador de pedidos utiliza esta correlación con las fases de procesamiento de pedidos. La segunda correlación es la correlación del convoy, OrderConvoyCorrelation, que usa el estado del pedido (Estado) además del identificador de cliente y el identificador de pedido. La forma OrderRequestReceive usa OrderConvoyCorrelation como siguiente conjunto de correlación. Esta configuración de la correlación garantiza que la instancia del administrador de pedidos reciba cambios para el pedido que está procesando.
Nota
Recuerde que un conjunto de correlaciones es una agrupación de propiedades de mensaje utilizadas para determinar si un mensaje pertenece a una instancia determinada de una orquestación. Para obtener más información, vea Usar correlaciones en orquestaciones.
Cuando orderManager recibe un mensaje posterior para un pedido, primero prueba el tipo de solicitud. Si TERMINATE es el tipo de solicitud, la forma Decisión ejecuta la rama de finalización. De lo contrario, la orquestación realiza una prueba en el mensaje nuevo para ver si se trata de una actualización. Un mensaje de actualización tiene un número de secuencia mayor (SeqNum) que la solicitud original. Si el número de secuencia del mensaje nuevo es superior, la orquestación comienza el procesamiento del pedido con el mensaje nuevo. Si el mensaje de actualización y el original cuentan con el mismo número de secuencia o el número de secuencia del mensaje de actualización es inferior, existe un error de secuencia. Si los números de secuencia coinciden, el pedido está duplicado y se marca como un error de duplicado.
Para obtener más información sobre SeqNum, vea Key Messages and Fields.
Pasos finales
Después de salir de los bucles, el administrador de pedidos asigna la dirección de respuesta al puerto dinámico CSRCompletionPort. Seguidamente, el administrador construye el mensaje de estado de finalización, lo envía y prueba si se ha producido un error. En caso de que exista un error, la orquestación ejecuta una forma Finalizar; de lo contrario, simplemente termina.
Coordinar con las fases
Tanto la orquestación OrderBroker como la segunda orquestación de fase de procesamiento (CableOrder2) realizan entradas en la base de datos de historial. La orquestación CableOrder2 actualiza la información de historial introducida por la orquestación OrderBroker . Para asegurarse de que hay una entrada en la base de datos que se va a actualizar, OrderBroker usa la notificación de entrega en el puerto que usa para la base de datos.
La configuración asigna el puerto de envío OrderBroker para la base de datos de historial 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 mantiene los dos puertos del grupo activos, la solución envía mensajes en ambos 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. Para obtener más información sobre la notificación de entrega, consulte Uso de confirmaciones.
Errores y enrutamiento de mensajes reparados: opciones de diseño
La orquestación y las orquestaciones del controlador de excepciones usadas por las fases de procesamiento de pedidos usan una orquestación de control de errores (ErrorHandlerOrch) para enrutar los pedidos incorrectos de reparación. El diseño supone que existe un departamento o grupo que arreglará los errores del pedido como sea necesario. El orden reparado no se vuelve a enviar a través de la orquestación del agente de pedidos (OrderBroker). En su lugar, el pedido normalizado se repara en la forma normalizada. En el diseño actual de la solución, la orquestación de controlador enruta el mensaje de error al origen del pedido original. Sin embargo, los pedidos reparados deben enrutarse a un puerto MSMQ en la orquestación de control de errores. (La versión de prueba de la solución usa una carpeta de archivos). A continuación, el controlador de errores devuelve el mensaje reparado a la orquestación que realiza la llamada.
Esta solución utiliza este diseño, pues el agente de pedido realiza una normalización y validación significativa del mensaje de pedido. A su vez, el mensaje de pedido que necesita reparación también se encuentra en la forma normalizada. El mantenimiento de la forma normalizada del mensaje impide tener que tratar la diferencia existente entre las formas enviada y normalizada de los mensajes.
Consulte también
Lógica del administrador de procesos
Mensajes y campos clave