Table of Contents:
Introduction
In this tutorial, a moving node wants to send an “Offload” message to a node. It inquires other nodes about their compute capabilities (CPU speed, no. of cores), and if the other node has at least 4 CPU cores, it will use it as the message target.
There are 5 nodes, divided into 3 groups:
- Group 1: One moving node called “M” (M0 )
- Group 2: Two static nodes X1, X2
- X1 and X2 are configured to have 2 CPU cores and a CPU speed of 20,000 MIPS
- Group 3: Two static nodes Y3, Y4
- Y3 and Y3 are configured to have 4 CPU cores and CPU speed of 31,500 MIPS
Hardware configuration in the settings file for Group3, for example, looks like this:
Group3.application1 = processEngineAppY
processEngineAppY.noOfCpus = 4
processEngineAppY.cpuSpeed = 31500
There are 2 process definitions:
-
Process 1 - run by M0, which sends a message named “Get hardware description” to every node it connects to, and then checks the answer. It waits for the response and then checks if the response indicates that the node had at least 4 CPU cores. If yes, it proceeds to trigger work offloading using a message.
-
Process 2 is deployed on the static nodes (X1,X2,Y3,Y4). This process is started by the “Get hardware description” message. It uses a custom Java implementation Task to obtain the hardware specification and then sends a message with the hardware description to the node who started the process (M0 in this scenario).
##
Modelling “Process 2”
Let’s first model Process 2. Make the process start event a “Start message event” which expects a message named “Get hardware description” (See Tutorial 2 how to create such start events).
Getting Hardware specs in Java
Then, add a Simulate Processing Work task from the palette.
Following the example of Tutorial 2, create a subclass of ee.mass.epm.sim.task.SimulatedTask Java class. You can place the file for example in:
step-one/step-one-main/src/main/java/ee/mass/epm/samples/CheckHardwareTask.java
Override & implement the execute(DelegateExecution execution) method as follows:
@Override
public void execute(DelegateExecution execution) {
super.execute(execution);
SimulatedProcessEngineConfiguration engine =
(SimulatedProcessEngineConfiguration) Context.getProcessEngineConfiguration();
int hostAddress = engine.getHostAddress();
DTNHost self = SimScenario.getInstance().getHosts().get(hostAddress);
CpuConf cpuConf = BpmEngineApplication.ofHost(self).getCpuConf();
execution.setVariable("noOfCpus", cpuConf.getNoOfCpus() );
execution.setVariable("cpuSpeed", cpuConf.getCpuSpeed() );
}
- The above code first obtains the SimulatedProcessEngineConfiguration object, which represents the Flowable process engine.
- This allows to use the getHostAddress() method of SimulatedProcessEngineConfiguration, which returns the ONE address of the host running the engine, it is stored in the hostAddress variable.
- With the host address, we can obtain the DTNHost object from the simulated scenario:
- SimScenario.getInstance().getHosts() returns a List of DTNHosts, list indexes correspond to network addresses.
- DTNHost is the ONE simulator class for representing individual hosts
- Next, to obtain a reference to the ONE application that embeds the process engine (BpmEngineApplication) , we use convenience method BpmEngineApplication.ofHost( )
- Finally, the BpmEngineApplication instance provides a method to access the Cpu configuration with getCpuConf(). Using it, two process variables - noOfCpus and cpuSpeed - are set.
With the Java implementation in place, don’t forget to update Simulate Processing Work “Class” property to point to your implementation.
Sending the HW description message
To complete the process, add a Send BP Message task which attaches noOfCpus and cpuSpeed process variables to the message. The Message name should be “Hardware Description”,
Modelling “Process 1”
If you have followed the previous tutorials, you should be able to put together the first 3 tasks of Process 1. Below, we quickly summarize them.
- “Device Connected” is a an Intermediate Signal Catching Event, configured to refer to a “New Connection” Signal
- “Ask hardware description” is a “Send Start Process Message” task, sending a message with name “Get hardware description” to the the address stored in process variable lastConnectAddress (set by the connection signal event)
- “Hardware Description Received” is an intermediate Message catching event for a message named “Hardware Description” (Sent from Process 2).
XOR-gateway
Now that we have received the hardware description message, we want to make a decision based on it. For this we use an XOR-gateway.
Add the XOR gateway to the process and create 2 outgoing flows:
- First one advancing the flow (it will be later connected to a send message task)
- Second one going back to “Device Connected”
- For the first flow arrow, we will set its flow condition property to ${ noOfCpus >= 4}
- This expression evaluated during runtime, it uses the process variable we received with the hardware description message. If this flow condition is evaluated to be true, the process will proceed using this path.
- For the second flow, instead of specifying a flow condition, we will set it to be the “Default flow”.
- This means if other flows of the XOR gateway are not evaluated to be true, this default flow will be taken. The default flow is visualized with a small line crossing the flow.
The below video demonstrates how to set up these flow conditions.
Completing the process
Finally, add a Send BP Message task, as a kind of a placeholder for now invoking some services (offloading work) on the node we have identified to have the required number of CPUs.
This message task should be after the XOR gateway outgoing flow with the flow condition. The actual message handling we are not covering here, it has been done in previous tutorials.
Running the scenario
Recall the different CPU configurations of X1, X2, Y3, Y4.
If you run the simulation, you should see the hardware description message exchanges with X1 and X2, but no “Offload work” message, because the XOR gateway flow which checks the noOfCpus variable value does not yield a true value. With Y3 however, the XOR gateway flow proceeds to the Offload message task.
