Table of Contents:


Introduction

In this tutorial you will see how to hosts can start processes on other hosts and simulate long-running compute tasks.

The simulation environment is identical to the one in Tutorial 1. However, this time, when the scenario is started, node A is running Process A, while node B is not running any processes, nor does it have any processes deployed.

Process A deploys a process (Process B) to node B and then starts it via a message. The deployed process involves running a task (“Do Simulated Work”) which imitates a long-running computation. The duration of the computation task depends on the hardware configuration of node B and the worksize of this particular task. In this tutorial, the size is specified with a process variable, that Process A attached to the message when it started the process instance. After finishing the work task, Process B sends a message back to A, concluding the process for both.

Process A:

Process A

Process B:

Process B

Let’s begin by defining Process A. Set the process key of Process A to be tutorial2_simple_offload .

Deploying A Process

Add a “Deploy Process” task from STEP-ONE palette.

Deploy Process is a kind of Message task, which in addition to the message parameters such as destination and message size, needs a “Deployed resource path” property to be defined. This corresponds to the bpmn.xml file on your machine running the simulation, that will be deployed to the message destination.

Set the destination address to be “1” (node B), and the Deployed resource path to:

samples/tutorial2_offloading/Tutorial_2_Deployed_Process.bpmn20.xml

This is the path of the 2nd process which we will define alter below.

Process B

Starting a process instance

Another special kind of message is the “Start Process” message, which will make the recipient’s process engine start a new instance of a process, assuming that the process definition has already been deployed on the message recipient.

Add the Send “Start Process” Message element from the palette to the process.

Now consider: if the recipient of this message has multiple processes deployed, how does it know which process to start when receiving a Start Process message?

This is handled through the Message Name. If there is a process definition whose Start Event is subscribed to a message with the exact name as the incoming Start Process message name, the engine starts a new instance.

For this example, let’s use the message name "Start Offloaded Process", we will see how to create a process whose start event is subscribed to this message name.

Also, let’s attach the “workSize” variable to this message. The value of workSize has been specified in the simulation run configuration.

As the final part of this process, we will wait for a message to come back from the deployed process, as an indicator that it has finished its work. For this, add a “Intermediate message catch event” that waits for a message with the name “Work Finished”. See Tutorial 1 if you need help defining message catch events.

This concludes the process of node A.

Process B Start Message Event

Let’s now model the 2nd process: This is the process A is deploying to B.

First, to be able to start this process from a message, we have to define a Start Message Event.

Create a message definition for the start Event, the message should have the name “Start Offloaded Process”. This is message node A has to send to start a new instance of this process.

Simulated Computation Work

The “Simulate Processing Work” task allows to define a task which will finish only after a certain amount of simulation time has passed. The time depends on the hosts CPU configuration and Work Size parameter of the task. Further, the actual time will be reduced if there are multiple processes simultaneously running processing tasks on the same host.

The below screenshot shows the “Work size” for the simulated processing task which is assigned the value of process variable “workSize”.

Process B

Note: The default CPU configuration in STEP-ONE for a node is to have 1 CPU core with a speed of 10,000 MIPS. We will not look at how to customize this value in this tutorial.

Finishing Process B and Running

As the last activity, let’s make the 2nd process send a message after the simulated processing is finished. For this, add a Send BP Message task that will send a message with the name Work Finished . Make the destination of this message the value of the process variable startMessageSenderAddress. This is a special variable is set by STEP-ONE whenever a process instance is started using Start Process message. In this case, during runtime the value would be the address of host A.

If you have these two models in place, let’s inspect the simulation configuraiton for this tutorial:

Scenario.name = Tutorial2_Offloading

processEngineApp1.autoDeployedProcesses = samples/tutorial2_offloading/Tutorial_2_Simple_Offloading.bpmn20.xml

processEngineApp1.autoStartedProcessKeys = tutorial2_simple_offload
processEngineApp1.autoStartedProcessVars = workSize=30000

Note that we are only deploying (and starting) processes for processEngineApp1, which is the engine of Node A. When we start the process with key tutorial2_simple_offload, we are also specifying the value 30000 for the variable workSize. This is the variable that is sent to B when the 2nd process is started after deployment and used as the value of the Simulated computation work task.

When running this simulation, you should see similar behavior as below:

Note that during timestep 6, node B is working on the compute task, no messages are being exchanged. Try changing the workSize value to confirm that larger tasks take longer to complete.


Back to Home