Validate bpmn diagram?

Hi everyone,

I noticed that process diagrams after several modification get (often) corrupted and the only way I found to fix them is to build them again (from scratch) or modify the closest (if I have working copies).

What I don’t have understood is if the problem comes from the modeler or intelliJ (while merging branches for example…).

The modeler I was using is the eclipse based one which also allow to validate the diagram(right click on the file). It passes the validation apart for a few warning.

I just downloaded the last one which does not allow validation any longer.

More in detail:
the bpmn diagram is corrupted because it does not deploy on the process engine.
When I deploy my application the jboss deployment is successful but there is no referring record in ACT_RE_PROCDEF.
And obviously the cockpit does not see any process definition either.

Then I tried to deploy the closest version together with the “corrupted” one.
By doing so, I got both deployed with different version number which (at least for me) would have made sense if the “corrupted one” had deployed any case.

If possible, I would like to understand the reason of this behavior but overall I would like to know if there is a way for validating bpmn diagram in order to just fix the problem in the source.

Here is the the “corrupted” file:

Corrupted Process Diagram

Thanks in advance,



Not sure I understand the problem. The diagram you have posted works fine in Camunda Modeler (0.5.0; not the Eclipse plugin) and deploys successfully (Camunda 7.4.0). If processes do not deploy because they are not valid XML or valid according to the BPMN meta model, you should see an exception on the console.

Can you please give a concise, step-by-step description what is wrong in your case? Or alternatively, can you post the sources (e.g. on github) to a process application that I can deploy and that reproduces the problem?


Hi Thorben,

I actually agree with you.
If there were a problem with xml, I should see an exception in the server log which was not the case.
I’m guessing the problem is xml corruption because I already had similar issues in the past (message event not declared according to the console but present in .bpmn…) which I solved by taking obsolete (but “deployable” ) diagrams and adapting them. Basically I thought that mess is more difficult to detect in xml (at least for me) .

Anyway, for completeness, I use camunda 7.3.0.
Last Thursday I got a problem with my process definition and I opened a topic in this forum (Terminate End Event not killing the process).
I was finally able to solve it(thanks overall to the tip you gave me, meaning reproducing a test case of the error).

Then I updated the diagram with the solution and everything was going fine till the server went offline for external reason.
Starting from yesterday I haven’t been able to deploy the application again. The problem is not the server 100%.

I’m sure of this because I also tried to deploy an old diagram and it worked just fine.
This one do not unless I deploy at the same time an old version so I get both with a different version number.

All the time I deploy I clean the ACT_RE_PROCDEF table and I do that because, as requirement from business, I need just one version of the process.

Now, while waiting for a reply, I’ve been rebuilding the diagram (with the new modeler v0.5.1) and this time does not work for another reason:
it complains that service tasks should have either a ‘class’ or a ‘Delegete expression’…defined.

And this is the case as you can see:

but I get the error anyway.

In those cases I’ve always rebuilt the diagram cause I don’t know where eventually modify it.
And this is way I’m asking if I can validate the diagram somehow…

As per the source code, I can’t put it on Git…

I hope that was a bit clearer.

Hi Paolo,

Perhaps the problem is that you manually delete entries from ACT_RE_PROCDEF. By default, a shared process engine performs duplicate checking, i.e. it only redeploys process definition if it has changed. That check is performed based on entries in the ACT_RE_DEPLOYMENT and ACT_GE_BYTEARRAY tables. If you manually delete entries only from the ACT_RE_PROCDEF table, the duplicate check will still assume that the process definition is still deployed in the previous state and won’t redeploy it. Now, if you switch back to an older version and then redeploy, then the duplicate check works as expected.

So instead of manually removing entries from ACT_RE_PROCDEF which may give you an inconsistent database state, I strongly recommend using process engine API like RepositoryService#deleteDeployment to get rid of older process definition versions.

I hope that is indeed the cause of the problem and solves the issue for you.


Hi Thorben,

that was indeed the problem and the solution you proposed solved!!

I’ve been able to redeploy and thanks to a post on stackoverflow I also solved the issue related to service task not declaring implementation.

Camunda Example clarification

Thanks again,