Evaluating COPPER for managing simple (but somehow distributed) wotrkflow

[Eugene Dzhurinsky]

Hi there! I need to create some simple workflow for CRM, like described below:

- a user signs up and receives the confirmation email

- the system waits for the event "the user has opened the email" for 24 hours

- if the user opened the email but didn't complete the signup by clicking on certain link - we need to send another email

- if the user has never opened the email (or we didn't get the event for any reason) - then we need to send yet another email

- etc

The workflow might be somehow complex, that's why I think that COPPER will help a lot, because we can code the workflow in Java. However from the documentation and examples it's not clear for me

- how do I distinguish timeouts from event triggers in a wait call?

- is it possible to distribute the workflow among multiple servers, so for example the event "signup" might occur on one server and the workflow will be created, and the event "confirm signup" could occur on another server (and the workflow should be terminated)

Many thanks in advance!

[Michael Austermann]

Hi!

I am pretty sure, that copper meets the requirements that you outlined.

You distinguish timeouts from responses/event triggers as follows:

Assume that you are waiting for a response with correlationId CID:

wait(WaitMode.ALL, 24*60*60*1000, CID); // wait up to 24h for a response with correlatinId==CID

Response<?> r = getAndRemoveResponse(CID);

if (r.isTimeout()) {

  // 24h and no response...

  // send eMail again to customer...

}

else {

  // process the response...

  foo(r.getResponse());

}

By the way: You feed response to the system by using "ProcessingEngine.notify"

Regarding your question with distributed servers:

Well, it is possible to have multiple engines being connected to the same database - see e.g. org.copperengine.core.persistent.AbstractSqlDialect.setMultiEngineMode(boolean)

Any of these engines can start new workflow instances, process steps of existing workflow instances or feed responses to the system.

So if you want one engine to only start new workflow instances or feed respones you could just configure this engine with a different processor pool than the others.

Assume that engine A has a processor pool named A and engine B has processor pool B (you can chose names for the pools in the configuration).

So engine A could start a workflow instance in pool  B - which would lead to a situation where only B would process the workflows although A has started them.

You can also change the processor pool of a workflow instance during execution so that it will change it's engine in this case:

setProcessorPoolId("A");

resubmit();

// this workflow instance is running in pool "A" -

setProcessorPoolId("B");

resubmit();

// this workflow instance is running in pool "B" - 

Hope this answers your questions.

/Michael

---

Von: "Eugene Dzhurinsky" <jdev...@gmail.com>
An: "COPPER Engine" <copper...@googlegroups.com>
Gesendet: Freitag, 9. September 2016 14:47:37
Betreff: [COPPER Users] Evaluating COPPER for managing simple (but somehow distributed) wotrkflow

--
You received this message because you are subscribed to the Google Groups "COPPER Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to copper-engin...@googlegroups.com.
To post to this group, send email to copper...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/copper-engine/23c51cad-5e3f-4802-9122-319ba184f7b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eugene Dzhurinsky]

Michael, thank you very much for such a prompt and comprehensive response!

I will definitely try to create some proof of concept implementation for our workflow, so fat it looks like I've found the right tool :)

Thanks again!

[Eugene Dzhurinsky]

Michael, I'm just curious - does the java files have to be in-place to start the workflow? 

Can I use compiled class files instead?

[Michael Austermann]

I guess this thread will answer your question:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/copper-engine/NqDu6Zu_wX8

/Michael

---

Von: "Eugene Dzhurinsky" <jdev...@gmail.com>
An: "COPPER Engine" <copper...@googlegroups.com>

Gesendet: Donnerstag, 22. September 2016 00:17:54
Betreff: [COPPER Users] Re: Evaluating COPPER for managing simple (but somehow distributed) wotrkflow

Michael, I'm just curious - does the java files have to be in-place to start the workflow? 

Can I use compiled class files instead?

--

You received this message because you are subscribed to the Google Groups "COPPER Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to copper-engin...@googlegroups.com.
To post to this group, send email to copper...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/copper-engine/e8900272-c217-4083-be1b-26d494909682%40googlegroups.com.

[Eugene Dzhurinsky]

Indeed it does, I needed to plug the copper-ext module into Maven. Thanks!

Can you please look into the following relatively simple case:

import java.io.File


import my.workflow.SignupWorkflow.WorkflowState
import org.copperengine.core._
import org.copperengine.core.common.WorkflowRepository
import org.copperengine.core.tranzient.TransientEngineFactory
import org.copperengine.ext.wfrepo.classpath.ClasspathWorkflowRepository


