A World of Features with PowerBuilder 2019

A World of Features with PowerBuilder 2019

PowerBuilder 2019,  released on May 31, 2019, brings to the table C# development capabilities (a C# IDE and .NET data access objects), enhanced REST Web API client for PowerScript desktop and Web apps, new UI technology for PowerScript desktop apps, and numerous other enhancements.  But what we want to discuss in this blog article is the world of new features that PowerBuilder projects can take advantage besides what is in the box.

Let’s first start with the world of cloud-based services.  These days pretty much anything you want to do is offered as a cloud-based service - some free and some paid.  For example, you may store and share documents using Dropbox, and then sign legal documents with DocuSign.  As another example, you may strengthen your application security with two-factor authentication using Google’s free app (iOS/Android).  In general, most cloud-based services can be incorporated into PowerBuilder projects by using either the HTTP client or REST client in combination with tokens.

Now if you modernize your app architecture with the new C# Web APIs of PowerBuilder 2019 your world of (free) features kicks up to another level.  In general, any library on NuGet that is compatible with the .NET Core framework can be used in your C# Web API.  For example, just by adding a few lines of code and the Swashbuckle library you can automatically create documentation for your C# Web APIs.  Just keep in mind to read the license agreements because most but not all libraries on NuGet are free.  Aside from the libraries on NuGet, let’s not forget what the .NET Core framework and C# language itself provides.

While this blog doesn’t give you a detailed technical recipe, we hope it has piqued your interest to explore popular cloud services and libraries on NuGet.  You can further your knowledge about the new features of PowerBuilder 2019 by watching the release webinar.  If you get stuck, take advantage of the community Q&A.  And we hope you will attend Elevate 2019 to get live training on the new features of PowerBuilder 2019.

  4389 Hits
  4 Comments
4389 Hits
4 Comments

The Future of PowerScript Desktop Apps

Now that PowerBuilder 2019 and its new C# development capabilities are in beta, we are starting to get questions about the future of PowerScript desktop apps.  Specifically, does Appeon recommend developers to move away from PowerScript desktop apps?  And related to this point, will Appeon be enhancing or just maintaining the features of PowerScript desktop apps?

A quick look at the PowerBuilder roadmap page and it is obvious we have put much focus on the C# language, open standards, and cloud architecture.  Increasingly, most new .NET projects have such high-level requirements.  Perhaps this is why the .NET framework is radically different these days – the .NET Core framework is open source, cross OS, and targeted for cloud deployment.  And unfortunately, we could not use any of the .NET stuff Sybase did because it didn’t meet these requirements.  So certainly, we had to put a lot of focus on non-client/server features. 

Now let’s assume for the sake of argument that the cloud is the future and focus on if and how a PowerScript desktop app fits into such future.  A native UI technology (e.g. PowerScript desktop app) has certain advantages over HTML (e.g. ASP.NET page) and vice versa.  However, for most line-of-business apps we believe a native UI technology offers the best set of tradeoffs.  Key industry players like Microsoft seem to be recognizing the shortcomings of HTML and trying to lessen this gap with Progressive Web Apps (PWAs).  At Appeon, we think it makes more sense to “cloudify” the PowerScript desktop app than replace it with some other technology. 

In fact, we began to “cloudify” the PowerScript desktop app the second we took over PowerBuilder, which we did on top of its existing C++ runtime and PowerScript language.  Starting with PowerBuilder 2017, we introduced an all-purpose HTTP client, a REST-specific client, an OAuth2 client (with support for tokens), and JSON handling (parsing, generating, packaging).  And in PowerBuilder 2019, we have significantly enhanced all of these features, especially how they integrate with the DataWindow to minimize the amount of coding you do. 

But of course, there is still more work for Appeon to do with the PowerScript desktop app to make it attractive for new projects, no matter they are client/server or cloud based.  This is exactly why in every single release for the foreseeable future we have planned to bring major new features to the desktop target.  For example, in PowerBuilder 2019 we will revamp the UI of desktop apps.  And in PowerBuilder 2021 we plan to revamp deployment of desktop apps (from the cloud).  Beyond that, it would be silly of us to say now, and most vendors wouldn’t even say this much. 

Read More
  71301 Hits
  28 Comments
71301 Hits
28 Comments

PowerBuilder’s SOAP to RESTful Evolution

PowerBuilder’s SOAP to RESTful Evolution

