Could Zeebe ignore extension tags from other vendors?

We want to create model using BPMN 2.0 in another modeler. The other modeler (e.g., Signavio) adds extension tags to XML it exports. When trying to deploy this XML to Zeebe, we get error that extension tags from other vendor are not recognized.

Couldn’t (shouldn’t) Zeebe just ignore those other vendor extension tags?

1 Like

I think in general it makes sense to me, but be aware that Zeebe also needs several extension elements to execute your model. It will also fail if these are not available, e.g. for service task.

Feel free to open an issue here Issues · camunda/zeebe · GitHub

Greets
Chris

Hi @mcarleb,

could you please upload a process model that gets rejected? I would like to have a look on it.

Cheers, Ingo

In some ways, throwing an error makes sense.
If your BPMN contains both extension:camunda and extension:signavio tags, warning the user that the system doesn’t understand what to do with the other tags is clearer about what to expect than just silently ignoring them.

Perhaps maybe an option box (default false) on the deploy form would make sense.

‘sprint3-process-bpmn-SIGTAGS.bpmn’ contains tags from Signavio (where model was created). I can import this file into C8 modeler, but I cannot deploy.

‘sprint3-process-bpmn-SIGTAGS_C8.bpmn’ has been processed by me to extract the Signavio tags. I can import this file into c8 modeler, AND I can deploy and execute.

Thank you for attention,
Mark

sprint3-process-bpmn-SIGTAGS_C8.bpmn (16.2 KB)
sprint3-process-bpmn-SIGTAGS.bpmn (18.4 KB)

You can save this script to a file and it should strip out most of the stuff from other modelers that Camunda Platform 8 doesn’t like:

#! /bin/sh

fl=Cloud-${1}
cp $1 $fl
xmlstarlet edit --inplace --ps \
    -N bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" \
    -N triso="http://www.trisotech.com/2015/triso/modeling" \
    -N openapi="https://openapis.org/omg/extension/1.0" \
    -N boc="http://www.boc-group.com" \
    -N kp="http://knowprocess.com/bpmn" \
    --delete "//triso:*" \
    --delete "//openapi:*" \
	--delete "//boc:*" \
	--delete "//kp:*" \
    --delete "//bpmn:ioSpecification" \
    --delete "//bpmn:dataInputAssociation" \
    --delete "//bpmn:dataOutputAssociation" \
    --delete "//bpmn:dataObject" \
    --delete "//bpmn:dataObjectReference" \
    --delete '//bpmn:message[not(//bpmn:messageEventDefinition/@messageRef=@id)]' \
    --delete '//bpmn:extensionElements[not(*)]' \
	--delete "//bpmn:operation" \
	--delete "//bpmn:interface" \
    $fl

You will still have to make sure that the XML headers are right.

Look for modeler:executionPlatform="Camunda Platform" modeler:executionPlatformVersion="7.15.0" and change it to modeler:executionPlatform="Camunda Cloud" modeler:executionPlatformVersion="1.1.0" which should workk.

HTH,
dg

Hi @mcarleb,

The Signavio process looks like a valid BPMN process from the XML side.

It didn’t use the bpmn namespace for the bpmn elements. As the modeler could open and save it, it is valid BPMN.

I also found that your model is not executable. But even after making the process executable, I could not deploy it. In my test console output I found this stacktrace:

10:51:23.439 [-zb-actors-5] ERROR io.camunda.zeebe.broker.process - Unexpected error while processing resource 'sprint3-process-bpmn-SIGTAGS.bpmn'
java.lang.RuntimeException: Unable to process unknown element with name signavioMetaData
	at io.camunda.zeebe.model.bpmn.traversal.ModelWalker.lambda$walk$0(ModelWalker.java:69)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at io.camunda.zeebe.model.bpmn.traversal.ModelWalker.walk(ModelWalker.java:63)
	at io.camunda.zeebe.engine.processing.deployment.transform.BpmnValidator.validate(BpmnValidator.java:40)
	at io.camunda.zeebe.engine.processing.deployment.transform.BpmnResourceTransformer.transformResource(BpmnResourceTransformer.java:65)
	at io.camunda.zeebe.engine.processing.deployment.transform.DeploymentTransformer.transformResource(DeploymentTransformer.java:120)
	at io.camunda.zeebe.engine.processing.deployment.transform.DeploymentTransformer.transform(DeploymentTransformer.java:97)
	at io.camunda.zeebe.engine.processing.deployment.DeploymentCreateProcessor.processRecord(DeploymentCreateProcessor.java:100)
	at io.camunda.zeebe.engine.processing.streamprocessor.TypedRecordProcessor.processRecord(TypedRecordProcessor.java:54)
	at io.camunda.zeebe.engine.processing.streamprocessor.ProcessingStateMachine.lambda$processInTransaction$3(ProcessingStateMachine.java:300)
	at io.camunda.zeebe.process.test.engine.db.InMemoryDbTransaction.run(InMemoryDbTransaction.java:47)
	at io.camunda.zeebe.engine.processing.streamprocessor.ProcessingStateMachine.processInTransaction(ProcessingStateMachine.java:290)
	at io.camunda.zeebe.engine.processing.streamprocessor.ProcessingStateMachine.processCommand(ProcessingStateMachine.java:253)
	at io.camunda.zeebe.engine.processing.streamprocessor.ProcessingStateMachine.tryToReadNextRecord(ProcessingStateMachine.java:213)
	at io.camunda.zeebe.engine.processing.streamprocessor.ProcessingStateMachine.readNextRecord(ProcessingStateMachine.java:189)
	at io.camunda.zeebe.util.sched.ActorJob.invoke(ActorJob.java:79)
	at io.camunda.zeebe.util.sched.ActorJob.execute(ActorJob.java:44)
	at io.camunda.zeebe.util.sched.ActorTask.execute(ActorTask.java:122)
	at io.camunda.zeebe.util.sched.ActorThread.executeCurrentTask(ActorThread.java:97)
	at io.camunda.zeebe.util.sched.ActorThread.doWork(ActorThread.java:80)
	at io.camunda.zeebe.util.sched.ActorThread.run(ActorThread.java:189)