object SignupWorkflow {

  case class WorkflowState(data: Int)

  def main(args: Array[String]): Unit = {
    val wfRepo = new ClasspathWorkflowRepository("my.workflow")
    val engineFactory = new TransientEngineFactory {

      override def createWorkflowRepository(): WorkflowRepository = wfRepo

      override def getWorkflowSourceDirectory: File = null

    }
    val engine = engineFactory.create()
    engine.run("TestAlias", WorkflowState(100500))
    Thread.sleep(10000)
    engine.notify(new Response[String]("test123", "PASSED", null), new Acknowledge.DefaultAcknowledge())
    engine.shutdown()
  }


}


@WorkflowDescription(alias = "TestAlias", majorVersion = 1, minorVersion = 0, patchLevelVersion = 0)
case class SignupWorkflowImpl() extends Workflow[WorkflowState] {
  override def main(): Unit = {
    println(getData)
    wait(WaitMode.FIRST, -1, "test123")
    val resp = getAndRemoveResponse("test123")
    println("Got response " + resp)
  }
}

For some reason wait returns immediately, and the result of getAndRemoveResponse is null. I double checked the examples from https://github.com/copper-engine/copper-starter/ and I can't figure out what do I do wrong in my code. The workflow is created with the proper initialization data.

[Howie T]

I wonder why you need the copper-ext library to do so...

Meanwhile for the wait() problem, which version of copper are you using? Can this help you: https://github.com/copper-engine/copper-engine/issues/53 

[Eugene Dzhurinsky]

The base package - copper-coreengine doesn't contain the ClasspathWorkflowRepository

As for the wait problem it doesn't terminate, the line 

val resp = getAndRemoveResponse("test123")

returns null instead of a response. And "wait" doesn't actually wait for anything.

I use version 4.1.1 with TransientEngineFactory, so no database is involved.

[Howie T]

I see, I had experienced such problems before, please take a look at Michael's response in: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/copper-engine/Jrucl_Tic7I

[Michael Austermann]

If method "wait" returns immediately, then the workflow class is not instrumented.

Make sure that you workflow class is in an extra package and give this package name to the classpathworkflowrepo.

Furthermore I never tried copper with groovy - maybe there is an incompatibility - I don't know.

You can also increase the loglevel of copper to DEBUG or TRACE and see the logging output of the repo class.

It will tell you what classes it has instrumented.

---

Von: "Eugene Dzhurinsky" <jdev...@gmail.com>
An: "COPPER Engine" <copper...@googlegroups.com>

CC: "michael austermann" <michael.a...@scoop-software.de>
Gesendet: Freitag, 23. September 2016 05:01:57
Betreff: Re: [COPPER Users] Re: Evaluating COPPER for managing simple (but somehow distributed) wotrkflow

[Eugene Dzhurinsky]

Thanks, So I've added some more code and more logging:

https://gist.github.com/jdevelop/8088162a3f6d1fb22afc5f31241ab669

The output is:

