Deployed process cannot access forms in the application resources

Camunda 7 Topics Discussion & Questions
,
1

I have a spring boot application which deploys a process with forms as part of the jar resources. It also contains embedded forms, which I reference using the key embedded:app:forms/xxx.html where forms/ seems to be the name of the folder below src/main/resources/static that contains the forms.

When users deploy a new process through Camunda Modeler which points to the already deployed forms with keys in the above form, the user tasks do not find their associated forms. Instead, the tasklist shows an error “Form failure: The context path is either empty or not defined”.

@StephenOTT explains how a deployed process can have its forms deployed alongside with it in the same deployment (apparently, they must be literally in the same deployment, as discussed in Form failure: The context path is either empty or not defined).

My situation is the other way around: I want to enable users to deploy processes via Camunda Modeler that use existing forms in the application resources without requiring them to deploy the forms with them. I can see that the web app receives 200 when it tries to retrieve the form at http://127.0.0.1:8095/bem/camunda/api/engine/engine/default/task/e7ce491e-5829-11e9-9da8-02f48d9e896d/form, but the contextPath is null. It makes sense, that is exactly what the error message states.

{"key":"embedded:app:forms/observe-progress.html","contextPath":null}

My understanding is that there are two different ways to refer to embedded forms, one points to forms in the application resource and uses embedded:app:, the other points to deployed forms in the same deployment as the process that uses them and requires embedded:deployment: form keys.

But I would expect that a deployed process can use both forms deployed at runtime and forms that are already deployed with the application resource - why else would there be two kinds of form keys?

1 Like
2

The reason why the context is null seems to be that ApplicationContextPathUtil fails to come up with a context:

public static String getApplicationPathForDeployment(ProcessEngine engine, String deploymentId) {

  // get the name of the process application that made the deployment
  String processApplicationName = null;
  IdentityService identityService = engine.getIdentityService();
  Authentication currentAuthentication = identityService.getCurrentAuthentication();
  try {
    identityService.clearAuthentication();
    processApplicationName = engine.getManagementService()
      .getProcessApplicationForDeployment(deploymentId); // <<== no process app name found for deployed process
  } finally {
    identityService.setAuthentication(currentAuthentication);
  }

  if (processApplicationName == null) {
    // no a process application deployment
    return null;                                        // <<=== ends here
  } else {
    ProcessApplicationService processApplicationService = BpmPlatform.getProcessApplicationService();
    ProcessApplicationInfo processApplicationInfo = processApplicationService.getProcessApplicationInfo(processApplicationName);
    return processApplicationInfo.getProperties().get(ProcessApplicationInfo.PROP_SERVLET_CONTEXT_PATH);
  }
}

which in turn is caused by the fact that registrationsByDeployment only contains deployments that are part of the application resource, but no deployments from the Camunda Modeler:

 public ProcessApplicationReference getProcessApplicationForDeployment(String deploymentId) {
  DefaultProcessApplicationRegistration registration = registrationsByDeploymentId.get(deploymentId);
  if (registration != null) {
    return registration.getReference();
  } else {
    return null;
  }
}

I would expect that an application context can be determined for processes deployed at runtime, too. Is this a bug or is this by design?

2 Likes
3

@dschulten really great write up :+1:t2::+1:t2:

As a quick test, can you try and do a deployment through the java API using the classpath resource. See if the Bpmn works with the forms when you deploy through the classpath rather than sitting in the db.

4