Caused by: java.lang.ClassCastException: class org.camunda.bpm.model.xml.impl.instance.ModelElementInstanceImpl cannot be cast to class io.camunda.zeebe.model.bpmn.instance.BpmnModelElementInstance (org.camunda.bpm.model.xml.impl.instance.ModelElementInstanceImpl and io.camunda.zeebe.model.bpmn.instance.BpmnModelElementInstance are in unnamed module of loader 'app')
	at io.camunda.zeebe.model.bpmn.traversal.ModelWalker.lambda$walk$0(ModelWalker.java:66)
	... 20 common frames omitted

Maybe the parser ignores the signavio: namespace and tries to apply the signavioMetaData as a common XML element.

But as Camunda promotes the Business IT Collaboration, this process should be deployed without changes.

I will add your process as an example in a Github issue as @Zelldon proposed.

Cheers, Ingo

Issue created: Deploy Signavio exported BPMN diagrams · Issue #9424 · camunda/zeebe · GitHub

Thanks, Ingo. Two things: (1) are you saying I can hope that Zeebe will at some point ignore the Siganvio extension tags such that the BPMN from Signavio should be deployable from Signavio without my removing? (2). I am able to deploy and run the XML from Signvaio–if I strip from the XML the elements tagged as Signavio extension. If you want me to share all files required to deploy, I will send those with screen shots and more explanation of how I do it.

PS: when I say I can deploy/run XML from Signavio after stripping Signavio extensions, I mean that I also have to add to XML (via C8 modeler) for Zeebe elements/attributes that are naturally not in Siganvio (e.g., specification of the user form, “types” for service task that are used to assign service tasks to external workers, etc.). Until BPMN 2.0 includes standards for deployment/execution, the need to add these elements/attributes in C8 modeler seems necessary and understandable.

Hi @mcarleb,

BPMN 2.0 is vendor independent, which is an important feature of this standard. It has certain extension points that different vendors should use for their extensions.

In the past Signavio processes played very well with the Camunda Platform Version 7, roundtrip from business analyst to process developer and back was possible with Camunda Cycle.

In general all tools should just ignore extension points they don’t know, as they have a namespace where they don’t care about.

I can reproduce the error even if I open a Zeebe process with an old version of the Camunda Modeler (4.0.0) and add an input mapping to a service task:

    <bpmn:serviceTask id="Activity_14cv33y" name="Do service 1">
      <bpmn:extensionElements>
        <zeebe:taskDefinition type="taskType1" />
        <camunda:inputOutput>
          <camunda:inputParameter name="a">b</camunda:inputParameter>
        </camunda:inputOutput>
      </bpmn:extensionElements>
      <bpmn:incoming>Flow_0s9i287</bpmn:incoming>
      <bpmn:outgoing>Flow_1smvm9w</bpmn:outgoing>
    </bpmn:serviceTask>

I get the same message during deployment:

io.camunda.zeebe.client.api.command.ClientStatusException: Command 'CREATE' rejected with code 'INVALID_ARGUMENT': Expected to deploy new resources, but encountered the following errors:
'synchronousExample.bpmn': Unable to process unknown element with name inputOutput

Thank you for offering additional files. But as I can reproduce it with our own tools, we should be able to fix it.

Removing the other extensions is a shortterm workaround.

Cheers, Ingo

I think we did the same thing in Camunda 7: Ignoring namespaces we are not aware of. In my understanding, this is also what the specification envisions, as various tools could add proprietary extensions that are only meaningful to them (e.g. BPMN in color, Signavio stuff, or whatever).

It could also ease a first step in migration, as it would allow to keep some Camunda 7 extension attributes in the model which are simply ignored (meaning you can do a more step-by-step approach to replace C7 with C8 extensions).

Created: BPMN Parsing should ignore third-party namespaces · Issue #9438 · camunda/zeebe · GitHub