2016-09-23 10:28:07,731 INFO   [DefaultProcessorPoolManager] addProcessorPool(T#DEFAULT)

2016-09-23 10:28:07,734 INFO   [TransientScottyEngine] Engine is starting up...
2016-09-23 10:28:07,736 INFO   [ClasspathWorkflowRepository] Starting up with wfPackages=[my.workflow.test]
2016-09-23 10:28:07,736 INFO   [ClasspathWorkflowRepository] adaptedTargetDir=/tmp/cpwfrepo1474640887736
2016-09-23 10:28:08,219 INFO   [ClasspathWorkflowRepository] wfSet.size=4
2016-09-23 10:28:08,219 INFO   [ClasspathWorkflowRepository] Analysing classfiles
2016-09-23 10:28:08,219 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflow$WorkflowState$
2016-09-23 10:28:08,230 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflowImpl
2016-09-23 10:28:08,230 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflow
2016-09-23 10:28:08,230 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflow$WorkflowState
2016-09-23 10:28:08,236 INFO   [AbstractWorkflowRepository] Instrumenting classfiles
2016-09-23 10:28:08,261 INFO   [ScottyClassAdapter] Transforming my/workflow/test/SignupWorkflowImpl
2016-09-23 10:28:08,277 INFO   [AbstractWorkflowRepository] CheckClassAdapter.verify succeeded for class my/workflow/test/SignupWorkflowImpl
2016-09-23 10:28:08,277 INFO   [AbstractWorkflowRepository] Creating classes
2016-09-23 10:28:08,278 INFO   [AbstractWorkflowRepository] my.workflow.test.SignupWorkflowImpl created
2016-09-23 10:28:08,289 INFO   [ClasspathWorkflowRepository] Startup finished
2016-09-23 10:28:08,289 INFO   [TimeoutManager] started
2016-09-23 10:28:08,289 DEBUG  [TimeoutManager] Activated at: 1474640888289
2016-09-23 10:28:08,290 DEBUG  [TimeoutManager] There are currently no timeout slots - waiting indefinitely...
2016-09-23 10:28:08,290 INFO   [DefaultEarlyResponseContainer] started
2016-09-23 10:28:08,290 INFO   [PriorityProcessorPool] ProcessorPool T#DEFAULT: Starting up
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [Processor] started
2016-09-23 10:28:08,291 INFO   [TransientScottyEngine] Engine is running
2016-09-23 10:28:08,294 DEBUG  [Workflow] Creating new my.workflow.test.SignupWorkflowImpl
2016-09-23 10:28:08,294 INFO   [DefaultTicketPoolManager] Mapping workflow class 'my.workflow.test.SignupWorkflowImpl' to ticket pool DEFAULT
2016-09-23 10:28:08,294 DEBUG  [TicketPool] Trying to obtain 1 tickets. DEFAULT: 0 of 2000 tickets used
2016-09-23 10:28:08,294 DEBUG  [TicketPool] Obtained my tickets! DEFAULT: 1 of 2000 tickets used
2016-09-23 10:28:08,295 INFO   [Processor] started
2016-09-23 10:28:08,305 DEBUG  [TransientScottyEngine] registerCallbacks(Workflow [id=45120f01-4aca-40cf-a132-9bf2ee02e5a1, priority=5, processorPoolId=T#DEFAULT], ALL, 0, [test123])
Got response null
2016-09-23 10:28:08,345 DEBUG  [TicketPool] Released 1 tickets! (Now DEFAULT: 0 of 2000 tickets used)
2016-09-23 10:28:18,304 DEBUG  [TransientScottyEngine] notify(Response [correlationId=test123, response=OLOLO, exception=null, timeout=false, metaData=null, internalProcessingTimeout=null, earlyResponseHandling=true, responseId=null, sequenceId=null])
2016-09-23 10:28:18,304 ERROR  [TransientScottyEngine] Workflow with id 45120f01-4aca-40cf-a132-9bf2ee02e5a1 not found
2016-09-23 10:28:18,304 INFO   [TransientScottyEngine] Engine is shutting down...
2016-09-23 10:28:18,305 INFO   [DefaultProcessorPoolManager] Shutting down...
2016-09-23 10:28:18,305 INFO   [TimeoutManager] stopped
2016-09-23 10:28:18,305 INFO   [PriorityProcessorPool] ProcessorPool T#DEFAULT: Shutting down
2016-09-23 10:28:18,305 INFO   [DefaultEarlyResponseContainer] stopped
2016-09-23 10:28:18,305 INFO   [Processor] Stopping processor 'T#DEFAULT#0'...
2016-09-23 10:28:18,305 INFO   [Processor] Stopping processor 'T#DEFAULT#1'...
2016-09-23 10:28:18,305 INFO   [Processor] stopped
2016-09-23 10:28:18,305 INFO   [Processor] stopped
2016-09-23 10:28:18,305 INFO   [Processor] Stopping processor 'T#DEFAULT#2'...
2016-09-23 10:28:18,306 INFO   [Processor] Stopping processor 'T#DEFAULT#3'...
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [Processor] Stopping processor 'T#DEFAULT#4'...
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [Processor] Stopping processor 'T#DEFAULT#5'...
2016-09-23 10:28:18,306 INFO   [Processor] Stopping processor 'T#DEFAULT#6'...
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [Processor] Stopping processor 'T#DEFAULT#7'...
2016-09-23 10:28:18,306 INFO   [Processor] stopped
2016-09-23 10:28:18,306 INFO   [TransientScottyEngine] Engine is stopped


Process finished with exit code 0

So basically I can see that the class SignupWorkflowImpl is instrumented. This is not Groovy but Scala, it it does matter.

Then I moved the workflow into the Java file:

package my.workflow.test;

import org.copperengine.core.Interrupt;

import org.copperengine.core.Response;

import org.copperengine.core.Workflow;

import org.copperengine.core.WorkflowDescription;

@WorkflowDescription(alias = "TestAlias", majorVersion = 1, minorVersion = 0, patchLevelVersion = 0)

public class SignupWorkflowImpl extends Workflow<Integer> {


    @Override
    public void main() throws Interrupt {
        waitForAll("test123");
        Response<?> resp = getAndRemoveResponse("test123");
        System.err.println("Got response " + resp);


    }
}

And everything worked as expected - it does wait until the workflow finishes.

2016-09-23 10:35:32,829 INFO   [DefaultProcessorPoolManager] addProcessorPool(T#DEFAULT)
2016-09-23 10:35:32,832 INFO   [TransientScottyEngine] Engine is starting up...
2016-09-23 10:35:32,833 INFO   [ClasspathWorkflowRepository] Starting up with wfPackages=[my.workflow.test]
2016-09-23 10:35:32,833 INFO   [ClasspathWorkflowRepository] adaptedTargetDir=/tmp/cpwfrepo1474641332833
2016-09-23 10:35:33,356 INFO   [ClasspathWorkflowRepository] wfSet.size=2
2016-09-23 10:35:33,356 INFO   [ClasspathWorkflowRepository] Analysing classfiles
2016-09-23 10:35:33,357 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflow
2016-09-23 10:35:33,367 INFO   [ClasspathWorkflowRepository] analysing class my.workflow.test.SignupWorkflowImpl
2016-09-23 10:35:33,373 INFO   [AbstractWorkflowRepository] Instrumenting classfiles
2016-09-23 10:35:33,395 INFO   [ScottyClassAdapter] Transforming my/workflow/test/SignupWorkflowImpl
2016-09-23 10:35:33,395 DEBUG  [ScottyClassAdapter] Transforming my/workflow/test/SignupWorkflowImpl.main()V
2016-09-23 10:35:33,400 DEBUG  [BuildStackInfoAdapter] label L800074881
2016-09-23 10:35:33,400 DEBUG  [BuildStackInfoAdapter] varInsn: ALOAD 0
2016-09-23 10:35:33,400 DEBUG  [BuildStackInfoAdapter] insn H_PUTSTATIC
2016-09-23 10:35:33,401 DEBUG  [BuildStackInfoAdapter] typeInsn: ANEWARRAY java/lang/String
2016-09-23 10:35:33,401 DEBUG  [BuildStackInfoAdapter] insn DUP
2016-09-23 10:35:33,401 DEBUG  [BuildStackInfoAdapter] insn H_PUTFIELD
2016-09-23 10:35:33,401 DEBUG  [BuildStackInfoAdapter] ldcInsn test123
2016-09-23 10:35:33,402 DEBUG  [BuildStackInfoAdapter] insn AASTORE
2016-09-23 10:35:33,402 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL my/workflow/test/SignupWorkflowImpl waitForAll ([Ljava/lang/String;)V
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] label L2030024264
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] varInsn: ALOAD 0
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] ldcInsn test123
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL my/workflow/test/SignupWorkflowImpl getAndRemoveResponse (Ljava/lang/String;)Lorg/copperengine/core/Response;
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] varInsn: ASTORE 1
2016-09-23 10:35:33,403 DEBUG  [BuildStackInfoAdapter] label L1545105159
2016-09-23 10:35:33,404 DEBUG  [BuildStackInfoAdapter] fieldInsn GETSTATIC 'java/lang/System' 'err' 'Ljava/io/PrintStream;'
2016-09-23 10:35:33,404 DEBUG  [BuildStackInfoAdapter] typeInsn: NEW java/lang/StringBuilder
2016-09-23 10:35:33,404 DEBUG  [BuildStackInfoAdapter] insn DUP
2016-09-23 10:35:33,404 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKESPECIAL java/lang/StringBuilder <init> ()V
2016-09-23 10:35:33,405 DEBUG  [BuildStackInfoAdapter] ldcInsn Got response  
2016-09-23 10:35:33,405 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL java/lang/StringBuilder append (Ljava/lang/String;)Ljava/lang/StringBuilder;
2016-09-23 10:35:33,405 DEBUG  [BuildStackInfoAdapter] varInsn: ALOAD 1
2016-09-23 10:35:33,405 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL java/lang/StringBuilder append (Ljava/lang/Object;)Ljava/lang/StringBuilder;
2016-09-23 10:35:33,406 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL java/lang/StringBuilder toString ()Ljava/lang/String;
2016-09-23 10:35:33,406 DEBUG  [BuildStackInfoAdapter] methodInsn INVOKEVIRTUAL java/io/PrintStream println (Ljava/lang/String;)V
2016-09-23 10:35:33,406 DEBUG  [BuildStackInfoAdapter] label L1210147789
2016-09-23 10:35:33,406 DEBUG  [BuildStackInfoAdapter] insn RETURN
2016-09-23 10:35:33,406 DEBUG  [BuildStackInfoAdapter] label L136268986
2016-09-23 10:35:33,424 INFO   [AbstractWorkflowRepository] CheckClassAdapter.verify succeeded for class my/workflow/test/SignupWorkflowImpl
2016-09-23 10:35:33,424 INFO   [AbstractWorkflowRepository] Creating classes
2016-09-23 10:35:33,425 INFO   [AbstractWorkflowRepository] my.workflow.test.SignupWorkflowImpl created
2016-09-23 10:35:33,434 INFO   [ClasspathWorkflowRepository] Startup finished
2016-09-23 10:35:33,434 INFO   [TimeoutManager] started
2016-09-23 10:35:33,434 INFO   [DefaultEarlyResponseContainer] started
2016-09-23 10:35:33,435 DEBUG  [TimeoutManager] Activated at: 1474641333434
2016-09-23 10:35:33,435 INFO   [PriorityProcessorPool] ProcessorPool T#DEFAULT: Starting up
2016-09-23 10:35:33,435 DEBUG  [TimeoutManager] There are currently no timeout slots - waiting indefinitely...
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,436 INFO   [TransientScottyEngine] Engine is running
2016-09-23 10:35:33,436 INFO   [Processor] started
2016-09-23 10:35:33,440 DEBUG  [Workflow] Creating new my.workflow.test.SignupWorkflowImpl
2016-09-23 10:35:33,441 INFO   [DefaultTicketPoolManager] Mapping workflow class 'my.workflow.test.SignupWorkflowImpl' to ticket pool DEFAULT
2016-09-23 10:35:33,441 DEBUG  [TicketPool] Trying to obtain 1 tickets. DEFAULT: 0 of 2000 tickets used
2016-09-23 10:35:33,441 DEBUG  [TicketPool] Obtained my tickets! DEFAULT: 1 of 2000 tickets used
2016-09-23 10:35:33,458 DEBUG  [TransientScottyEngine] registerCallbacks(Workflow [id=724acad8-6dbc-430a-91fa-e6ea83d84d70, priority=5, processorPoolId=T#DEFAULT], ALL, 0, [test123])
2016-09-23 10:35:43,456 DEBUG  [TransientScottyEngine] notify(Response [correlationId=test123, response=OLOLO, exception=null, timeout=false, metaData=null, internalProcessingTimeout=null, earlyResponseHandling=true, responseId=null, sequenceId=null])
2016-09-23 10:35:43,457 INFO   [TransientScottyEngine] Engine is shutting down...
2016-09-23 10:35:43,458 DEBUG  [TicketPool] Released 1 tickets! (Now DEFAULT: 0 of 2000 tickets used)
2016-09-23 10:35:43,458 INFO   [DefaultProcessorPoolManager] Shutting down...
2016-09-23 10:35:43,458 INFO   [TimeoutManager] stopped
2016-09-23 10:35:43,458 INFO   [PriorityProcessorPool] ProcessorPool T#DEFAULT: Shutting down
2016-09-23 10:35:43,458 INFO   [DefaultEarlyResponseContainer] stopped
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#0'...
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#1'...
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#2'...
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#3'...
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#4'...
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#5'...
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] stopped
2016-09-23 10:35:43,458 INFO   [Processor] Stopping processor 'T#DEFAULT#6'...
2016-09-23 10:35:43,459 INFO   [Processor] Stopping processor 'T#DEFAULT#7'...
2016-09-23 10:35:43,459 INFO   [Processor] stopped
2016-09-23 10:35:43,459 INFO   [Processor] stopped
2016-09-23 10:35:43,459 INFO   [TransientScottyEngine] Engine is stopped
Got response Response [correlationId=test123, response=OLOLO, exception=null, timeout=false, metaData=null, internalProcessingTimeout=null, earlyResponseHandling=true, responseId=null, sequenceId=14746413328180001]


Process finished with exit code 0

And I can see that the class is being modified. So looks like for now Scala could not be used as a language for workflow definitions.