Avoid history table explosion for long-running cyclic processes?

Question

I have a process which has a conditional loop iterating each 1 minute. The process itself can run for weeks, but I expect 99% of it's the history to be a repeating entries reflecting invocation of executions which are the part of the said cycle. Example:

|15:34:30.167|15:34:30.238|TimerCatchEvent|
|15:34:30.258|15:34:30.323|CheckConditionServiceTask|
|15:34:30.371|15:34:30.410|ExclusiveGateway1|
|15:34:30.457|15:34:30.501|ReturningtoTimerEventServiceTask|
|15:35:30.167|15:35:30.238|TimerCatchEvent|
|15:35:30.258|15:35:30.323|CheckConditionServiceTask|
|15:35:30.371|15:35:30.410|ExclusiveGateway1|
|15:35:30.457|15:35:30.501|ReturningtoTimerEventServiceTask|
|15:36:30.167|15:36:30.238|TimerCatchEvent|
|15:36:30.258|15:36:30.323|CheckConditionServiceTask|
|15:36:30.371|15:36:30.410|ExclusiveGateway1|
|15:36:30.457|15:36:30.501|ReturningtoTimerEventServiceTask|

Is there any way to somehow collapse these repeating history entries on the camunda level? Or maybe someone had come up with other solutions to this problem?

P.S. This is a follow-up for the question on cross-process synchronization: Cross-process synchronization in Camunda? - I have implemented what I need using post-fact timer-based "are all ready to sync?"-check.

Answer 1

You could also delete history entries from the database using some clean-up-script. It is safe to delete information from the history - it will not affect the runtime behavior.

Cheers Bernd

Answer 2

In Camunda the History is Event Driven. It is possible to

1. implement a custom HistoryLevel controlling the amount of events produced and the data they contain,
2. implement a custom History Backend which allows you to logg the events in a different way than the default handler does.

Maybe that is useful to you?