The movement from SOAP-based web services towards RESTful-based web services is another evolutionary journey for PowerBuilder developers and their related applications. Originally, Sybase added SOAP (Simple Object Access Protocol)-based features in PowerBuilder version 8.0. The original SOAP features were aligned with the Java implementation of EasySOAP and provided a messaging protocol specification for exchanging structured information in the implementation of web services across computer networks. Sybase enhanced the web service feature in PowerBuilder version 9.0 to include the ability to handle more complex SOAP interactions. In PowerBuilder version 11.0, Sybase then added support for Microsoft’s .NET-based web service framework as well. This greatly improved the web service interaction possibilities in that era of PowerBuilder. The .NET web service feature was tweaked again in PowerBuilder version 11.5 (and latter PowerBuilder versions) to support the newer releases of the .NET framework.

Since PowerBuilder 11.5 though, the basic SOAP-based architecture has been PowerBuilder’s “go to” vehicle for web service interactions. However, the IT industry moved onward with newer REST (Representational State Transfer) web service technology, which has now become a de facto architectural style used by most modern web services. The REST approach defines a set of constraints and properties based on the HTTP protocol that provides greater interoperability between computer systems on the Internet today. By REST using a stateless protocol and standard operations, REST systems can have faster performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system, even while it is running.

There are six guiding constraints that define a RESTful system. These constraints restrict the ways that the server may process and respond to client requests so that, by operating within these constraints, the service gains performance, scalability, simplicity, modifiability, visibility, portability, and reliability. If a service violates any of the required constraints, it cannot be considered RESTful. The formal REST constraints are as follows:

Client–server architectureStatelessnessCache-abilityLayered systemCode on demandUniform interface

The focus of a RESTful service is on resources and how to provide access to these resources. A resource can easily be thought of as an object as in OOP (object-oriented programming). A resource can consist of other embedded resources as well. While designing a system, the first thing to do is identify the resources and determine how they are related to each other. This is like the first steps of designing a database: identify entities and relations. Once we have identified our resources, the next thing we need is to find a way to represent these resources in our system. You can use any format for representing the resources, as REST does not put a restriction on the format of a representation.

The client and service talk to each other via messages. Clients send a request to the server, and the server replies with a response. Apart from the actual data, these messages also contain some metadata about the message. It is important to have some background about the HTTP request and response formats for designing RESTful Web services. REST requires each resource to have at least one URI (Uniform Resource Identifier). A RESTful service uses a directory hierarchy like human readable URIs to address its resources. The job of a URI is to identify a resource or a collection of resources. The actual operation is determined by an HTTP verb. The URI should not say anything about the operation or action. This enables us to call the same URI with different HTTP verbs to perform different operations.

Read More
  4404 Hits
  1 Comment
4404 Hits
1 Comment

Base64 – Your New Binary Friend

Base64 – Your New Binary Friend

PowerBuilder’s Web Service prowess has increased significantly in recent releases from Appeon - in particular, PB2017 R2 and R3 release. These PowerBuilder releases have given us a new HTTP Client and RESTful Client capabilities that can utilize the newer JSON (JavaScript Object Notation) data format and the ever-popular XML (Extensible Markup Language) data format as well. When processing standard data type information in either the JSON or XML format, the ease of data exchange is very high. However, when trying to transfer binary data, the JSON and XML formats and the supporting HTTP transport layer for RESTful web services will not readily handle binary data.

To address this binary dilemma in the JSON and XML realm, today’s applications utilize the Base64 binary-to-text encoding mechanism to convert binary data into ASCII text sequences of the data. This allows the converted data to be injected into the JSON or XML schema and transmitted without upsetting the HTTP transport protocol. While it does increase the overall transmission data length when utilizing this encoding scheme, it is necessary in order to achieve the end goal of data exchange with these technologies.

In PB2017 R3, PowerBuilder will be updated to include new functions to both encode and decode binary data to and from the Base64 encoding scheme. The new PB built-in Base64Encode and Base64Decode commands can now perform the encoding in and out of the Base64 scheme using the standard PowerBuilder run-time engine support. For example, the PB Base64 PNG image used in this article would look like the following in a hexadecimal editor:

Figure 1- PowerBuilder Base64 Image in Hex

Using the new built-in Base64Encode method, the PNG image binary data is converted into a set of ASCII character sequences which can now be easily transmitted or even read by a simple text editor, as follows:

Read More
  4080 Hits
  0 Comments
4080 Hits
0 Comments