Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Kristjan on June 16, 2023, 11:17:18 AM
-
I am going to read API data from an air handling unit. First part is getting a token with a POST method. One of the attached images shows the vendor instructions in cURL.
Request works fine in Postman using form-data with username and password. Attached is the HTTP formatted request from Postman.
Now, in the PLC, I set up the HTTPCMD with Request Content-Type = multipart/form-data. And in the Request Body String I have tried all kinds of formatting (see image) but the API replies with an error that I am "Missing content-type boundary" (see image). How do I format the Request Body String with proper content-type boundary? How do I format a form-data request?
-
My 510th parameter permutation seems to have solved it :D
I changed Request Content-Type to "application/x-www-form-urlencoded" and formatted the Request Body with only double quotes at the beginning and end. No other quote marks within the Request Body string. Image attached for future reference. Future generations might be happy to find this ;)
Now, I am getting a decent response with an access token... no wait! It's not the whole token!?!
The response goes into a variable of User memory block JSONData (string structure with 1024 characters) but the response is only 273 characters long and clearly missing a lot. Postman shows me a response with 1466 characters (insane token length - I'll ask the vendor if he is willing to compromise for me).
But why is the response not filling the 1024 characters of the memory block variable?
-
The current issue is the length of the JSON responses and requests. Token response is 1466 characters and other responses with AHU data are typically 3000-4000 characters. I guess I cannot use my User defined variable type JSONData (1024 characters).
Is there a sensible way to process the large JSON responses and using very long token strings in a new request?
Putting the token response into consecutive D-memory locations and parsing and concatenating for a new request is hardly an option since I will always have to deal with the long token.
-
Just make the HTTP Response be a BYTE Buffer instead of a STRING. You can look at a BYTE Buffer (call it Resp) in Memory View and change the format to ASCII.
The JSONPARSE instruction can take a BYTE Buffer, and you probably have fields larger than 1024, so you will need to utilize a second (or third, fourth, etc.) BYTE Buffer when you parse/extract the data from Resp BYTE data block.
Just keep peeling the onion.
Good coding:
You might want to MEMCLEAR Resp buffer before every HTTPCMD to make it be easier to debug (otherwise, the buffer will contain characters from the previous HTTPCMD). Make sure you have an EDGE CONTACT driving the MEMCLEAR, because you want to clear it on the EVENT of starting the HTTPCMD, not on POWERFLOW (i.e. every PLC scan power flow is ON) cuz you need the HTTPCMD data to stick (and not be overwritten by the MEMCLEAR)
-
Thanks franji1. The byte buffer works great and I have also parsed out the token from the response into a new byte buffer (1355 characters).
The next step is using the token in the header of a new HTTP request. And the request header string will be something like "Authorization: Bearer eXXXXXXXXi", just a lot longer token from a byte buffer. How can I create this request header with static text in combination with 1355 characters from a byte buffer?
-
If it's truly static, you could do it offline using the Memory Image Manager for that specific data block.
If it's not static, you can do multiple STRPRINT/STRGETB in pieces parts, utilizing array indexing for your datablock index
-
It's not a static token but I know the token length from the JSONPARSE instruction (Number of Bytes Parsed). I have STRPUTB the whole token into several SL-strings.
Now I want to use the strings in the request header (see attached) but I can't get the PLC to resolve the strings. The header must include "Authorization: Bearer " and then the token. But in this case it is actually sending "Authorization: Bearer SL10 SL11 etc..." I have tried moving the quote marks, no quote marks on the text, strings after the last quote mark etc.
Is there a DoMore syntax that resolves the strings before sending the request header?
(It doesn't look like I can use a byte buffer in the request header...)
-
Those are string scripts - you do not have to use the $" escape sequence - the box knows it is text, so just do
"Authorization: Bearer " SL10 SL11 SL12 SL13 SL14 SL15
HOWEVER, there is a limit of a print script to 1024 characters, so I don't think you can use HTTPCMD since the HEADER section only supports string, not buffers.
-
DmD actually forces double quotes with $-escape character. See attached warning/edit
DmD doesn't accept "Authorization: Bearer " SL10 SL11
Too bad the print scripts is limited to 1024 characters (I guess it still solves 99%) since the token is 1355 characters long. I guess it makes this integration unavailable.
The reason that I am using the PLC here is that the site has an older generation SCADA system that doesn't support web services. So the PLC was intended to be a gateway. The latest generation SCADA does support web services and in those cases I read data directly from the API into SCADA. I don't need the data for any processing in the PLC.
-
DmD actually forces double quotes with $-escape character. See attached warning/edit
Doh! I had it wrong. I thought Header was a print script. It ONLY takes a String Literal or a single String element. Regardless, it doesn't support buffers for text longer than 1024 characters.
-
Thank you for your support. It is extremely useful!
I'll try other methods to retrieve the API data. Maybe Node Red on a Raspberry Pi.