Flusso di lavoro di orchestrazione ordini che genera un ordine basato su regole

È possibile esaminare il workflow di orchestrazione dell'ordine di alto livello di un ordine basato su regole.

flusso di lavoro di orchestrazione ordine — Figura 1. Flusso di lavoro di orchestrazione ordine

Un ordine complesso basato su regole e suddiviso in più ordini figli con interdipendenze tra loro passa principalmente attraverso le seguenti tre fasi di elaborazione nell'applicazione IBM Sterling® Order Management System :

Convalida

Quando un ordine di OrderType 'CustomerOrder' viene creato in IBM Sterling Order Management System, viene inviato a un sistema esterno di Rules Engine, come Operational Decisions ManagerODM) per la convalida. Un servizio SDF viene richiamato sull'evento OnSuccess della transazione ORDER_CREATE . Il servizio invia un messaggio alla coda di convalida e un server di integrazione attiva il processo di convalida dell'ordine richiamando un'API personalizzata.

Se la convalida ha esito positivo, lo stato dell'ordine viene modificato in InProgress dalla transazione ORDER_PROCESS . La transazione ORDER_PROCESS è una transazione ChangeOrderStatus derivata. L'evento OnStatusChange è configurato per inserire un messaggio nella coda di decomposizione.
Se la convalida fallisce, la transazione ORDER_PROCESS viene richiamata per cambiare lo stato dell'ordine in Sospeso (in attesa di convalida) e viene creata un'eccezione di ExceptionType come OrderValidationException utilizzando l'API createException

Scomposizione

Un ordine convalidato viene inviato nuovamente al motore delle regole per ottenere la serie scomposta di ordini eseguibili. Quando un messaggio viene rilasciato nella coda di decomposizione, un server di integrazione prende questo messaggio e attiva il processo di decomposizione dell'ordine richiamando un'API personalizzata. L'API personalizzata prepara un documento di input contenente i dettagli dell'ordine e dell'articolo e crea una richiesta di input per effettuare una chiamata API remota a un sistema del motore di regole esterno, come ODM.

La risposta ricevuta dall'API remota viene quindi elaborata e la transazione createOrder viene richiamata per creare tutti gli ordini scomposti nell'applicazione IBM Sterling Order Management System. Questi ordini scomposti sono conservati nell'applicazione IBM Sterling Order Management System come ordini di vendita con una relazione genitore-figlio tra di loro. Al termine del processo di decomposizione dell'ordine, viene rilasciato un messaggio nella coda di esecuzione del piano di creazione.

Esecuzione e adempimento

Quando un messaggio viene ricevuto nella coda di esecuzione, il server di integrazione attiva il processo di esecuzione dell'ordine richiamando un'API personalizzata. L'API personalizzata crea il documento di input per effettuare una chiamata API remota a un sistema del motore delle regole esterno, come ad esempio ODM per recuperare la sequenza di esecuzione dell'ordine.

La risposta ricevuta dal motore delle regole viene elaborata e la sequenza di esecuzione dell'ordine viene memorizzata nell'applicazione IBM Sterling Order Management System.

L'implementazione dell'API personalizzata elabora queste dipendenze e identifica l'ordine senza dipendenze come l'ordine idoneo per il processo di evasione. Per avviare l'evasione degli ordini idonei, lo stato degli ordini scomposti idonei viene modificato in 'Pronto per l'evasione' utilizzando la transazione ORDER_PROCESS . Tutti gli ordini che si trovano nello stato 'Pronto per l'evasione' sono idonei per essere ritirati da qualsiasi sistema di evasione. Una volta che il sistema di evasione ha terminato l'elaborazione di questi ordini, deve chiamare IBM Sterling Order Management System per cambiare lo stato di tali ordini in "COMPLETATO" utilizzando la transazione ORDER_COMPLETE. La transazione ORDER_COMPLETE deriva da changeOrderStatus e l'evento OnStatusChange viene attivato e configurato per richiamare il servizio EvaluateOrderDependency che aggiorna l'indicatore di dipendenza sulle relazioni di tutti gli altri ordini che dipendono dall'ordine completato.

Viene inviato un messaggio alla coda richiamando il servizio PostMsgToEvaluateDependencyQ per ogni ordine aggiornato. Un server di integrazione acquisisce questo messaggio e richiama un'API personalizzata che valuta se questo ordine non ha più dipendenze in sospeso. Se l'ordine è un ordine scomposto, il suo stato viene modificato in "Pronto per l'evasione". Se l'ordine è un ordine cliente, il suo stato viene modificato in Completato, che termina il processo.