ConfigurationWorkflow. xml
The first file to be created is workflow. xml. The following is a simple example:
<Workflow>
<Persistence type = "DotNetTools. Workflow. Spi. Memory. MemoryWorkflowStore, DotNetTools. Workflow"/>
<Factory type = "DotNetTools. Workflow. Loader. XMLWorkflowFactory">
<Property key = "resource" value = "workflows. xml"/>
</Factory>
</Workflow>
This example shows that we are going to use MemoryWorkflowStore to save process data. In this way, you can reduce the information related to database settings and the possibility of problems. Memory persistence is very convenient for testing.
Workflow factories
The Configuration File above also specifies our workflow Factory (XMLWorkflowFactory). The main function of the workflow factory is to manage the process definition file, including the ability to read and modify the definition file. The 'resource' attribute indicates that the process definition file is read from classpath. According to this definition, create a file named workflows. xml in classpath.
Workflows. xml content:
<Workflows>
<Workflow name = "mytest" type = "file" location = "myworkflow. xml"/>
</Workflows>
We put workflow. xml myworkflow. xml and workflows. xml in the same directory (usually build output directory) so that they can be read by the workflow factory. See the workflow configuration file
In this way, the configuration is complete. Next, initialize a process and call it.
Initialising Workflow
The call mode of Workflow is quite simple: a major interface is used to perform most operations. This interface is IWorkflow interface and its extension Implementation of AbstractWorkflow, such as BasicWorkflow. For simplicity, we use the most basic one: BasicWorkflow.
First, create Workflow. In actual projects, this object should be placed in a global position for reuse, because creating a new Workflow object each time requires expensive system resources. In this example, we use BasicWorkflow. Its builder consists of the User Name of the current caller. Of course, we seldom see the workflow application of a single user, you can refer to other Workflow implementations to obtain the current caller in different ways.
For simplicity, we use BasicWorkflow to create a single user mode, avoiding the trouble of writing other methods to get users.
In this way, create a workflow called by 'testuser:
IWorkflow workflow = new BasicWorkflow ("testuser ");
The next step is to provide the configuration file. In most cases, simply pass a DefaultConfiguration instance:
DefaultConfiguration config = new DefaultConfiguration ();
Workflow. Configuration = config;
Now we have created and configured a workflow, and then we will call it.
Start and start a Workflow
First, we need to call the Initialize method to start a workflow. This method has three parameters: workflow name (defined in workflows. in xml, it is processed through workflow factory), action ID (ID of the initialization action we want to call), and initialization variable. In this example, variables do not need to be initialized, so we just pass a null,
Long workflowId = workflow. Initialize ("mytest", 1, null );
We now have a workflow instance, and the returned workflowId can represent this instance in subsequent operations. This parameter is used in most Workflow interface methods.
Test Workflow
Now let's check whether the started workflow instance runs as expected. According to the process definition, we expect the current step to be the first step and should be able to perform the first action (start writing a draft ).
IList currentSteps = workflow. GetCurrentSteps (workflowId );
// Verification only has one current step
Assert. AreEqual (1, currentSteps. Count, "Unexpected number of current steps ");
// Verify that this step is 1
IStep currentStep = (IStep) currentSteps [0];
Assert. AreEqual (1, currentStep. StepId, "Unexpected current step ");
Int [] availableActions = workflow. GetAvailableActions (workflowId );
// Verify that only one action can be performed
Assert. AreEqual (1, availableActions. Length, "Unexpected number of available actions ");
// Verify that this action is 2
Assert. AreEqual (2, availableActions [0], "Unexpected available action ");
H4 execution action
Now that the workflow instance has been verified, as we expected to go to the first step, let's start to execute the first action:
Workflow. DoAction (workflowId, 2, null );
This is the first simple call action. The workflow engine changes the status to 'underway' Based on the specified conditions and remains in the current step.
Now we can call 2nd actions in a similar way, and all the conditions required by this action have been met.
After calling the 2nd actions, no action is available according to the process definition. GetAvailableActions returns an empty array.
Congratulations: You have completed a workflow definition and successfully called it. In the next section, we will explain some more in-depth concepts of workflow.