Configure the timeout of a connector

Product Suggestions
,
1

Hello all,

In many apps, I am using connectors to make TULIP interacts with SAP.
I manage the answer with the HTTP status code in a variable (200, 202, 401 etc).

But when SAP is down, there is no answer. After 120 seconds, the TULIP Player just show the following error:
image

Is it possible to define a 30 seconds timeout and get a HTTP request status 408 or 504? It would be great to avoid to stuck the app and the operator.

I am on LTS11.
Thanks,
Rémi Bayon

2

Hi Remi!

I was checking with the Tulip team on this one, and right now it looks like there isn’t a way for you to configure the error code right now. If you would like, I can make this into a product request for you!

5

Hey @remi.bayon -

We can adjust this timeout at an instance level, but this will impact all of your connectors. I just wrote a feature request to expose this setting for each connector. support@tulip.co can change this setting for you, if you are interested in us going down this path.

I also just wrote a ticket for us to dig a little into how we propagate errors up to triggers. There really are a few status codes that may matter:

  1. Player making a call to the connector host to run the connector.
  2. The connector host call to the external system.

Either of these calls failing could cause a trigger to fail, but we don’t do a great job exposing both of these error codes so you can take the proper corrective actions.

6

Hello both,

Thanks for your help and the explaination.

7

@Pete_Hartnett
one idea: events like a custom widget use?
I think it’s not easy to implement, but who knows?

Regards Chris

8

Hey @ChrisF -

This is something we have talked about, or more specifically allowing you to catch errors within triggers and run actions based on those errors. This can get a little tricky at the edges like:

  • My Trigger has 4 actions, the second action is a connector function call.
  • During execution, that connector function times out, sending the trigger into the catch statement
  • When the catch statement is executed, do we then go back and execute actions 3 and 4? or do we just break out of the logic? We could probably make a logical decision here, but communicating this behavior, and its implication on other surrounding triggers is non trivial.
  • Furthermore, what if there is another failure in the catch statement? do we call it again, potentially creating an infinite loop?

As a first step here, we just need to refine the attributes that you can map to from the connector function UI, allowing you to listen to the return from your external system, the overall call to the connector host, or both. Right now these are all rolled up into a single status code. With this piece broken out, you can start building dedicated trigger logic to retry in the cases that a call fails, without the added complexity of dedicated on error logic in triggers.

Pete

9

Hi @Pete_Hartnett

as long as there are no more complex clauses (do…loop, or if…then…else), I think it’s possible to separate a connector call in his own trigger to react to the return statements.

But I’m not a developer :wink:

Regards Chris