PowerBuilder Modernization Challenges

by Pierre Kubryk, Project Manager and Architect at Blu Age

Introduction

When PowerBuilder hit the market in 1991, it provided features to quickly create form-based applications synchronized with a database. For public and private institutions looking to move away from old technologies, or even to computerize their processes, it represented the opportunity to structure their development work while being able to quickly push new screens and forms to their users .

As PowerBuilder continues to fade from use, and as businesses now turn to digitization to leverage the capabilities of modern technologies (Clouds, containers and scalable infrastructures), it is important that your forward plans include a path to a smooth transition for your users and teams. In this blog note, I will demonstrate how Blu Age addresses three key parts of PowerBuilder applications to ensure you can move to a modern multi-tiered, HTML5, Angular, Java or .NET Core architecture while keeping the benefits that made you pick PowerBuilder to begin with.

Moving from a fat client to an HTML5 architecture – When multiple windows have to fit in a single one

PowerBuilder is a powerful language. It enabled building complex multi-windowed applications to answer your complex business needs when mobility, micro-services, clouds, and containers were not yet a thing. Moving from a fat client to a modern HTML5/SPA REST/SOA architecture is the key to enable the transformation of your applications that will accompany the digitalization of your business. This cannot, however, be done successfully ignoring your users and current processes.

To avoid disrupting your user experience, Blu Age has developed a unique way of modernizing and re-architecting your PowerBuilder applications to retain the functionality of the multi-window or MDI experience directly in your users’ favorite web browsers. This includes the ability to display at the same time several modernized window for small views or switch to a full-screen experience for the ones that are more complex. Blu Age modernization also ensures the synchronization of data shared across several worksheets or windows.

This is how a typical PowerBuilder application modernized with Blu Age looks like:

Your users find again their menus (1) but also benefit from a modern login/logout interface (2). It is important not to overlook that point when moving to a web-based application! Because you are moving to a very different architecture that is more network intensive, your enterprise and/or regulatory requirements in term of security and authentication are likely going to be totally different. Blu Age is flexible and enables you to integrate your enterprise-wide authentication mechanisms. We have already successfully integrated OAuth2 and token-based authentication mechanisms as diverse as Owin, JWT Bearer Token, JAAS, KeyCloak, etc.

In terms of graphical interface, your users will also benefit from a multi-window layout where each SRW modernized has its own independent titles (3), controls (4) and scrollbars (5). This example shows a two-way split, but other options are available. Usually, going beyond four windows displayed at the same time is not desirable, but it also depends on your users’ needs and their screens resolutions.

Modernize your PFC dependent applications to new solid foundations

The benefits provided by the PowerBuilder Foundation Classes (PFC) are not out of date. Many organizations use them to enrich the list of readily available components for their application portfolio. Others are using them as a cornerstone of their applications, delegating important functions such as the screens validation, the authorization management, the update flows, and the database transaction granularity.

To ensure a successful modernization, Blu Age teams use an open source Angular framework coupled with either a REST/Spring or REST/.NET Core backend. It is tailored by our engineers and architects to ensure that while transforming your applications to a modern client/server architecture, your business flows will remain the same even when the PFC implicitly orchestrates them. Blu Age will also reengineer the updates to the database in order to keep the right database transactions encapsulation. This is a key to secure functional equivalence and data integrity.

The diagram below depicts a piece of the Angular layer save process happening on modernized PFC based applications :

When a user triggers a save on a PFC window (1), the list of components with pending updates are gathered (2) recursively (3) using Angular Observables. For efficiency purposes, only these components will be validated (4). The Update process can then start (5). This step will gather all the updated Data Objects - using the same Angular publisher/subscriber mechanisms - and aggregate them in a single REST backend call. The .NET Core or Java code can then take the relay and push all the updates in a single database transaction.

From a technical perspective, it is important to note that it keeps the encapsulation responsibility of your components and windows while giving you a full control to make them evolve on the long run. The generated code uses the latest capabilities of Angular to let you override, extend, or change any of these behaviors.

From the all-encompassing DataWindow to a modern layered architecture

The DataWindow is the fundamental piece of any PowerBuilder application. From a modern architecture perspective, they mix many layers: they are at the same time your data-beans, your views, your Data Access Object (DAO), and your Object-Relational Mapping (ORM). Quite a lot of features in files that rarely pass the 100 lines of code threshold!

Because so many things are happening behind the scenes when triggering a simple retrieve() or update(), a special attention is required when modernizing them. Some of the DataWindows properties like updateKeyInPlace or UpdateWhereClause actually capture business knowledge tightly coupled with your data. Ignore them and you can forget your data integrity!

The Blu Age software transforms your DataWindows, splitting them across the modern architecture layers: for each of your DataWindows, the concerns are appropriately dispatched to the modern HTML5, Angular services, beans, and backend DAO. Nevertheless, all of them are integrated to work seamlessly and update your database in an exact way and order your PowerBuilder application did.

Enough said, let’s take a look at the modern code!

The Presentation layer

There is not a lot to say about this Angular template. This is a textbook example. It is small – you get one template.ts, one component.ts and service.ts per DataWindow. Unadulterated – There is no JQuery hack, data and events being bound as they should to the template code.

The data bean/data object/DDO

The data object has the role of storing the data retrieved from the database or modified by your user/business logic. Data presented to the users are transferred back and forth from the backend to the front end through REST requests. This object will, therefore, have a representation in both layers of your application.

To enable querying the database, the Blu Age transformation will keep the mapping between the data object and the table columns. This information is kept only in the backend layer through Java Annotations or .NET Core Attributes and never exposed on the front end.

DAO Engine

PowerBuilder uses several levels of data cache. When triggering an Update on a DataWindow, PowerBuilder will read these caches and build dynamically, using the attributes seen before, the update, delete, and insert queries that need to run to unload the data changes back to the DB. All this is done outside your control.

As part of the modernization, Blu Age will generate the .NET Core or Java code that will perform these calculations. This DAO code is as accessible and maintainable as any other parts of your application!

The snippet above is an extract from the .NET Core version of the DAO engine. From the three legacy DataWindow buffers – Original, Primary, and Delete (the Filter buffer is not of interest in the backend), we still use the Delete Buffer (1) to compute the delete SQL statements. However, we have radically changed the way updates (2) are calculated. Why? To account for the architecture change. Remember, we are moving away from a fat client architecture where the user’s modifications to the data state and the DAO engine are co-located on the same computer. We now have a network between the two. The updates happen on the web browser client, but the DAO is on the server side. You certainly do not want to pass your 1,000 records dataset back to the server just for one update.

Summary

Blu Age modernizes your existing PowerBuilder applications preserving all of the special features of PowerBuilder while updating the technology. The result is Java or .NET Core applications with all the functionality and benefits of your existing PowerBuilder applications but none of the sustainability risks.

More information

The information in this blog will be discussed in more detail during the upcoming webinar, "Turn your PowerBuilder applications into modern web-based applications with Blu Age!" The webinar is scheduled for November 29th at 11:00 am Eastern and you can sign up here :

Register for the webinar

To learn more, sign up for the webinar or feel free to reach out at contact@bluage.com.

All product names, trademarks and registered trademarks are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, trademarks and brands does not imply endorsement.