[REST-API] Service Task Error Handling


I have a service task which request a Rest service and I want to handle any kind of exception which that service throws. Just for information this REST Service is a C# service and does not know anithing about Camunda.

So, this is the test model:

So, when my service raises an exception nothing special happens and the execution finish without any problem. Did I made any mistake?

Follow the function body:

I made a try with a Java Service which I could put some comunda jars. I did a simple service like that:

Still the same…

Can somebody give a clever idea?

I assume you’re making a REST call using the Camunda http-connector connector. This creates a standard HTTP stateless connection wherein you will issue a REQUEST and wat for a RESPONSE which then terminates the session. Actually, it doesn’t matter how you initiate the call because a REST call is a REST call.

There are multiple failure modes in two broad classifications:

Connectivity Errors

  • Bad URL

  • Connection denied (TCP port on service endpoint not listening)

  • Connection timeout (no endpoint response or too long a wait time)

Service Execution Errors

  • Bad authentication

  • Unknown method invoked

  • General server errors

  • General service errors

The first group may (though I don’t know how to do this) be detected within the context of the http-connector itself. I would have a look the documentation.

The second group will require you to parse the response. In most cases you’re going to get an HTTP code (200, 204, 500, etc.) and some form of message. You’re going to have to parse for the error(s) you’re interested in.

These principles, I think, would hold for any implementation of a REST call, though your particular implementation might offer other functionality.

If the problem is actually receiving a response to parse, then you need to be sure the service endpoint is receiving the request and is issuing a response. This might seem obvious, but you need to confirm that you’re actually receiving a response of some sort, if only an HTTP acknowledgement.

1 Like

Hi Guys,

here is an example how to handle errors with a connector.

As Michael said, you have to parse the response and map it to an BpmnError.

Hope this helps,


1 Like


I’m struggling with first type of error (Connectivity Errors). I’ve associated Error Boundary Event to Connector REST service task - and when remote service is not reachable I just got exception and process breaks.
I’m able to work-around this by using Java Delegate and playing with REST connection myself - but wanted to understand if there is a way to use OOTB solution for REST calls.


Hi Michal,

if you mean technical errors, the out-of-the-box-solution would be to make the task async and fill the retry-time-cycle attribute according to your needs. If all retries are done, you will find an incident in the cockpit to handle the issue and retry once more.

https://docs.camunda.org/manual/7.6/user-guide/process-engine/transactions-in-processes/ and https://docs.camunda.org/manual/7.6/webapps/cockpit/bpmn/failed-jobs/ for further details.

Hope this helps, Ingo

Thanks for the explanation but I already knew that, I just need to know how to throw propagate the exception… I didn’t make this information clear enough… My fault, but I apreaciate it :slight_smile:


This link helps, but I had to clone the repo and take a look to the sources. But after I try to complete a task I got this exception:

Failed to link org/camunda/spin/impl/logging/SpinCoreLogger

Googling about this I found a WTF solution: just declare the org.camunda.spin.camunda-spin-core as manifest dependncie and all the work is done.

Ok, everything is linked on Wildfly module and should work as well…:grinning:

No, Didn’t…:astonished:

Why? :scream:

Any Idea?:no_mouth:

Just for information: I solved the problem adding the folloing jars:


You guys must asking: Why do not you use as provided module? I can’t because I deploy the same jar on a tomcat server with one processEngine and Database connection configured as Gobal Resource and on a Wildfly with a ProcessEngine and database connection configured on standalone.xml file.

Anyway, thanks guys. You all are great.