Fast forwarding time for activities to mimic long durations

I am building a demo data generator that pumps the engine with process instances. One of the things I want to do is to have some activities to have longer durations than others, so we can show the duration heat map in Optimize for example. Up until now I am pausing the process to do this (using durations of msecs), but that is not practical for large numbers of processes or durations that might last days!

There are ways of overriding the Java clock in a JVM using java.time.Clock, but I am thinking that will affect the clock for the whole JVM. I want to be able to fast forward time for individual activities within a given process instance.

So, is there a way of overriding the start and end times of an activity, once the activity has completed?

Hi @Justin_Phillips,

there are alraedy two solutions to generate load on the process engine:

and https://github.com/camunda-consulting/camunda-util-demo-data-generator

You can have a look how the problem is solved there.

Hope this helps, Ingo

1 Like

Hi, so I am trying to use the embedded demo data generator from the link in the previous post (not the web app), and I have the following exception when I run the application.

java.lang.RuntimeException: org.camunda.bpm.engine.ProcessEngineException: ENGINE-08043 Exception while performing 'Deployment of Process Application myProcessApp' => 'Deployment of process archive 'null': Cannot deploy process archive 'null' to default process: no such process engine exists: processEngine is null

My application is a Spring boot application with the following entry point.

/**
 * ExampleApp.
 */
@SpringBootApplication
@EnableProcessApplication("myProcessApp")
public class MyProcessApp extends SpringProcessApplication {
    public static void main(final String[] args) {
        new MyProcessApp().run(args);
    }

    public void run(final String[] args) {
        SpringApplication.run(MyProcessApp.class, args);
    }

    @PostDeploy
    public void startFirstProcess(ProcessEngine processEngine) {
        DemoDataGenerator.autoGenerateFor(processEngine, "myProcessApp", getReference());
    }
}

Any ideas as to what might be causing this, thanks in advance? Do you have an example project with a Springboot application using the demo data generator I could look at?

OK a bit more info. The above code is failing in method org.camunda.bpm.container.impl.spi.DeploymentOperation.execute() when trying to deploy the process archive step. Below is the output of the debugger and the code being run:

It is trying to load the process archive from the details in the processes.xml file.

<process-application
        xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <process-archive>
        <properties>
            <property name="isDeleteUponUndeploy">false</property>
            <property name="isScanForProcessDefinitions">true</property>
            <property name="jobExecutorActivate">true</property>
        </properties>
    </process-archive>

</process-application>

I am guessing then because I am extending SpringProcessApplication, it is no longer using Spring annotations to discover the application properties (e.g. @EnableProcessApplication, but now expecting to see them in the processes.xml file?

OK got a bit further and I no longer get any blowups around the deployment phase. My revised application code is as follows:

@SpringBootApplication
@ProcessApplication
public class MyProcessApp extends SpringBootProcessApplication{
    public static void main(final String[] args) {
        new MyProcessApp().run(args);
    }

    public void run(final String[] args) {
        SpringApplication.run(MyProcessApp.class, args);
    }

    @PostDeploy
    public void startFirstProcess(ProcessEngine processEngine) {
        DemoDataGenerator.autoGenerateFor(processEngine, "myProcessApp", getReference());
    }
}

Seems I needed to swap out @EnableProcessApplication for @ProcessApplication. I have other blow ups that need looking into though.