Information Technology Reference
In-Depth Information
• The requirement description
• The story points (integer value)
• The developer ID
• Requirement compiled (true/false)
• Requirement deployed (true/false)
Some of these variables will be filled when the process starts. The project name and the
requirement description will be provided when a new instance of the process needs to be
created. The rest of the activities in the process will generate all the other information.
After the execution of the first activity in our process, the rule engine will fill the process
variable called story points. We will see how this happens later on.
The
userTask
instance in our process, called
Develop Requirement Code
, will
require us to map information from the process scope to the
userTask
scope. We will
be narrowing down the process information to just the information required by this task to
work. This
userTask
instance will be in charge of creating the required code.
For this simple example, and to get the first version of this process working, we will ex-
ecute the data assignments inside the
userTask
object. To see the complete mapping,
open the process definition called
sprintManagement-V1.bpmn2
and look for
userTask
. It can be found in the
chapter-03/BPMN2-scenarios/src/main/
resources
folder of the code section. The code is as follows:
<bpmn2:userTask id="_5" name="Develop Requirement Code">
...
</bpmn2:userTask>
To understand—without all the visual clutter—what is going on inside the variable map-
pings, let's analyze the following XML structure:
<bpmn2:userTask id="_3" name="Develop Requirement Code">
<bpmn2:incoming>_2_3</bpmn2:incoming>
<bpmn2:outgoing>_3_4</bpmn2:outgoing>
<bpmn2:ioSpecification id="_3a">
<bpmn2:dataInput id="_3_requirementInput"
name="requirement"/>
<bpmn2:dataInput id="_3_complexityInput"
name="complexity"/>
