Formkey - resolve embedded:app: fails with spring-boot

Community Community Extensions
1

please see also: https://github.com/camunda/camunda-bpm-spring-boot-starter/issues/72

When starting and deploying the process with the spring boot starter (webapp), we do not use SpringProcessApplication or ServletProcessApplication.
Problem: the keyword “:app:” inside a formkey is not resolved correctly.
I guess I need to somehow set the servletContextPath property to “/” to resolve this, but I do not know how. Any Hints?

2

Hi Jan,

I am not familiar with the Spring Boot deployment scenarion. Do you deploy any process application or is no process application involved at all?

Cheers,
Thorben

3

Hi Thorben,

We start an embedded engine and configure deployments via SpringProcessEngineConfiguration. We do not seem to use a ProcessApplication at all, unless I am missing something.

Jan

4

Hi Jan,

In order to resolve the context path for a form, the REST API backend looks up a process application that is registered for the respective deployment and determines if it provides a property named servletContextPath. So you could deploy an EmbeddedProcessApplication with the desired resources and implement the getProperties method that returns an adequate value for the servletContextPath property. For docs on EmbeddedProcessApplication, see: https://docs.camunda.org/manual/7.4/user-guide/process-applications/the-process-application-class/#the-embeddedprocessapplication

Of course, the auto deployment functionality of the SpringProcessEngineConfiguration does not do that by itself, so you may either have to extend it or deploy the resources independently.

Cheers,
Thorben

5

Thanks for the pointer, will have a look into this.

Regarding auto-deployment: I already have a similar issue open: https://github.com/camunda/camunda-bpm-spring-boot-starter/issues/53 where we discussed if it would not be a good idea to rely on the engines default scan for deployable artifacts instead of doing a manual scan using configured patterns. Maybe this could be the way.

One more thing: I looked deployProcessApplication() and saw that this will try to read the processes.xml file. I do not want to provide on, this is better done via application.properties in spring boot. Do you know if this will fail when I don’t provide an xml?

6

For the engine to perform a deployment you’ll need one. Note that it can be of minimal content though, e.g.

<process-application
  xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive>
    <properties>
      <property name="isDeleteUponUndeploy">false</property>
      <property name="isScanForProcessDefinitions">false</property>
    </properties>
  </process-archive>

</process-application>

and in the process application’s createDeployment callback, you can add any resources you like.

Cheers,
Thorben

7

Hm … I’d really like to avoid any xml overhead … what happens if I provide a processes.xml in the starter that is used by default, could this be “overwritten” by adding one to the applications META-INF ? We could then provide a minimal, working xml but still allow the user to set her own values …

Another question: Why use “EmbeddedProcessApplication” and not “SpringProcessApplication”?

8

Sorry, I feel like I am not able to answer the question since I have pretty much no idea how the Spring Boot and in particular the Camunda Spring Boot integration works. Perhaps @hawky4s can answer these questions better.

Sure, you can also use a SpringProcessApplication. I don’t see much of a benefit with an embedded engine, though.

Cheers,
Thorben

9

Ok, thanks, I will stop asking questions, I will just play around a little and come back with concrete issues …

10

I solved this by using a SpringProcessApplication and setting the contextPath property to “/”

11

Hi @jangalinski,
can you provide more detailed information how you did that ?
If I extend SpringProcessApplication and put a process.xml (empty or not) to META-INF , I step into a exception:
Cannot deploy process archive ‘null’ to default process: no such process engine exists: processEngine is null

12

Hello again,
I answer the question by myself.
If you falsely extend SpringProcessApplication instead of SpringBootProcessApplication, you will run into the described exception.

13

Thanks for clarifying. Seems like I made the same mistake in my answer above. Yes, you must use the SpringBootProcessApplication

14