◷ Reading Time: 5 minutes
Long-running business process
A long-running business process or transaction is when the whole end-to-end process might take days and weeks if not months or years to complete. A good example is when:
- A person goes to his or her GP and the doctor asks for a blood test.
- Then the doctor gives a patient a blood test exam and sends the patient to a lab
- The patient goes to a lab and does the blood test
- The lab requires a couple of days to run the test and prepare the results to send to the GP
- The patient now should get an appointment with the GP in a couple of days and visit the GP
Let’s say in this example that’s the end of the process. As you can see, this process takes days to be completed. At any stage different actors can participate in the whole process:
To model this type of process, you can also use multiple sets of smaller Flows and manage the connection between them. In order to make it simpler, you can use a Workflow.
Let’s create a simple Workflow model using the FlexRule Designer:
Also define an input parameter (In) called lab result, as shown below:
When you add a receive task, set the properties below:
- Title: Lab Result
- Display Name: Send lab result
This means that in the Receive Task the actor (using your application) can query what actions are available. At this stage, your application can show the actor the actions (with the above properties) that are available. The actor can set the lab result parameter and send a Signal to the workflow to continue from this step onward.
If you look at the XML model of Workflow you can see the definition below:
<Workflow name="WorkflowWorkflow2" version="126.96.36.199"> <Declaration> <Define name="lab result" direction="In" /> </Declaration> <Nodes> <Start name="Start1"> <Transition name="Transition1" to="Task1" /> </Start> <End name="End1" /> <Task name="Task1" title="Lab Result" displayName="Send lab result"> <Transition name="Transition4" to="End1" /> </Task> </Nodes> </Workflow>
A Workflow is no different from any other logic, so you can simply use RuntimeEngine to load and Run workflow. For some specific Workflow functionality, the RuntimeEngine has a Workflow property that can be used. Other than that it is the same as a normal Flow.
When a generic flow is executed using the Run method it will be going from start to finish. In the workflow, when execution reaches a Task or Timeout, Workflow goes into a Waiting state, and execution control comes to your application. Then you can decide when to Resume the workflow from wherever it was last time.
With a workflow you can:
- Run: which creates a new instance of a workflow. That’s called a Workflow Instance.
- Resume: which continues a Workflow Instance from the last state. To continue a workflow instance you need to provide its latest context and a Signal
To run a workflow you need to:
- Create an engine using RuntimeEngine
- Call the Run method by passing input parameters
byte workflowModel=Encoding.UTF8.GetBytes(wf); var engine = RuntimeEngine.FromXml(workflowModel); // Now we call the run method. var result = engine.Run((object) null);
In the above sample code, we pass null to the lab result parameter, as this parameter will be used later on for providing the lab results.
At this stage, the workflow will be run and execution will be returned to your code.
For a long-running business process, you need to manage the context in order to resume it later. To access context you can use the line below:
var context = (WorkflowExecutionContext) result.Context;
If you check the state of Workflow you would notice it is not Complete and instead it is Waiting.
When a workflow state is on Waiting you can resume the workflow by providing the context.
context.VariableContainer["lab result"] = CreateLabResultObject(); engine.Workflow.Resume(context, new ReceiverSignal("Lab Result"));
In the above example your application will need to:
- Create and pass lab result (i.e., CreateLabResultObject method). This can be of any type.
- Specify a signal by using ReceiverSignal to let the workflow instance know with what Task to continue. There might be a situation where multiple Tasks are available to continue. Signal will tell the instance of what execution path to take.
If you check the workflow state you will find that it is completed now.