PowerBuilder’s prowess to be able to enable Win32 and Win64 native applications to directly interact with the Internet universe started when Sybase added the iNet object class to the PowerBuilder System Class area. The iNet object object’s methods allowed native PB apps to link out to a specific URL via the LinkToURL command, send data to a specific URL via the PostURL command and/or read data from a URL via the GetURL command. While this is still in PowerBuilder 2017 R2 for backwards compatibility, its functionality limitations and security vulnerabilities (only supports up to TLS 1.1) definitely makes it worthwhile to explore the new HTTPClient object, which we will discuss in this blog.
Figure 1- iNet object as seen in the PB IDE's Object Browser
In modern-day Internet interactions, applications often require more advanced functionality within their URL processing and support for at least the TLS 1.2 protocol is a must. Thus, starting in PB 2017 R2, Appeon added the HTTPClient object to the PowerBuilder’s System Class area. The HTTPClient object is designed to take over from the iNet object and to provide key advanced features that were requested of the iNet object even way back in the Sybase days of PowerBuilder but were never implemented. Some of these key advanced Internet features requests were to: set Request Header(s), read a Response object’s Header or Body, get the Response Code from a Request, process binary data, handle JSON data, and of course support TLS 1.2.
You may be wondering why Appeon didn’t just enhance the iNet object? One of the key reasons for introducing a new HTTPClient object class rather than revamping the existing iNet object was to avoid iNet object class behavioral changes that could break existing apps when migrating to newer PowerBuilder releases. The other key reason was an entirely new implementation was necessary so that the RESTClient object (covered in another blog) could make use of the HTTPClient. This was important design consideration by Appeon such that PowerBuilder would have a modularized and extensible architecture.
The HTTPClient object class has added a number of valuable features that are useful for many HTTP transaction scenarios, including when calling RESTful Web APIs. For example, Timeout and SecureProtocol properties are provided where the PB developer can control URL’s that do not respond (this would “hang” iNet-based applications) and the HTTP security protocol used (such as TLS 1.2 – the de facto standard today). The new HTTPClient also has a nice productivity setting with the AutoReadData property where the developer can offload some PowerScripting to the HTTPClient object class to automatically read Response body information after any URL interaction.
Figure 2- HTTPClient object as reflected in the PB IDE System Class browser
If the result set retuned to the HTTPClient session is JSON (JavaScript Object Notation) formatted data, you can also pair the HTTPClient with the new JSONParser object class introduced in PB 2017 R2. With the JSONParser, you can basically traverse any JSON data – even with complex embedded repeating values – and parse the data items out of the JSON result set as required. We’ll blog more about the JSON object classes soon to better outline the prowess of using this class of object in tandem with the HTTPClient, but below is a basic introduction.
Figure 3- JSONParser object class in the PB IDE System Class area
Here is a simple code snippet from the JSONParser that can be used to process a RESTful returned JSON result set …
Long ll_root
Long ll_loop
Long ll_rows
String ls_command = "GET"
io_http.Sendrequest ( ls_command, <URL> ) // Send RESTful request
io_http.getResponsebody ( ls_data ) // Get Response body
io_parser.LoadString ( ls_data ) // Load JSON data stream into Parser
ll_root = io_parser.GetRootitem ( ) // Get JSON root pointer
ll_rows = io_parser.GetChildCount ( ll_root ) // Get Child count (#rows)
FOR ll_Loop = 1 to ll_rows // Walk thru JSON buffer
// Process JSON datum
LOOP
The HTTPClient can also receive XML formatted data as well. Of course, PowerBuilder has had a parser for that for many, many releases in the form of the PBDOM (PowerBuilder Document Object Model), which can read the XML schema and process the datum within the XML. The key with the JSON and XML data is also using the Base64 Windows APIs or the upcoming PB 2017 R3’s built-in Base64 function to read and decode binary data. You can read more about the binary conversion required and how to perform this in PowerBuilder in our Base64 blog post.
Look for another upcoming blog post around the HTTPClient’s “kissing cousin” the RESTClient object class. This object can make your development life a lot simpler when your DataWindows need to source data from an HTTP-based resource that returns data in a JSON format – you can automatically call the HTTP-based resource and load the data into a DataWindow with one simple command!
