As stated in the title, I have a PLC that utilizes the AsHttp library to implement a Webservice Server. A Web client, implemented via JavaScript, accesses it through ports 80 or 81; ideally, port 81 is preferred for port separation. These are my requirements. During use, I encountered two issues that have been bothering me.
If the process data of the PLC is accessed through ports other than 80 (such as 81 or 82), there will be a cross-origin resource sharing (CORS) issue. JavaScript returns a 200 status code (which is correct) and indicates that the CORS policy has been blocked. Therefore, if we configure the backend to address this CORS issue by allowing all external requests and responding, what should we do?
Regarding the issue of the return value from the WebService request body, I am currently using the AsHttp sample, but the value returned by Get is a String. The client expects a file-based return, such as in XML or JSON format like Fig.
Can anyone from BRCommunity help @jianing.kang?
The setup here is not entirely described but I suspect that the web site and the web service which runs on the PLC are not on the same host / domain and there might be a proxy involved. If this is the case then the Website has to define the CORS policy to allow access to xxx.br-automation.com:81.
Access-Control-Allow-Origin: https://xxx.br-automation.com:81
The AsHttp::httpsService() function block will not care about the Origin: header field unless you implement the reaction in your code yourself and respond with Access-Control-Allow-*: http response headers.
Regarding the response data. The function block allows you to return any response data you like. Just make sure you set the correct Content-Type.
You could use the AsXML to format your response or build the string yourself.
For JSON you would need to also build the string yourself or port a JSON library.
[GitHub - br-automation-com/PvJson: Allows serializing PVs to Json and parsing Json to PVs]
First of all, I’d like to express my deepest gratitude to Christian Unterberger.
Regarding the response data, the customer prefers to receive it in the form of an XML or JSON file, rather than as a string.
Do you have any recommendations on this matter?
Tkx
Thank you.
Regarding the JSON / XML file.
I think what your customer wants is a response in which the data is encoded as JSON (applicaton/json) or XML (application/xml).
Both are only strings fundamentally.
Therefore a client will make some request to a resource formatted like this.
GET /service HTTP/1.1.
REQUEST HEADERS
Accept: application/json
And your service should respond with
HTTP/1.1 200 OK
Content-Type: application/json
…
BODY
{
“value” : “test”
}
To do this you just need to fill the structure
responseHeader.contentType with “applicaton/json”
set the contentLength field to the length of your response data and set pResponseData to
“{\n "value":"test”\n}"
Of course this is simple for simple responses but could require you to implement a JSON encoder / decoder for more complex structure serialization.
Hi @jianing.kang, can you update us, have you found solution with Christian?
To be honest, there isn’t
What EU actually needs is that BuR returns a file stream (not a string), regardless of whether it is in json or xml format.
But it doesn’t matter. We tried to persuade the EU and accept our approach.Or use the method of ASP.
tks