“Orchestrating Work with Activiti and Spring Integration” by Josh Long

When my buddy Josh Long from Pivotal writes about Activiti and Spring, it’s always must-read material. No exception this time, so I do want to give it exposure here too:

Orchestrating Work With Activiti and Spring Integration

Nice conclusion too: “BPM adds a fair amount of cognitive load for simple integrations but offers a lot of value when business process descriptions must be model- and business analyst-friendly. One common misconception is that developers have to give up the ability to enhance the system once BPM is involved; NOT SO! Thanks to Spring Boot and some hard work from the Activiti team, Activiti works perfectly with all of Spring.”

 

Edit 11 Feb 2016: as promised in the comments below, forked the example and made it running on v6: https://github.com/jbarrez/activiti-examples

5 Comments

  1. Anonymous February 10, 2016

    the example does not seem to work with activit6: the example assumes that the processInstance id is the same as the execution id ( which seems to be true in activiti5 but not the case with 6 right?

  2. Joram Barrez February 10, 2016

    That’s true.

    In v6, signal() has been replaced by trigger() (as it was confusing for many people with the BPMN signal concept). So the reply flow should be something like

    .handle(msg -> engine.getRuntimeService().trigger(
    String.class.cast(msg.getHeaders().get(“executionId”))))

  3. Anonymous February 10, 2016

    yes but the „executionid „is misleading here : Collections.singletonMap(„executionId“, asyncProcess.getId()) is actually the processInstance id. triggering that would cause an exception in activit6 as it is not the „actual“ waiting execution id (?) this is a bit confusing when upgrading …

    engine.getRuntimeService().signal() does not do the same as trigger in that case

  4. Joram Barrez February 10, 2016

    trigger() does do the same as signal(): continue the execution from the point where the executionId currently is, but in v5 in this case the processInstanceId is also used for visiting the the process activity. In v6, the process instance execution is always a scope, and is never used for visiting a process activity.

    To fix it:

    return Collections.singletonMap(“executionId”, asyncProcess.getId());

    should indeed be

    String executionId = runtimeService.createExecutionQuery().activityId(“sigw”).singleResult();
    return Collections.singletonMap(“executionId”, executionId);

    I’ll try form Josh’s repo and make it v6 compliant.

  5. Joram Barrez February 11, 2016

    Update: see the edit above for the v6 version of this example.

Leave a Reply

Your email address will not be published. Required fields are marked *