The XML file attached was created by another application.
The file is read into an byte[] fileContent and then deployed using the Java-API:

        DeploymentBuilder deploymentBuilder = this.repositoryService.createDeployment();
        deploymentBuilder.enableDuplicateFiltering( true );
        deploymentBuilder.addInputStream( fileName, new ByteArrayInputStream( fileContent ) );
        deploymentBuilder.name( fileName );
        Deployment deployment = deploymentBuilder.deploy();

But as the umlauts are there on different views in camunda cockpit (lower part of screenshot 1 and screenshot 2) it cannot be a problem of deploying.

Hi sebastian.stamm and roman.smirnov,

does anybody know a reason why we should get the DMN XML encapsulated in a JSON object in the history view? If not I would propose a binary endpoint for the decision definition xml like the binary data endpoint for deployment resources. This way the encoding would be preserved.

Cheers,
Sebastian

I do not see a reason why we would need it wrapped in JSON. When we introduce a binary data endpoint to retrieve the XML, we should do this for the process definition, too (I assume we have a similar problem there).

I think at the time that endpoint was implemented, there was some reason to have the process definition's id included in the response. Unfortunately, neither the ticket (CAM-142) nor the commit (https://github.com/camunda/camunda-bpm-platform/commit/b61d1e0d19622c06373cf212aa1e16e183b7728e) give the reason why.

Hi gimbel,

this maybe solvable at least for DMN with a new Rest endpoint. Also maybe a similar problem exists for BPMN. The REST part is quite simple but would require backend and frontend work.

Cheers,
Sebastian

Let's discuss next week if this can be done in scope with 7.4

we will not be able to do this with 7.4

While playing with https://camunda.org/dmn/demo-stage/? and storing and deploying the changed file umlauts suddenly were displayed correctly.
That's because BPM xml-file was stored in UTF-8 encoding now instead of former ISO-8859-15.
A reason that this is working might be, that I also have set property file.encoding to UTF-8 for my WildFly instance.
We changed our application now to write out decision tables in UTF-8 encoding which solves the problem we had.

But anyways the encoding and display should be handled correctly in my eyes.

I agree but that makes the issue less urgent.

We are closing this ticket as part of our backlog grooming. Reasons:

• We did not receive sufficient evidence that this ticket is important