How to configure conditional flow based on HTTP response code

[Anand Kane]

Hi Everyone

I have the following integration,

- Receive update event from SF lead

- Invoke HTTP POST endpoint.

- Log response from the above POST request.

The REST application is a spring boot application and I have used 'API Client Connector' to create a connection to it. I throw a RuntimeException from inside the handler method of the POST endpoint on every third invocation. It is ensured that the endpoint sends back HTTP response 500 when this happens.

I want to configure a conditional flow based on the response code. For this I tried to create an 'Advanced Conditional Flow' using expression ${response.status} == 500 and some other varients. However, the integration fails to start with an exception org.apache.camel.language.simple.types.SimpleIllegalSyntaxException: Unknown function: response at location 0.

I tried to find how to access the response object in Camel expression language, but could not find anything useful that will unblock me.

Can someone kindly help me with how to configure such a conditional flow?

Thanks

Anand

[Zoran Regvart]

Hi Anand,
we have error handling implemented on a very narrow feature set, i.e.
for integrations of API provider type, i.e. when we handle what
response is given to the client for specific statuses and within the
SQL connector where we handle and emit Syndesis specific errors, a
requirement for error handling.

So in your case we don't have this supported. In fact the Camel route
will error out before reaching the conditional step and the
conditional step won't be invoked at all.

As a side note, and more pertaining to your question, the expression
needs to be in a syntax supported by Camel. Look at the reference
here: https://camel.apache.org/components/latest/languages/simple-language.html#top

To get this working you'd need to change the service you're invoking
to return a 2xx HTTP status even for errors and have the body contain
something like a JSON with "status" property that you can use in an
expression for branching.

zoran

> --
> You received this message because you are subscribed to the Google Groups "Syndesis" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syndesis+u...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/syndesis/23c3c0ce-06a2-4cd7-a834-763ca1f300den%40googlegroups.com.



--
Zoran Regvart

[Anand Kane]

Thanks a lot for a super quick response Zoran (as always). I really appreciate that.

You are right in saying that the flow errors out even before reaching the conditional step.

While it's a good idea to include 'status' in the response body, it may not always be possible; especially when connecting to a third party API. One workaround I can think of for such cases is to create a step extension to wrap the API call. This has a downside that users will have to provide credentials every time they use the extension. A proper solution would be to implement error handling for API Client Connectors. What do you think about this? 

Thanks

Anand

[Zoran Regvart]

Hi Anand,

On Tue, Feb 23, 2021 at 6:59 AM 'Anand Kane' via Syndesis
<synd...@googlegroups.com> wrote:
> While it's a good idea to include 'status' in the response body, it may not always be possible; especially when connecting to a third party API. One workaround I can think of for such cases is to create a step extension to wrap the API call. This has a downside that users will have to provide credentials every time they use the extension. A proper solution would be to implement error handling for API Client Connectors. What do you think about this?

I agree, definitely, and I think we had that on the roadmap, but it
was prioritized down over other functionality. I think we have most of
the pieces in place; that is I think we're in a state where we need to
implement error handling in the HTTP connector, which is basically
declaring what errors can occur and a translation from an exception to
an error data model. I think the best fidelity we can offer would be
on API client connectors (ones created from OpenAPI/Swagger) as we
have errors declared in the API specification. For HTTP connector we
can list all (common?) HTTP status codes and offer mapping those. The
only bit that I'm not sure at the moment is how generic is the UI
support for this, i.e. will doing the connector work suffice or do we
need to make changes to the UI as well...

zoran
--
Zoran Regvart