Skip to main content
To homepage To homepage

I have two particular use cases where I would like the TX REST connector to be able to handle nothing being returned. 

  • In one case I've configured the portal to do a PUT request. PUT's generally don't return any body.
  • In a second case, the API is just configured to do this sometimes. We get ID's from another endpoint that we are then supposed to use dynamically like: endpoint/{ID}. The problem is that the source system can have phantom ID's, meaning that ID=13 doesn't really point anywhere. endpoint/13 then returns just a completely empty body. 

In both cases the problem seems to be that the connector can't handle this. We get back:

Failed to execute endpoint 'xxx':
Unexpected character encountered while parsing value: }. Path 'TX_Autogenerated_Element', line 1, position 28.

Going of the error message, it would seem that the connector is assuming a json was returned and automatically starts trying to convert is somehow. 

 

I need to be able to handle these situations somehow, since I have no control over the returns of the API. 

Also, I already tried to apply a dummy-xslt. The idea was that I could perhaps create a table transform that would simply return a dummy value always. I used this xslt:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <dummy>Dummy Content</dummy>
    </xsl:template>
</xsl:stylesheet>

but that did nothing, indicating that the problem occurs before any table transforms. 

Hi @Benny 

Why do you need to use a PUT, I haven’t had any cases of people using this?

Normally it is POST or GET that is used.

Also if you want to control what is returned, you would normally state some sort of header regarding the type of data to be returned. E.G. 

Content-Type = "application/xml"

Accept = “application/xml”

The PUT case is where I use the portal to upload images to my datalake, based on values returned by other endpoints. I know this is kind of exotic, but real useful in my case. 

The other case is just something that can happen in working with this API. I get ID=13 from endpoint A, and normally that would mean I can get an XML with data from enpointB/13. However in a small number of cases that returns noting. I have no way of knowing beforehand when a return body will be empty, so this need to be caught. 

 

Your suggestion with the headers has no effect. Since the body returned is empty Accept="application/xml" has no effect at all. 

Hi @Benny 

The PUT part, would most likely not return an result.

Have you tried to see what is returned if you set up the cache to do so to files.

Maybe it attempts to see the } of {ID} as the value to use somehow.

I configured a test-endpoint like endpoint/13 (so hard-coded) which returns nothing. There are two cache files created: Data_.raw and Data_.xml. Both are empty.

Hi @Benny 

Perhaps the PUT option isn’t as well defined.

What happens if you use a tool like Postman to run the Put command with a hardcoded setup, does it then return something?

In Postman both work as intended, meaning empty body. The empty body seems to be exactly the problem. 

Hi @Benny 

I have no way of testing it, but how does this look in postman, when it returns an empty body? Does it give back a HTTP status code 200 OK or a HTTP status code 201 Created when it is executed?

If it doesn’t work with this specific option because it doesn’t return anything, then I don’t see how it would ever be made to handle it. This is a data source, meaning it is supposed to pull data from the source, not add to it.

It is still possible to do such things, you can do CURL calls with a powershell script, so you could run it with the endpoint execution or similar.

I will admit that that I'm kind of stretching the tools scope by using it for PUT requests. 

 

However I, as I described, I also face a situation where the empty body is just the result of a GET neatly returning a “200 OK”. Successful request will return data that I need to process. I cannot predict when this will happen, so hardcoded/dynamically excluding these requests is no option. I need to be able to make these (GET) requests and then handle this unwanted outcome. 

 

 

Hi @Benny 

As far as I am aware, we are working on changes handling empty field names and values. I don’t know if an empty result will be part of it, but it should be able to handle that an result is empty.

Normally it will be set to stop, for pagination and so, but I don’t know if it could also work for the initial result also being so.

I have asked the developers.

Reply


Terms and ConditionsCookie settings