Unable to deploy model from Modeler, "SAXException while parsing input stream"

Hello, we’re BPMN newbies, doing a quick spike to figure out if we want to go further down the BPMN road generally, and with Camunda specifically. We are attempting to kick tires on BPMN and Camunda using the SaaS cloud trial.

The Camunda Modeler has been great, but we’re having trouble with deployment.

We are able to deploy the sample models fine, but the first process we tried to model will not deploy. Here is the BPMN file:
fac-create-new-submission-v2-copy.bpmn (24.6 KB)

The error message presented in the Modeler’s Output tab is not at all helpful:

Command ‘CREATE’ rejected with code ‘INVALID_ARGUMENT’: Expected to deploy new resources, but encountered the following errors:
‘FAC_create_new_submission_V2 - Copy.bpmn’: SAXException while parsing input stream[ deploy-error ] 30/11/2022 10:1:55

Note that the Modeler says it is checking problems against Zeebe 8.1, which is the same version as the cluster that was automatically deployed. We expected to get more detailed information here, similar to what is shown in the docs.

I found my way to bpmnlint and tried running it on the file… Here’s the output:

$ bpmnlint fac-create-new-submission-v2-copy.bpmn 

/mnt/c/Users/bmogi/Downloads/fac-create-new-submission-v2-copy.bpmn
  BPMNPlane_1             error    Import warning: unknown attribute <background-color>           
  BPMNPlane_1             error    Import warning: unknown attribute <border-color>               
  Flow_1sbnb0f_di         error    Import warning: unknown attribute <background-color>           
  Flow_0hlyo0l_di         error    Import warning: unknown attribute <background-color>           
  Flow_1ka8s3e_di         error    Import warning: unknown attribute <background-color>           
  Flow_1mwos5d_di         error    Import warning: unknown attribute <background-color>           
  Flow_1ntdyro_di         error    Import warning: unknown attribute <background-color>           
  Flow_0cv8fu3_di         error    Import warning: unknown attribute <background-color>           
  Flow_1nq5xpj_di         error    Import warning: unknown attribute <background-color>           
  Flow_1qpix0o_di         error    Import warning: unknown attribute <background-color>           
  Flow_1gcdogm_di         error    Import warning: unknown attribute <background-color>           
  Association_1rcv59h_di  error    Import warning: unknown attribute <background-color>           
  Activity_1x0ki8y        warning  Incoming flows do not join                            fake-join
  Activity_0ibrt0q        warning  Incoming flows do not join                            fake-join
  Activity_0einu9l        warning  Incoming flows do not join                            fake-join

✖ 15 problems (12 errors, 3 warnings)

Note some of the problems found are listed as type error even though the rest of the line says that they’re warnings. :thinking: Also, as far as we know we’re not explicitly setting a background-color anywhere; those attributes may have been added by Modeler implicitly.

Since the file was created in Camunda Modeler we would expect these same messages to appear somewhere in Modeler, but they don’t. Even so, these warnings are all… well, warnings! So we hope they’re not the source of the error message we see on deploy.

Anyone see what the problem might be?

I tried removing elements from the model one by one in Modeler until I was down to this point, and it still doesn’t deploy properly. The error message is the same.

File attached:
test.bpmn (3.2 KB)

Starting from the “API Orchestration Tutorial” template, I deleted the “Rest Connector” task to make a similarly simple model, and I was able to deploy it. I downloaded it and ran bpmlint on both that file and our reduced test model:

$ bpmnlint api-orchestration-tutorial.bpmn 
[no output]

$ bpmnlint test.bpmn 
/mnt/c/Users/bmogi/Downloads/test.bpmn
  BPMNPlane_1  error  Import warning: unknown attribute <background-color>  
  BPMNPlane_1  error  Import warning: unknown attribute <border-color>      

✖ 2 problems (2 errors, 0 warnings)

OK, so, maybe those warnings really are errors?! I went into the test file and deleted the background-color and border-color attributes everywhere that they appeared, then uploaded the test file… and it deployed fine!

Next step: I removed those attributes from our complete model, leaving this output from bpmnlint:

$ bpmnlint test.bpmn 
/mnt/c/Users/bmogi/Downloads/test.bpmn
  Activity_1x0ki8y  warning  Incoming flows do not join  fake-join
  Activity_0ibrt0q  warning  Incoming flows do not join  fake-join
  Activity_0einu9l  warning  Incoming flows do not join  fake-join

I uploaded that version and it did not deploy properly. However, now the error in the Output pane has changed, and says only:

[ deploy-error ] 30/11/2022 22:52:9

OK, so maybe I need to fix those fake-join warnings…? I took a look at the bpmnlint rule for fake-join and it’s pretty clear about what needed to be fixed. So I fixed those fake-join warnings by making this updated version of the file:
test-with-fixed-fake-joins.bpmn (25.9 KB)

