In our use case our data expires over night and we have to start fresh every day morning, in such cases what is the best way of deleting all process instances (running & completed)/user tasks/comments/claims/etc (but NOT users/groups or permissions)
I understand there is an option to drop the database and let spring boot recreate the database, configure users & deploy processes on startup, But it’s not quite elegant and where possible we want to avoid application restarts. Any thoughts.
Im not a big fan of removing history as I typically work in environments where an audit trail is necessary…
However, for your use case, could you set history level to none so you don’t need to care about history and put an interrupting timer on your entire process scope such that if its not complete by say 6:00am, the process terminates?..
There is a delete API in the rest API docs, so I guess you could use the APIs to delete data. This has the advantage of being supported and more stable than the script method below.
Another alternate is to use DB scripts to truncate the runtime tables, however this requires intimate knowledge of the DB schema and is subject to change…
I up this topic because I’m seeking a way to delete all my instances without losing any definition of process or decision.
My server starts to lag seriously with all this stuff running. Can I achieve this from PHP with the Rest API ? Thanks
Since you ask… I also experienced similar annoyance.
I wrote a couple of utilities to help solve this problem - both available as custom JAX-RS services. source at GitHub
Please note: source-code is evolving… With sufficient demand I will later tag a stable release. Ideally add it into Camunda’s shared base?
This removes deployments from Camunda’s “process” and “case” instance storage. This does not tell, for example, ask JBoss/Wildfly to “undeploy” the WAR. This does however clean up all the model versions you may see piling up during server start/restart. After running this service, I typically re-execute a hot-deployment. Not because I un-deployed the WAR, but because a full re-deployment tells Camunda “here’s a new process model - start here” - basically triggers, w/o restart, the BPM-engine to recognize the deployment (same behavior provided in admin console).
@GET
@Path("deletealldeployments")
@Produces(MediaType.APPLICATION_JSON)
public JsonNode deleteAllDeployments() {
This cleans up both active and history for case instances
I created this primarily to help avoid confusion while I was cycling insances per process-varialbe setup/configs and java-code cycles.
@GET
@Path("cleanupcaseinstances")
@Produces(MediaType.APPLICATION_JSON)
public JsonNode cleanUpCaseInstances() {
When the process is running for substantial amount of time, the history tables get big. Not sure about the runtime tables though. Are they get bigger as well? Then should we have some routine to purge all such data?
for deployment_id in $(echo ${deployment_list_json} | jq -r ‘..id’); do
curl -sX DELETE ${CAMUNDA_API_PATH}“deployment/”${deployment_id}“?cascade=true”
if [[ $(echo $?) -eq 0 ]]
then
echo “Deployment with id: “$deployment_id” and its instances were successfully deleted”
else
echo “Deployment with id: “$deployment_id” and its instances failed to be deleted”
fi
done