Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
Our edge devices already implement a REST API comprising a set of HTTP service requests (POST only). Many of the service requests just push data but a few are expecting values to be returned. In the Composer, when I create a service that returns a single value (result), the HTTP response to the device is always an InfoTable with a single row and single column (in JSON format in this case). The value is the one I want, but now I have to change the firmware in every device to find the value in the response. Is there anyway to override the default behavior in this special case of services returning single values as an InfoTable? What are my options?
Hi Andy,
the way you get closest to what you need is the following:
change the following two headers of your REST request call:
Accept : text/csv
Content-Type : text/csv
To get a correctly formatted result with a system >=6.5 you'll have to change a setting in the Platform Subsystem: Switch off Filter Content Type'. This has some security impact, see Updating the Request Method and Content Type Filtering for CSRF Protection in the 6.6 HelpCenter.
The result will return your String in the second line (the first will be the header column. i.e. the name of the property, by default this is result.
I just tried these settings and invoked a getStringValue service on a TestThing Thing that returns a String. The invocation URL is:
http://192.168.159.131:8080/Thingworx/Things/TestThing/Services/getStringVal
and the result will then be:
"result"
"Hello World!"
Here is s screenshot of my Postman request:
Cheers, moritz
I believe you are doing proper POST calls so you won't have to turn on the switch.
For the service return values, you can first of all define in the Service what the result parameter basetype is, so could even just be a number or string or boolean.
then with the Accept header you can get text, text/xml, text/csv, application/json returned
Thanks, Moritz and Pai. Close is good - thanks for the suggestion on using text/csv. However, this solution will still require a small change in the edge device firmware.
I guess the real question is, when connecting with edge devices with a predefined API, Is it possible to customize the corresponding Thing services in a way that would allow me to, for example, control the exact encoding of the result in the HTTP response or use certain values from the HTTP URL and header?
Or, said another way, how does one produce a Thingworx extension to talk to a proprietary or non-standard device?
Thanks,
What response is your call expecting to be returned?
In one specific case, the device says it is expecting application/json of a dateTime offset value, but it is not expecting the InfoTable metadata that my service sends with the response. But there are other cases where the return value is different and I am looking at this as a general problem. These service also need to read values from the HTTP POST URL and/or header. Whatever the existing API is I need to develop services that match..
Hi Andy, if you want to use the Calls your equipment is making right now, there will be some major changes needed on the platform, as I indicated, Thingworx REST API can't consume the additional pieces you have in the URL.
So all the information will have to go to the Parameter declaration.
However when it comes to return values, again you can create services to create any BaseType information within Thingworx that you'll be calling and those can come back in text / xml / json or csv
Without a doubt some work will be involved on both ends.
I already successfully added jsp pages to the TWX codebase - these can then use TWX APIs and you'll have the freedom to format the output in any way you want. You could also create your own servlets, then you'll need modifications to the web.xml.