Http-connector: Get the Request Response Time?

Is there a way to get the request response time for a http-connector request?

Sort of, by using a start and end listener you can use a Groovy or JavaScript function/script to extract the current time. This assumes that the time for “setup” of the activity is neglible and that the bulk of the duration is waiting for the response.

For example, using JavaScript in the start listener, you could use:

var d = new Date(); var n = d.toString();
var s = d.getTime(); execution.setVariable(“elapsedStart”, s);

Then in the end listener use:

var d = new Date(); 
var e = d.getTime(); 
var s = execution.getVariable("elapsedStart");
var elapsed = e - s;

“elapsed” is your duration.

@mppfor_manu thats a decent idea. thanks.

overall would prefer to add the response time to the http-connector lib.

Well, sure, but that sort of falls outside of what it’s supposed to do. It would be nice if it automatically pushed the actual payload into an accessible variable in the same way that a boundary error event pushes the error message into errorMessageVariable.

Hi Stephen,

Connect has an interceptor concept, i.e. you can execute code with every executed request. This is not covered by the user guide but described in the sources here: https://github.com/camunda/camunda-connect/blob/master/core/src/main/java/org/camunda/connect/spi/ConnectorRequestInterceptor.java. I think the test suite also contains an example that makes use of such an interceptor.

Cheers,
Thorben

1 Like

I will look into it. Thanks @thorben

Hi Steven,

I’m just curious: Isn’t it enough to take the duration of the task (from the history service)? From my understanding it would take only a few processorcycles to build up the connector and nearly all the time is spent on the network, isn’t it?

Cheers, Ingo

That’s a good idea too. My original use case was to have the response time be available next to the response payload variable so I would action based on a request that was taking a long time. Example if a request took too long then throw a message. I was thinking of just doing this before the end of the execution of the service task. But yes we could just add a eval somewhere post-service task, and use the history service.