4 minutes reading time (823 words)
Featured

PowerBuilder’s HTTP Client Evolution

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!

  

Comments (3)
Saturday, Jul 14 2018

excelente

#72
1

Thursday, Nov 14 2019

Once again the stewards of PowerBuilder fail at the simple task of keeping the environment in-line with what it's users need. The entire internet does not live and die by ReST alone. So much of the internet relies on SOAP's XML format and it's not about to change. Web services written to leverage SOAP are not going to be rewritten just to support ReST. Those back-end services are going to remain SOAP, what they need is TL1.2 support, and adding it to the server side is as simple as installing a certificate and changing the URL from http to https, DONE. But the client side... with Appeon falling flat on it's face and not adding the simple support for TLS1.2 for it's SOAP service will lead to PowerBuilder shops to question... WTF is appeon thinking? Instead of a simple 5 minute change to the code, it becomes a 6 month project for each Web Service that needs to be re-written from PB's SOAP implementation to the HTTPClient implementation... flat out stupid. Who wants to then add another 3 months to the server side? NO ONE. One burn that won't be forgotten when it comes time to modernize application. Powerbuilder will be left behind for .NET, Java, Ruby... anything but another PowerBuilder nightmare in the future.

Just because it can be done, doesn't mean it should be done. But appeon thinks otherwise and then makes up reasons why it can't be done, saying... it was to avoid iNet object class behavioral changes that could break existing apps when migrating to newer PowerBuilder releases". Really? then code it so it doesn't, otherwise the developers are stuck with the problem instead of the appeon. Complex XML documents with repeating multi-level tags with dozens of values just became a nightmare due to the short sighted view of appeon. Instead of appeon taking one for the team, the entire team gets bent over the table while appeon watches from the sidelines.

1
Friday, Nov 15 2019

Hi Alex,

Compare with Web Service / SOAP, REST is more powerful, extensible and more popular. Thus we provided REST functionality in PB 2017.
If you used Web Service / SOAP functionality before in PB, you can use HTTP Client to call instead. You can refer to the link below for more details.
https://www.appeon.com/developers/get-help/knowledgebase/call-soap-web-service-using-httpclient-object.html


Regards,
Ken

0