Responding to message event with HTTP Error

Camunda Platform 7 Topics Camunda Platform 7 Process Engine
#1

Hi,

I would like to respond to the external /correlate message Rest API call with an HTTP error (e.g. 400 Bad Request). Is this possible?

I would like to achieve something like this:
image

I’d like the non-interrupting message event to reply to the caller with an error.

Thanks!

#2

Hi @annamaria.cassola

You cannot change the REST API - that’s a Camunda implementation. You might be able to change the correlation keys / process variables to match the message…

Can you explain what you are trying to do?

BR
Michael

#3

Hello @annamaria.cassola ,

what you try to achieve is something like transactional message correlation.

One quick and dirty way is the utilisation of the business key (as correlation key) and making it unique in the process instance db table. Problem: Dirty persistance layer exceptions.

Another possibility is the registration of an execution listener that queries for existing process instances with the same business key and throws an exception.

I hope this helps

Jonathan

#4

I would like to achieve a unique business key for a particular process. That is, I do not want to have multiple in-flight processes having the same business key, and if there is an attempt to create one, I would like the client to be given an error.

#5

I will try the second option you suggested.

1 Like
#6

The second options suggested by @jonathan.lukas does get closer to what I was hoping for, but it gives an internal server error (500), still leaving the client without a more specific reason for failure.

I believe I may need the client to query for existing processes with the same business key prior to requesting the creation of a new process, but this will take business logic away from the process and into the client, which is not desirable.

#7

Hello @annamaria.cassola ,

you could extend the Rest API and create an endpoint similar to start process instance.

There, you have the control over checks that can be run before starting a process instance. The main advantage here is that you can control the exact behaviour of the endpoint which is an important requirement. Sorry I underestimated it at first.

Jonathan

#8

Thanks for the ideas. I could provide a custom endpoint that would abstract the checks from the client. That should work too.

1 Like