Custom history backend

[eaenes...@gmail.com]

Hi,

Is there an example code for the custom history backend thing?

[eaenes...@gmail.com]

What i really want to do is to build a real time application.
I thought i can accomplish that by listening the history events and then using JMS or socket.io sth. like that.

How does that sound?

[webcyberrob]

Hi,

Could you clarify what you mean by a real time system?

Do you mean you really want event driven processes? If thats the case, Ive had some success in translating event driven finite state machines into BPMN process models. You need to be familiar with nested sub-processes, event driven sub-processes, interrupting boundary events etc.

If you want to react in real-time to process changes, then I would look at the listeners (eg TaskListners, execution listeners etc).

I would leave history as history, its a log/audit of what has occured, I would not be keen to trigger behaviour based on this feed.

regards

Rob

[eaenes...@gmail.com]

Real time process changes.
But I dont want to do it with the listeners because I have to add listeners to every task,event,etc...
The user guide says about the custom history backend:

"If you do not want to replace the default behavior but only provide an additional event handler, you need to write a composite History Event Handler which dispatches events a collection of handlers"

[webcyberrob]

Hi,

Ive not used this myself, but global listeners may be of interest...

http://docs.camunda.org/latest/guides/user-guide/#process-applications-process-application-event-listeners

regards

Rob

[thorben....@camunda.com]

Hi,

You can implement the interface org.camunda.bpm.engine.impl.history.handler.HistoryEventHandler and replace the default history event handler in the process engine configuration (or make a composite one as the docs suggest). I haven't found a focused, well-documented example for this, but you could have at [1] and specifically the classes FilterVariableHistoryPlugin and FilterVariableHistoryEventHandler.

Cheers,
Thorben

[1] https://github.com/camunda/camunda-consulting/tree/master/snippets/change-history-output/src/main/java/com/camunda/consulting/history/changeHistoryOutput

[eaenes...@gmail.com]

This could work too:

https://github.com/camunda/camunda-consulting/tree/master/snippets/task-name-beautifier#adding-the-task-listener-to-all-user-tasks-of-all-processes

[eaenes...@gmail.com]

Hi Thorben,

I tried both ways(global event listeners, custom history backend) but unfortunately I couldn't get what I want.Here is what I do:

Plan A: I implemented a global listener.It works fine when a new task is created or a user is assigned to a task.But it doesn't throw an event when a group is linked to the task or the due date changed.

Plan B: I implemented a custom history event handler which implements org.camunda.bpm.engine.impl.history.handler.HistoryEventHandler.I get the events but it is acting weird.For example when I link a group to a task, I get event type (org.camunda.bpm.engine.impl.history.event.HistoryEvent.getEventType()) = null.Another example when I update a task(i.e.due date) I get two events,the type of the first one is null and the second one is "update".And also how am I supposed to get task details.

What am I doing wrong?

Regards

[thorben....@camunda.com]

Hi,

Your observation of plan A is correct and shows the limitations of task listeners for this purpose. That's why the other option should be preferred in my opinion.

Could you share a test case for the behavior you observed when implementing plan B? That the event type is not populated appears to be a bug but it is important to know for which events this happens. You may use the camunda unit testing template [1].

Thanks,
Thorben

[1] https://github.com/camunda/camunda-engine-unittest

[eaenes...@gmail.com]

Hi Thorben,

https://github.com/enesaltinok/camunda-history-unittest

It seems event type is null only when the history event class is an instance of UserOperationLogEntryEventEntity.


Regards

[thorben....@camunda.com]

Hi,

Thanks for creating the test case. I can confirm this is a bug and created a ticket, see [1]. You might want to add yourself as a watcher and vote for it.

As a workaround, you can check the type of the history event before you rely on the event type.

Best regards,
Thorben

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