Flujo de trabajo de orquestación de pedidos que genera un orden basado en reglas

Puede revisar el flujo de trabajo de orquestación de orden de alto nivel de una orden basada en reglas.

Un pedido complejo basado en reglas que se descompone en varios pedidos secundarios con interdependencias entre ellos pasa principalmente por las tres etapas siguientes de procesamiento en la aplicación IBM Sterling® Order Management System :

Validación

Cuando se crea un pedido de OrderType como 'CustomerOrder' en IBM Sterling Order Management System, se envía a un sistema externo de Rules Engine, como Operational Decisions ManagerODM) para su validación. Se invoca un servicio SDF en el suceso OnSuccess de la transacción ORDER_CREATE . El servicio envía un mensaje a la cola de validación y un servidor de integración desencadena el proceso de validación de orden llamando a una API personalizada.

Si la validación es satisfactoria, la transacción ORDER_PROCESS cambia el estado de la orden a InProgress . La transacción ORDER_PROCESS es una transacción ChangeOrderStatus derivada. El suceso OnStatusChange se configura para colocar un mensaje en la cola de descomposición.
Si la validación falla, se llama a la ORDER_PROCESS transacción para cambiar el estado del pedido a Suspendido (Esperando Validación) y se crea una excepción de ExceptionType como OrderValidationException utilizando la createException API.

DECOMPOSITION

Una orden validada se devuelve al motor de reglas para obtener el conjunto descompuesto de órdenes ejecutables. Cuando se suelta un mensaje en la cola de descomposición, un servidor de integración recoge este mensaje y desencadena el proceso de descomposición de pedidos llamando a una API personalizada. La API personalizada prepara un documento de entrada que contiene detalles de orden, así como detalles de artículo y crea una solicitud de entrada para realizar una llamada de API remota a un sistema de motor de reglas externo, como por ejemplo ODM.

A continuación, se procesa la respuesta recibida de la API remota y se llama a la createOrder transacción para crear todos los pedidos descompuestos en la aplicación IBM Sterling Order Management System. Estos pedidos descompuestos se mantienen en la aplicación IBM Sterling Order Management System como pedidos de venta con una relación padre-hijo entre ellos. Al final del proceso de descomposición de pedidos, se descarta un mensaje en la cola de ejecución del plan de compilación.

Ejecución y cumplimentación

Cuando se recibe un mensaje en la cola de ejecución, un servidor de integración desencadena el proceso de ejecución de orden llamando a una API personalizada. La API personalizada crea el documento de entrada para realizar una llamada de API remota a un sistema de motor de reglas externo, como por ejemplo ODM para captar la secuencia de ejecución de orden.

La respuesta recibida del motor de reglas se procesa y la secuencia de ejecución de la orden se mantiene en la aplicación IBM Sterling Order Management System.

La implementación de API personalizada procesa estas dependencias e identifica la orden sin dependencias como la orden que es elegible para el proceso de cumplimentación. Para iniciar la tramitación de órdenes elegibles, el estado de las órdenes descompuestas elegibles se cambia a 'Preparado para tramitación' utilizando la transacción ORDER_PROCESS . Todos los pedidos que están en estado 'Preparado para despacho' son elegibles para ser recogidos por cualquier sistema de despacho. Una vez que el sistema de ejecución ha terminado de procesar estos pedidos, tiene que llamar a IBM Sterling Order Management System para cambiar el estado de dichos pedidos a "COMPLETADO" utilizando la transacción ORDER_COMPLETE. La transacción ORDER_COMPLETE se deriva de changeOrderStatus y el suceso OnStatusChange se activa y se configura para invocar el servicio EvaluateOrderDependency que actualiza el distintivo de dependencia en las relaciones de todas las demás órdenes que dependen de la orden completada.

Se envía un mensaje a la cola invocando el servicio PostMsgToEvaluateDependencyQ para cada pedido actualizado. Un servidor de integración recoge este mensaje y llama a una API personalizada que evalúa si este pedido no tiene más dependencias pendientes. Si el pedido es un pedido descompuesto, su estado cambia a "Preparado para despacho". Si el pedido es un pedido de cliente, su estado cambia a Completado, lo que finaliza el proceso.