InvokeHttp method returns binary contents, it is up how you are further processing the result that matters.
Since your service returns JSON, and Teiid does not have any JsonTable construct like XMLTable construct in 6.4.5 you would need to convert JSON to XML using JSONtoXML function and then use XMLTable to parse the contents.
I know that. But I want to use the OData translator and in the browser the webservice returns XML content. Therefore I was confused about the error I got.
With the WS translator I currently use I use the InvokeHttp method indeed.
Mendix documentation in question, Mendix only has OData3, I thought using OData4 would solve that?:
Basically an OData service returns the payload based on the "Accept:" header that an HTTP client sends. In the case of the browser, it automatically defaults to XML, thus you are seeing an XML formatted response. If you were calling through "invokeHTTP" and did not add in any headers then the OData service chooses whatever default it is configured with, which in this case looks like JSON. You in order to get XML response you need to add the "Accept" header to your request
call invokeHttp(... headers=>jsonObject('application/json' as "Accept")
Thanks for the explanation.
So how do I tell a source model table in Teiid designer to "call invokeHttp....."?
Because I don't want to use a PRC that calls invokeHttp, I want to use the provided OData translator which automatically creates a source model for me based on the OData webservice.
I would assume that this OData translator figures out for me whether to use XML or JSON and automatically sends the correct headers.
I think you misunderstand what I want to achieve and when I get the error. I have absolutely no problem consuming the OData (or whatever webservice) service using the invokeHttp using the WS translator, I made myself a program that autogenerates this for me using the metadata of a webservice. However, I do have trouble consuming an OData webservice that I constructed using the Teiid Connection to my server which then autocreates a source model including all tables with their columns and types; even primary keys.
Below is a working example which consumes Sap SuccessFactors (using either the sap-gateway or odata translator):
As you can see, there is no invokeHttp, at least as far as I can tell not directly visible in my development environment.
I might miss something but how can I tell my Mendix source model to send a header to the OData webservice to provide me with XML content?
>However, I do have trouble consuming an OData webservice that I constructed using the Teiid Connection to my server which then autocreates a source model including all tables with their columns and types; even primary keys.
So you are consuming from OData service called Mendix on back end service using Teiid's OData translator. Then you are using the Teiid JDBC connection to connect to the Mendix based VDB and building your own OData service on top of it? Do I have that right?
If yes, Why not use the OData API Teiid exposes already over any VDB?
The setup is as follows.
I created a datasource (resource adapter) on my server which I gave the odata translator and the base url of the odata webservice (e.g. https://api5.successfactors.eu/odata/v2/ or something ending at /odata4/).
Then in Teiid Designer I start the server. The I select Import -> Teiid Connection -> the just created datasource -> Select the OData translator -> Let this create a source model (based on the metadata) for me automatically; this source model contains all tables, columns and even primary keys.
This works almost flawlessly with for example Sap SuccessFactor except only some trouble with automatically converting dates (but we do that in our virtual base layer). When I follow the same steps for the Mendix OData webservice I get the source model with all the tables. However, when I try to access the data using either preview or a newly created VDB I get the error mentioned in the first post.
To be honest, I didn't know I could consume a OData webservice this way with Teiid until 2 months ago and since this looks like the way to go because it can query the webservice in a more efficient way.
Ok, that is more clear. I think your Mendix OData service is not capable of returning the payload in XML perhaps? The Teiid's OData translator uses the XML format for reading the entities. You can easily check this by attaching "?$format=xml" to end of query on a web browser. for ex: http://<mendix>/service/entityName?$formamat=XML then see what is returned?
That is just the weird part. By default it returns XML content in the browser. But I will try you suggestion to see what it does. It might that it doesn't understand the format= option.
I did some further digging. Mendix as of now does not support json. I think the odata translator of teiid defaults to json, otherwise the following error does not make a lot of sense. Mendix uses OData version 3 which I hoped to consume using the OData 4 translator. This does not seem to work. There seems to be an incompatibility between Mendix and Teiid, should I open a support ticket for this at RH?
Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 test_abp: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
at [Source: sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@506d74a0; line: 1, column: 2]
OData V2/V3 and OData V4 translators are completely different, they are not to be replaced with one another. So, using the OData v4 translator from Teiid against Mendix OData V3 version WILL NOT work. You have to use the Teiid's OData V2 version. Even there the V3 version never became public nor popular, although we have bits and pieces of some functionality for V3 Teiid does not conform to full V3, V2 and V4 yes. So, use the V2 translator, not V4.
> I open a support ticket for this at RH
If you are a RedHat customer you can submit ticket, but if not the only support is community support as we are trying to provide here, once we figure out if there is a bug in Teiid code, then you can open up a JIRA for it. Until then this forum is best to talk to us.