Clean up some ACT_GE_BYTEARRAY instances

[tim_whitworth]

We've been storing a copy of the main entity for our operations in a workflow variable, which has resulted in a buildup of data in the ACT_GE_BYTEARRAY as hist.var-entity, along with hist.var-child_entity and hist.var-workflowDefinition.

What should I do to make it safe to delete these? The rest of the historical data is still needed for reporting purposes, so we can't just delete the historical tasks from java.

If we just delete the entries, we lose the ability to complete tasks with a nullpointer exception. If we delete the ACT_HI_VARINST entries pointing to them, we don't see any error, but it's not clear that no complication will emerge later.

Is there any means of clearing up just those entries? Or configuring the history system to ignore them?

We've recently upgraded to activiti 6.0.0, used with spring 4.2.5.

[afaust]

I would say deleting any data from an active process is inherently unsafe. I would restrict your deletions to variables / byte arrays from processes that have already terminated. And you should only delete byte arrays referenced from actual variables - workflow definitions / deployments and such should only be deleted by using the Activiti APIs for "undeploying" them.

What I always recommend my customers to consider is that any historical data that may be relevant for reporting be exported in some sorts, so the process engine tables can be cleared out frequently. For a few customer processes, this was done by simply generating a report PDF as the last service task in the process, and filing that to Alfresco (in the embedded Activiti use case) or on an archive system. Alternatively, the data might be exported to a different database / schema which would be more suitable for reporting / BI views than the BPM engine schema. Once exported, the entire process and its associated data can be deleted after completion.

[cjose]

Also, going forward, transient variables (Activiti User Guide - Transient Variables) introduced in Activiti V6 might be a good candidate for your use case.