Parse Listeners for Classpath BPMNs and StartForm Keys?

I am using Springboot, and have a parse listener. It parses the BPMN as i expect, but when i go to retrieve the process with:

engine.repositoryService.createProcessDefinitionQuery()
                    .processDefinitionKey(processDefKey)
                    .latestVersion()
                    .singleResult() as ProcessDefinitionEntity

The startFormHandler is null because the BPMN has a null form key, but the form key was set using a parse listener.

It seems like this may be a bug.

1 Like

It seems to be related to how the form key is set:

Seems that the form key can be read in different ways.

Because it works with this:

but it does not appear to work when querying from the processEngine api.

@thorben any direction on best api path?

I was able to retrieve it with:

engine.formService.getStartFormKey(def.id) where def was the:

engine.repositoryService.createProcessDefinitionQuery()
                    .processDefinitionKey(processDefKey)
                    .latestVersion()
                    .singleResult() as ProcessDefinitionEntity

But still unclear why the entity does not return the value and why the entity being returned is mainly a empty entity.

Hi @StephenOTT,

The parse listeners didn’t change the XML in the database. The task listeners are applied to each process definition after parsing and affect only the internal object in the deployment cache.

Hope this helps, Ingo

1 Like

That helps. So should all apis that query the definition look in the deployment cache? And if not in the cache, then it would query the dB, parse the XML and returned the post-parse listener processed object?

If there is a way to change the XML? (I believe I did this with Deployer? Classes the past?)

I am less concerned about the change of the XML, but more concerned about understanding which apis query the XML directly vs looking at the cached version(the version that is processed by the parse listener)

Hi @StephenOTT,

I don’t kown and I think it depends on the function of the listener.

Looking at the Cawemo - Camunda Engine plugin (Camunda Platform Engine | docs.camunda.org) it could make sense to change the XML in the database for the next development iteration. On the other hand, a wrong configuration could execute the listener in the new version twice, if listener calls are added to the model on reading it from the engine.

Only with a new deployment.

Getting a process definition xml will forward the call to getting a resource which is retrieved always from the database: camunda-bpm-platform/engine/src/main/java/org/camunda/bpm/engine/impl/cmd/GetDeploymentProcessModelCmd.java at master · camunda/camunda-bpm-platform · GitHub and camunda-bpm-platform/engine/src/main/java/org/camunda/bpm/engine/impl/cmd/GetDeploymentResourceCmd.java at master · camunda/camunda-bpm-platform · GitHub.

All other calls I found so far go through the deployment cache.

Hope this helps, Ingo

It seems there are a few concepts that have not been well documented to date:

  1. Modification of XML
  2. Modification of activity impl for runtime
  3. Access of modified XML at runtime
  4. Access of modified XML as a download
  5. Access to original unmodified XML

When modifying the XML, my expectation would be to be receiving those modifications when querying the XML in the Apis at runtime.

I agree that redeployments should not double the listeners for example. But I think that ties into the #5 above wheee the unmodified XML is still what gets downloaded.

@Ingo_Richtsmeier any insight into why my code sample above what has the “why?” Comment does not work? I would expect it to read from the deployment cache as you describe.