Now that we can make HTTP request from the ABL (without any .NET, sockets etc). Can somebody show an ABL example of how to consume OData from the DataDirect Cloud.
There are some documentation available in the Release Notes for OE 11.5.1 but nothing in the official documentation yet.
> There are some documentation available in the Release Notes for OE 11.5.1 but nothing in the official documentation yet. Also It's a little
> bit slow as I believe it wait a few seconds to determine if there is any more additional information on the socket connection.
Now we can make HTTP request from the ABL (without any .NET, sockets etc). Can somebody show an ABL example of how to consume OData from the DataDirect Cloud.
There are some documentation available in the Release Notes for OE 11.5.1 but nothing in the official documentation yet. Also It's a little bit slow as I believe it wait a few seconds to determine if there is any more additional information on the socket connection.
Flag this post as spam/abuse.
I was about raise a support case and I was in the process of testing my sample code which was breaking down the timings and I realized that the temp folder was located on a network share. This seams to be the cause of the performance issues I was experiencing.
Side Note: I've noticed that the files created in the temp folder are not of a unique name. Could this cause a problem if you had multiple processes/threads using the HTTP Client at exactly the same time when there is a shared temp folder?
[quote user="CMI"]
I was about raise a support case and I was in the process of testing my sample code which was breaking down the timings and I realized that the temp folder was located on a network share. This seams to be the cause of the performance issues I was experiencing.
[/quote]
Interesting. Given that the temp/debug files are only written when -debugalert is set, do you see the slower runs when debug is off?
[quote user="CMI"]
Side Note: I've noticed that the files created in the temp folder are not of a unique name. Could this cause a problem if you had multiple processes/threads using the HTTP Client at exactly the same time when there is a shared temp folder?
[/quote]
Good question.
The single name debug file was because those files are mainly intended for developer debugging (so a single name makes things easier. for me anyway :) ).
The HTTP client doesn't keep the stream/output open - it just writes in append-mode when needed. That said, it is certainly possible to have multiple clients write to the same files simultaneously, especially if you're using a shared network drive for -T or you're on an AppServer. Feel free to log a bug to make the names unique.
Yes indeed, I did have -debugalert enabled since this was my development environment and that would explain the debug files. So that would be expectable having static names.
So I guess this actually raises another point, how do you actual get the message payload/body from the server response?
Looking at the available documentation (ref: Table 7: Extracting typed data from a response) it's not clear to me how oEntity object is assigned a value from oResponce. How does oResponce even know about oEntity object?
Update:
I think I've just answered my own question. I think that the oEntity needs to be supplied as a second parameter for the RequestBuilder:Get() method?
Yes indeed I did have -debugalert enabled (since this was my development environment) that would explain the debug files. So that would be expectable having static names.
So I guess this actually raises another point, how do you actual get the message payload/body from the server response?
Looking at the available documentation (ref: Table 7: Extracting typed data from a response) it's not clear to me how oEntity object is assigned a value from oResponce. How does oResponce even know about oEntity object?
Flag this post as spam/abuse.