about the order with which sequentially modeled activities have been passed

[Martin Schimak]

Hey all,

I am working on camunda-bpm-assert and I am trying to implement a 'hasPassedInOrder' assertion for activity instances of a running and/or historic process instance. My goal is to check whether sequentially modeled activities have been passed in the expected order.

I want this because it's is a very important concept when checking for unchanged "activity flow semantics" after having refactored a process definition.

My first - and too naive - approach was to use historicActivityInstanceQuery.finished().orderByHistoricActivityInstanceEndTime().asc() to sort the activities of a process instance in the order they finished. But this fails arbitrarily the moment several sequentially modeled activity instances complete within the same millisecond.

Hence my question: is there a safe way to ask (the historic activity instances table or some other information?) for the order with which sequentially modeled activities have been passed?

Many thx,

Martin.

[thorben....@camunda.com]

Hi Martin,

There is no way of resolving this from the historic entities the engine currently offers. I can think of two ways to do this:

1. You add an execution listener that logs activity invocations to some kind of data structure your test library has access to. You could use a parse listener to add it to every task. However, this changes the process model which is the unit under test, so I do not think this is a very good solution.
2. You write a custom history event handler (see the interface HistoryEventHandler in the engine) in which you log the order of historic activities in a custom data structure. This handler has to be registered with the process engine configuration. At the moment, we do not provide a composite event handler implementation (which is a useful addition though, I just created a ticket, see [1]), so you would have to build something like that in order to not disable the default history handler. Compared to 1, this approach is less invasive.

I think, the two approaches work fine for a single sequence of activities. If you should go with approach 2 and build a composite history event handler, we are happy to receive a pull request ;)

Depending on how this feature should work, this approach may fall short in cases with two parallel branches where each has two sequential activities. Let's assume that branch 1 has tasks TaskA1 -> TaskB1 and branch 2 has TaskA2 -> TaskB2. Depending on how async-attributes are attached to those tasks, you could see any interleaved order of the two task traces. To resolve this, we would require a reference to the previously executed activity id in the historic activity events.

I hope this helps you with implementing this feature.

Best regards,
Thorben

[1] https://app.camunda.com/jira/browse/CAM-2716

[Bernd Rücker (camunda)]

Hi Martin.

 

Depending on the ID-Generator used the ID’s should be orderable (is this an English word?). The timed UUID’s should be usable in an order by clause – even if the timestamps are the same because the engine is too fast. But this relies on the ID Generator.

 

Cheers

Bernd

--
You received this message because you are subscribed to the Google Groups "camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/26dedcbc-6972-4987-872e-86f7a7e70624%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Meyer]

Hi Bernd,

> Depending on the ID-Generator used the ID’s should be orderable (is this an English word?). The timed UUID’s should be usable in an order by clause – even if the timestamps are the same because the engine is too fast. But this relies on the ID Generator.

this is not true for the StrongUuidGenerator we ship with camunda BPM.

Daniel

[Daniel Meyer]

> this is not true for the StrongUuidGenerator we ship with camunda BPM.

Hold on, I am not sure :) The last time we checked we thought they were not increaing but maybe we were wrong

Daniel

[Bernd Rücker (camunda)]

I thought this is why we used a timed Strong UUID Generator? Actually something we should check and document (apidoc sufficient I think) – as this is really important – otherwise we do not have any possibility to really know the order of activities if they happened in the same milli – that would be not so good actually ;-)

--

You received this message because you are subscribed to the Google Groups "camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/fad03d0d-7a36-4bfc-a5a4-417e6122357a%40googlegroups.com.

[Daniel Meyer]

Hi Bernd,

At the time, the motivation for using the UUID Generator was so solve deadlock issues with the database-based generator

https://jira.codehaus.org/browse/ACT-789

Daniel

[Martin Schimak]

Hi all,

Many thx for your suggestions. As I do not want the user of camunda-bpm-assert to have to register a custom history event handler, I am inclined to just implement it for DbIdGenerator and TestIdGenerator and throw some Unsupported exception for other cases.

Do I see it correctly that DbIdGenerator still is (and remains?) the default? 

Martin.

--

You received this message because you are subscribed to the Google Groups "camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/dd4ee7b6-c15f-4a44-998a-cd44fbf75a13%40googlegroups.com.

[Martin Schimak]

This gives me a green bar after some seconds:

    IdGenerator generator = new StrongUuidGenerator();

    String lastId = "";

    for (int i=0; i<10000000; i++) {

      assertThat(generator.getNextId().compareTo(lastId)).isGreaterThan(0);

    }

[Bernd Rücker (camunda)]

That backs what I had in mind :-)

 

Thanks for verifying it!

To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/6161D441F5664236A5EDFCC6FAF4D0E0%40plexiti.com.

[Martin Schimak]

Actually it doesn't back what you had in mind :-), because I "beautified" the code after having pasted it into my mail - and messed it up. :-)

But what I really tested backs what you had in mind:

    IdGenerator generator = new StrongUuidGenerator();

    String lastId = "";

    for (int i=0; i<10000000; i++) {

      String nextId = generator.getNextId();

      Assertions.assertThat(nextId.compareTo(lastId)).isGreaterThan(0);

      lastId = nextId;

    }

Many greetings

Martin.

To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/4a609575.00001db8.00000013%40ca-ruecker.

[Martin Schimak]

Just to close that thread and to say thank you: I implemented that 'hasPassedInOrder' assertion feature now and tested it successfully with DbIdGenerator as well as StrongUuidGenerator. I tested in particular also for the "millisecond problem" causing that post.

As it is enough for me to sort the HistoryActivityInstances of one particle process instance, I do not rely on database sort anymore, but instead implemented a Comparator for in memory sorting which sorts the suffix part of a HistoryActivityInstance id numerically and just if that is not possible falls back to sort alphanumerically. 

https://github.com/camunda/camunda-bpm-assert/blob/master/camunda-bpm-assert/src/main/java/org/camunda/bpm/engine/test/util/HistoricActivityInstanceComparator.java

Many greetings,

Martin.  

[Bernd Rücker (camunda)]

I interpolated that in my head :-)
von unterwegs gesendet / sent with a mobile device

Martin Schimak <martin....@plexiti.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/camunda-bpm-users/1A0F25D70F4F4D69A84B1FC277A6EF23%40plexiti.com.