Workflow: The diagram of the business processes and decisions

Workflow configuration structure are given in the following:

{“configuration”:{“first_step”:”First step sid”,”filters”:{“Filter sid”:{“true_queue_sid”:”Tru Queue sid”,”true_filter_sid”:”Tru Filter sid”,”false_queue_sid”:”False Queue sid”,”false_filter_sid”:”False Filter sid”,”next_step”:”Next Step sid”,”forks”:[{“workflowSid”:”Workflow sid”,”timeout”:”<duration>”}],”name”:”Name”,”conditions”:”Conditions”,”looping_on_false”:”Loop if True”,”loop_max_retries”:”Loop Maximum Retries”,”loop_delay_minutes”:”Loop Delay Duration”,”delay_by_date_in_task_field”:”Delay by Defined Date”,”delay_minutes”:”Delay Duration”}}}}

Consider a system consists of various components such as electromechanics and electronics devices that could fail. Predictive maintenance (PdM) solution monitors the system to allow the early detection of potential failures of devices. Generally, PdM analysis the log data of devices by using machine learning algorithms to detect the anomalies and failures of the system.  Following failure detection, a process management system will control and manage the tasks needed to handle the failure. Various conditions can lead to a failure and various decisions to fix the failure can be utilized. These conditions and decisions are defined in the Workflow Configuration part of the process management system. 

Now, let’s begin with a simple scenario of system failure. For instance, suppose AI detects a failure (the device is broken) for device A.  Afterwards, device A needs to be repaired by a technician. Following that, Workflow configuration of this simple scenario is defined as follows. Suppose “Failure Repairing Technician” Queue has a sid “TQ111”.

{“configuration”:{“first_step”:”FS111″,”filters”:{“FS111”:{“true_queue_sid”:”TQ111″,”name”:”Failur1″,”conditions”:{“==”:[{“var”:”Device A”},”Broken”]}}}}}

Moreover, consider there are many stations in the system that consists of devices. If device A from station B has broken, firstly a notification of broken is sent to the Failure Repairing Technician. Else, if device A form station B needs maintenance, an email is sent to the support team. Now two queues are defined in this situation. “Send notification to Failure Repairing Technician” and “Send email to support team” queues with “TQ111” and “TQ222” sid respectively. 

{“configuration”:{“first_step”:”FS111″,”filters”:{“FS111”:{“true_filter_sid”:”FS222″,”false_filter_sid”:”FS333″,”name”:”Name1″,”conditions”:{“==”:[{“var”:”Device A”},”Broken”]}},”FS222″:{“true_queue_sid”:”TQ111″,”name”:”Name2″,”conditions”:{“==”:[{“var”:”Station”},”B”]}},”FS333″:{“true_queue_sid”:”TQ222″,”name”:”Name3″,”conditions”:{“==”:[{“var”:”Device A”},”Maintenance needed”]}}}}}

Loop

Loop is another property of Workflow Configuration that allows a task to be looped until it’s done. Consider there are many stations in the system that consists of devices. If device A from station B has broken, the process management system sends a notification of broken to the Failure Repairing Technician per 2 hours (Loop Delay Duration) for 2 times (Loop Maximum Retries) until the technician feedbacks about the results of repairing. Suppose we have a “Failure Repairing Technician” Queue with a SID “TQ111”.

{“configuration”:{“first_step”:”FS111″,”filters”:{“FS111”:{“true_queue_sid”:”TQ111″,”name”:”Name1″,”conditions”:{“==”:[{“var”:”Device A”},”Broken”]}}, “looping_on_false”:true, “loop_max_retries”:2, “loop_delay_minutes”:2}}}

Delay

Delay can be applied in two ways: Delay by predefined date and Delay by minutes. In addition, these two delay options can not be used together. In the above example, suppose device A’s failure must be repaired by a technician after a 120 minutes delay. By defining Delay by minutes, notification of failure will be sent to the Failure Repairing Technician. Or by defining Delay by predefined date, sending failure notification to the technician will be delayed until predefined date.  

{“configuration”:{“first_step”:”FS111″,”filters”:{“FS111”:{“true_queue_sid”:”TQ111″,”name”:”Name1″,”conditions”:{“==”:[{“var”:”Device A”},”Broken”]}},”delay_by_date_in_task_field”:”12/10/2020″}}}

Fork

One of the most important properties of Workflow is forks defined in the Workflow Configuration. See Task Forking for more details. In Task Forking, the various Workflows can be handled simultaneously and independently without waiting for each other. 

Suppose, device A consists of various pieces. Failure of any pieces leads to break device A. Consider piece A and B of device A are broken. Repairing these pieces needs to be done by different department technicians. In order to handle this situation, the Task is forked into two individual Workflows. Above all, Forking property enables the repairing process to be accomplished in parallel. That means, piece A is sent to Workflow 1 for repair and piece B is sent to Workflow 2.  

{“configuration”:{“first_step”:”FS111″,”filters”:{“FS111”:{“next_step”:”FS222″,”name”:”Name1″,”conditions”:{“==”:[{“var”:”Device A”},”Broken”]}},”forks”:[{“workflowSid”:”Workflow 1″,”timeout”:25},{“workflowSid”:”Workflow 2″,”timeout”:15}]}}}