Echo Veolia Integration

As with many external services, there can be concerns regarding response times which is why a fixed max timeout is set. In Echo Veolia's case, we are also adding additional overhead by converting the request and response elements to and from SOAP/XML, when the appropriate setting or parameter is set. To help transparency, each integration Endpoint tracks the time taken to convert as well as the time taken for the service to respond. This data is returned as part of any request into the integration.

Note - This is a particularly large search query made by the GetEventsForObject Endpoint with unflattering parameters given and is not indicative of normal speeds but helps demonstrate the differing times being displayed.

Request:

{
    "objectRef": {
        "type": "PointAddress",
        "value": [6599297],
        "key": "Id"
    },
    "debug": false,
    "query": {
        "from": "1970-01-01T00:00:00.000+01:00"
    }
}

Response - Data removed

{
    "success": true,
    "technology": "SOAP",
    "apiTime": 4303,
    "totalTime": 4460
}

"success" <boolean> - This is a standard boolean to notify the consumer as to whether we consider the request "successful", if not there will be an errors array with further details.

"technology" <string> - This will either be  SOAP or JSON.

"apiTime" <number> - The time, in milliseconds, it took to query the service and receive its response.

"totalTime" <number> - The total time, in milliseconds, it took to complete all aspects of the query. This will include converting to and from a SOAP schema if set.

From the above example we can see that it took 4.3 seconds to retrieve a large data set from the service and ~150ms to convert the request and response data into the JSON schema we expect. This is one of the largest and most expensive of the available Integration Points, data wise, but these metrics can be useful when the service is under load to determine if the GOSS integration aspects are being ill-performant or if the service is struggling.