I recreated the transfer task and for now it seems to work fine (or something else changed at the background). Let’s see if it remains stable (otherwise I will let you know in this ticket).

Unfortunately still very unstable:
 

It gives the following warning:
Failed to execute request for endpoint 'All statuses'.
HTTP Status Code 500 Internal Server Error
Response body:
 

----
There is no setting in the datasource settings to increase logging as with other data sources so I can not provide any more details.

Hi @Roy V 

In my guide I suggest this setup.

I noticed that I did not type it with a uppercase I in all the places I mention this.

I mention in my guide that it is really important that the name field you point to in the {} option needs to be exactly the same as in the source, down to case settings and so.

If you change your job log statuses to jobs/{Id}/status instead, it will work again.

Also you need to check that the result of the table looks like this.

There was an issue where it would switch around the content of these fields if you used a Data Lake.
I do not experience this in version 6645.1

Thanks for the reply but it is not clear for me.

We have three endpoints as you can see below. If I change jobs/{Id}/jobs to jobs/{Id}status then I do not have the JobExecutionLogs table any more and that is the one we need with messages if the job ran succescfully.

You can have a look at the settings in the portal for the TimeXtender API data source  for customer Vesteda . Can you please tell me what it is I need to change.
 

Hi @Roy V 

You mean that you get this message, right?

Failed to execute request for endpoint 'All job logs'.
HTTP Status Code 500 Internal Server Error
Response body:

I get this as well, at times I don’t, but once I get it it seems to happen continuously.

This message is not about the setup of the provider, so if you only get this, it means that the API itself returns this.

Hi Thomas

Thanks for the reply. 
So indeed the setup is correct as TimeXtender sometimes processes the data from the API correctly, so no change necessary on that part.

But if the API returns this message (for me, for you, for others then probably as well)  then it is the API itself which should be looked into right, as to why it returns this message so often instead of a consistent output?
Would be great if that can be addressed to someone.

Hi @Roy V 

Yes, I wanted to confirm our experiences were the same. I made an internal case about this.

Great, thanks.