I thought for sure that this was the last obstacle, but unfortunately that’s not the case. The Deploy Diagram button yields the same Output:

[ deploy-error ] 30/11/2022 23:8:10

So, the mystery remains! Here is the standing list of questions:

  1. Why doesn’t this deploy, even with the lint findings addressed?
  2. Where did the background-color and border-color attributes come from in the first place? As I mentioned above:

    Also, as far as we know we’re not explicitly setting a background-color anywhere; those attributes may have been added by Modeler implicitly.

  3. Why doesn’t Modeler give us a useful error message, similar to what bpmnlint gave us, either in the Problems tab pre-deploy, or in the Output tab post-deploy?
  4. Should these be reported as bugs somewhere?

I tried reducing our sample down again, to just this:

reduced-test-with-fixed-fake-joins.bpmn (6.8 KB)

If I try to deploy as-is, I get the mysterious output:

[ deploy-error ] 30/11/2022 23:27:12

If I delete any individual task, I get a verbose message in the Output about input/output mapping. For example, if I delete the first:

Command 'CREATE' rejected with code 'INVALID_ARGUMENT': Expected to deploy new resources, but encountered the following errors:
'test-with-fixed-fake-joins.bpmn': - Element: Activity_1whexer > extensionElements > ioMapping > output
    - ERROR: failed to parse expression 'f"{year}{trichar}{str(count).zfill(10)}"': Expected (binaryComparison | between | instanceOf | in | "and" | "or" | end-of-input):1:2, found "\"{year}{tr"
- Element: Activity_0ibrt0q > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_0ibrt0q > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_0ibrt0q > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_1whexer > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_0ibrt0q > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_1whexer > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_0ibrt0q > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
- Element: Activity_1whexer > extensionElements > ioMapping > output
    - ERROR: Expected expression but not found.
[ deploy-error ] 30/11/2022 23:28:29

However, if I delete all three tasks, then it deploys fine.

I am so baffled. Help!

You need to set the input/outputs correctly.

Thanks! My next step was to delete the inputs and outputs, and it did indeed deploy. We will inspect how those were set next.

Is there some way we could have known about that based on Modeler? There is still no indication of any particular problem.

You can check the docs.

Hello @mogul ,

the first problem was because the attribute background-color was not set in the correct namespace. In fact, it had no own namespace so the namespace of the element (bpmndi) was applied. In this namespace, there is not such attribute.

If you put color on elements using the Camunda Modeler for example, you will have a new namespace added under the root element bpmn:definitionsxmlns:color="http://www.omg.org/spec/BPMN/non-normative/color/1.0".

The attribute is then named color:background-color among other attributes (all with proper namespaces on it).

The second problem appears because of the expression =f"{year}{trichar}{str(count).zfill(10)}" which is the output report_id on Save and create audit. This seems not be a valid FEEL-expression. Please find more information about FEEL expressions here:

I hope this helps

Jonathan

1 Like

@mogul Can you verify you created the diagram end-to-end in the Desktop (or web) modeler?

If that is the case we may have a bug in the coloring logic. The diagram you shared is clearly broken from the XML perspective; hence the SAX exception.

Can you verify you created the diagram end-to-end in the Desktop (or web) modeler?

If that is the case we may have a bug in the coloring logic.

Yes, the diagram was only ever authored in the web Modeler.

The diagram you shared is clearly broken from the XML perspective; hence the SAX exception.

This brings up another question for me: Regardless of how the document got broken (by Modeler or some other source tool), why does Modeler load up the file without also complaining about the broken-ness?

Thanks for catching that! We didn’t mean for that to expression to end up in there, and is a side-effect of us not understanding that variable input/output mapping is about the logic happening within a Task, rather than the data generated during the whole process.

1 Like

Hello @mogul ,

the Desktop Modeler has a Log output. This log output displayed the problems.

Jonathan

1 Like

the Desktop Modeler has a Log output. This log output displayed the problems.

Great to know! We’ll use that in future. (And, please take the feedback that the lack of those same logs on the web Modeler hurts the Camunda “new user experience”!)

1 Like

This brings up another question for me: Regardless of how the document got broken (by Modeler or some other source tool), why does Modeler load up the file without also complaining about the broken-ness?

We’re considering adding import warnings to the tool. These are meaningless however without a way to fix them, so a (technical) XML view must be part of the package, too.

2 Likes

We’re considering adding import warnings to the tool. These are meaningless however without a way to fix them, so a (technical) XML view must be part of the package, too.

Just a quick followup to note that bpmn.io does in fact complain about the broken -color attributes in the file if we open it there!

This feedback is meaningful and useful by itself, and I think it would be a good addition to the Modeler UI.

1 Like

It does, yes.

As mentioned we’re planning to improve the web modeler accordingly, too. Good things take time, sometimes.

3 Likes