Creation of user task after asynchronous service task fails

Workflows
, ,
1

I have a simple workflow, which

  • sends an email (or export the document, anything communicating with another service) (service task)
  • prompts the user for input (user task)

When I start the process with synchronous continuation everything works fine. However, when I enable asynchronous continuation on the service task (by setting asynchronous before / after), creation of the user task fails.

Log:

2023-01-12 08:21:55.832 [        ] ERROR 24916 --- [aTaskExecutor-1] org.camunda.bpm.engine.context           : ENGINE-16004 Exception while closing command context: ENGINE-03051 There was an exception while invoking the TaskListener. Message: 'Failed to create task with id: cb095e81-9249-11ed-abb1-909d995d5857'

org.camunda.bpm.engine.ProcessEngineException: ENGINE-03051 There was an exception while invoking the TaskListener. Message: 'Failed to create task with id: cb095e81-9249-11ed-abb1-909d995d5857'
	at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.invokeTaskListenerException(EnginePersistenceLogger.java:468)
...
Caused by: com.mgmtp.a12.workflows.querying.exception.TaskCreateException: Failed to create task with id: cb095e81-9249-11ed-abb1-909d995d5857
	at com.mgmtp.a12.workflows.event.handlers.task.TaskCreateHandlerImpl.createTaskOrLogError(TaskCreateHandlerImpl.kt:34)
	at com.mgmtp.a12.workflows.event.handlers.task.TaskCreateHandlerImpl.onTaskCreate(TaskCreateHandlerImpl.kt:27)
...
Caused by: java.lang.NullPointerException: null
	at com.mgmtp.a12.dataservices.document.persistence.internal.SaveDocumentSupport.prepareDocumentForCreate(SaveDocumentSupport.java:57)
	at com.mgmtp.a12.dataservices.document.persistence.AbstractDocumentPersister.beforeDocumentCreate(AbstractDocumentPersister.java:72)
...

SaveDocumentSupport.prepareDocumentForCreate tries to fetch the current user from the SecurityContext. As this code is executed by camunda’s task executor it runs in a different thread than the one starting the process. Hence the thread-bound SecurityContext is empty.

Although it is clear why this happens, it is somewhat unexpected. It would be great if this behaviour could be mentioned in the workflows documentation.

Will this be “fixed” from A12-side? One could argue that the creator of the task document should rather be a “service” or “system” (instead of the user initiating the process or completing the previous user task), but there’d still have to be support in dataservices for this.

I noticed a somewhat similar topic Approach for dealing with security context in the case of scheduled methods with this reply:

We are sorry for the problems with the security context. I have created a ticket to fix that: A12S-3012 we will also fix that in 35.0.0

Maybe A12S-3012 will fix this? Will 35.0.0 be part of a 2022.06, or will there be a backport to 34.X? (I don’t have access to mgm’s Jira)

For the time being I would be glad if someone could suggest a workaround. Currently I am considering the following

  1. Re-model the workflow, such that the service-task and the user-task run in parallel and not consecutively (although this will change the semantics somewhat)
  2. Save the SecurityContext / Credentials as a process variable and somehow create a new SecurityContext in the task-executor thread (using camunda’s interceptor + plugin mechanisms - rather not)

Thank you.

2

Hi @anon67142020,

did you configure your Camunda and DS instances to use/allow certificate authentication? This is necessary for service tasks to work correctly. You can check GetA12 Login and the corresponding UAA documentation for a quick guide. With a working certificate setup the security context should be filled by one of our Camunda event listeners.

Regards
Oliver

3

Hi @oliver-mild-rush, I did not (yet) setup certificates.
I don’t see how this is related, as this behavior occurs after every service task - e.g. email notification - configured for asynchronous continuation. This is not so much about populating the security context on the receiving end (dataservice when using export delegate). It is rather about “losing” the security context when Camunda’s task executor supplies the executing thread. Creation of user tasks after the service task fails, as dataservices’ lower level API (specifically DefaultDocumentRepository#create, used locally by Camunda) still tries to access the SecurityContext. However, I assume this will be fixed with A12S-3012.

Update: maybe I am wrong here, and the Camunda listener will also populate the SecurityContext for other service tasks, regardless whether they are communicating with remote dataservices or other external services. We are about to configure certificates and I will get back to you once we did this.

4

Hi @oliver-mild-rush, we’ve successfully setup certificates and - miraculously - this solved our problem for all kinds of asynchronous tasks. This is not so obvious from the documentation. Thank you for your help.
Regards, Alex

5

Hi,

glad to hear this worked for you. Thanks for the feedback, we will change our documentation accordingly.

Regards,
Oliver