first cut of the new history

[tom.baeyens]

HistoryEvents are fired during process execution.

We maintain history information on 2 levels: process instance and activity instance.

Process instance start and process instance end generate history events are fired directly from within the implementation.

ActivityBehaviour implementations are responsible for calling the historyXxx methods that are exposed on the ActivityExecution

All the HistoryEvents are delegated to a HistorySession. The default HistorySessionImpl will invoke the process() method on the history events themselves.

The HistoryEvents are temporary events. In the process method, they build up the information in the history model. There is a HistoryProcessInstance and there is a whole class hierarchy starting with HistoryActivityInstance.

In the HistoryEvent.process methods, the history events create model entities or merge information into the model entities. For instance, a ProcessInstanceStart history event will create a HistoryProcessInstance entity/record. And the ProcessInstanceEnd will set the endTime property in the existing HistoryProcessInstance entity/record.

Similar pattern for the activities. But for automatic activities, there is an optimisation so that only 1 event is created and all the information is stored in one single insert (as all this happens inside 1 transaction).

[camunda]

Hi Tom.

Sorry, I didn't completly get it. Could you maybe start with the bigger picture first bevore going into the details? I didn't catched the idea yet.

Of should I maybe read a bit of code if its already checked in?

Thanks
Bernd

[tom.baeyens]

the bigger picture is this:

in jbpm 3 we have a flat log table.

biggest problem with that is that it contains references to the runtime data (tokens and process instances). because of that reason, the runtime data cannot be deleted and it keeps growing.

now in jbpm 4, we'll have a history schema that does not reference the runtime data (it can reference process definition data as that data remains in the db). as a result, now process instance data is deleted once it is no longer needed. e.g. executions and variables get deleted when they go out of scope. and the full process instance is deleted when it ends.

the runtime data tables stay clean and healthy this way. the reporting and other monitoring is done on a separate set of tables. so this also makes the whole system more performant.

so in jbpm 4 we will not have a flat log file, but a fully fledged schema that contains the history information of what happened when in the process executions.

so an extra advantage is that the history schema is designed to be easy queryable. it can contain some de-normalized duplications of information. (e.g. startTime, endTime and duration fields).

internally, the architecture remains almost the same: runtime execution still generates history events (previously called processlogs). there is a pluggable history session that captures these history events. and the rest is described above.

does this help ?

[jbarrez]

Tom,

Thanks for the clarification. This is a great modification compared to jbpm 3!

This allows to keep the runtime structures nice and tidy and the queries fast :-)

[tom.baeyens]

btw, i started wednesday evening and i just finished the first results of that work:

* process instances and activity instances are now recorded

* avg duration per nodes part of the api

* for choice activities like decision, state and tasks, the distribution of how many times each transition is selected can be queried with one api method

queries based on task assignee will also be possible. any good ideas ?

[camunda]

Okay, now I got it. This is indeed a very good improvement! I will try to have a look at the code asap (but cannot yet promise that I will have time :-/)...