PBDJ Feature Story

Our company, AssetPoint, develops, sells, and supports a software product, TabWare, an EAM (Enterprise Asset Management) software package that is developed with PowerBuilder. The mandate from our new ownership in the spring of 2008 was to release a web-architected version of our application by year end (2008!).

We had been having trouble competing in the marketplace without a web application for at least two years prior to that, and the issue had finally reached the boiling point. With such an aggressive year-end deadline and a limited budget, a re-write was out of the question. With a re-write as a known non-option, we approached this initiative with this four-step process:

1. Develop proof of concepts of our application using the two most logical technologies (PowerBuilder 11 and Appeon)
2. Select one and move forward with tackling the technical issues (hoping to not encounter impasses)
3. Perform efficient quality assurance and testing
4. Determine commercial deployment processes

Proof of Concept
Our PowerBuilder application is very large, with about 70 PBL files comprised of about 1600 DataWindows and 400 other (i.e., non-visual, global function, etc.) objects. Like many PowerBuilder applications, ours contains a lot of business logic embedded in the UI. We began the project by evaluating both solutions that we felt had the potential of helping us meet our aggressive goal of having a web solution by year-end: PowerBuilder 11 and Appeon. We first developed a prototype using the PowerBuilder 11 solution. We had received some training from Sybase on PB 11, and using that and some consulting services from Sybase, we migrated our application to PB 11 and tested portions of the application. While PowerBuilder 11 yielded a more "pure" web form application, we felt that it lacked the scalability and performance that our large application required.

We next developed a prototype using Appeon. Appeon will provide a trial version of their product for prototyping. Using the trial version, we pretty quickly deployed and tested the application with Appeon. While it was far from being fully functional (without us tackling the issues described below) it functioned well enough for us to decide to pursue it further. The performance and scalability seemed better suited to our large application than an un-refactored PB 11 application. We chose to use the .NET version, since our development staff is most familiar with Microsoft technologies. We came up with a list of the pros/cons of each, and after considering this, decided to move forward with Appeon.

Appeon - Technical Steps
The first task to tackle is to work through the Unsupported Features List (USF) that the Appeon product produces for you. This is a very nice feature of the product. Our USF list was not very big - it contained only 211 items. We obtained consulting services from Appeon to help us work through this list, as well as other issues we knew we would encounter as we went. It is extremely helpful to have an Appeon resource as part of your development team. The Appeon resources have good experience with this type of project and in deploying a PowerBuilder application to the web using Appeon. Some points to note:

• Appeon has a function (AppeonGetClientType() ) that can be used to determine if the application is running in web mode or not; this is very helpful if you are trying to maintain a Win32 application in addition to the web application with the same code line. This is important to us since our current client base is relatively happy with their client/server implementation.
• RichText controls can be problematic (as they would also be in a WebForm application). You will most likely have to find alternative solutions to these. One of our main usages of RichText controls was for the configuration and printing of bar-coded labels. We replaced this functionality with external reports, such as Crystal Reports or Microsoft's SQL Server Reporting Services (SSRS.)
• Our biggest frustration to overcome was being "captured" in the Appeon ActiveX control on the browser and not being able to solve problems with a .NET web solution. This problem was solved by developing what we call our Web Interaction Architecture (WIA). It involves creating a .NET assembly with COM exposed methods to allow PowerBuilder to call the methods. To avoid requiring .NET on the client, we use PowerBuilder to open an IE object that can navigate to a web page that provides the desired functionality. The .NET methods retrieve the user input from the web control and return the results as a string to the calling PowerBuilder function.

The PB script would look something like this:

--------------
OLEObject IE
integer lI_rc
IE = Create OLEObject
li_rc = IE.ConnectToNewObject("AssetPoint.TabWare810.twNet.twIe")
If li_rc < 0 Then
//handle failure
else
string ls_results
ls_results = IE.UserInputBrowser("")
IE.DisconnectObject()
End If

Testing
A good testing process is a requirement. There were two different types of testing that had to occur: functional and performance.

Obviously, functional testing is necessary. A QA analyst who is very familiar with the application's functionality is needed. Functionality that works in the Win32 version may not work in the web version. Changes made to fix one problem can cause problems somewhere else. During testing, we did rely on the fact that we weren't changing the business logic, and in many places assumed that since this is still our time-tested PowerBuilder code running the engine that it would still work. Our QA processes focused more on user interface (UI) issues and our integrations with third-party applications, than on pure business logic that has worked in our application for years.

Performance testing is also necessary. We relied heavily on our Appeon developer to help us with this. He had access to a test bed of well-equipped servers and desktops, as well as the LoadRunner load testing tool. Our QA analyst assembled test cases and provided a test database, and the Appeon developer performed the test cases. He also made all performance enhancements that were required as a result of the performance results. The performance enhancements primarily involved reducing server-side calls and tuning database procedure and triggers. Some performance improvements were as much as a 20x improvement.

Commercial Deployments
We sell our application to customers, so deployment and installation issues are important to us. There are some shortcomings to the Appeon solution in this regard:

• Different Appeon installations cannot be installed on a single server. This makes upgrades troublesome as you cannot install a new version beside an older version and test it out exactly as it will be installed, before cutting it over to Production. Having the ability to support this installation/upgrade practice would greatly reduce the downtime window required for a production upgrade.
• Having merge modules available for us to merge into our product's MSI installation would be beneficial to reducing the steps required to install the complete solution.
• The requirement of administrator privileges for the ActiveX installation can be problematic for some clients. Future versions of Appeon, in conjunction with functionality to be provided in Internet Explorer 8, will hopefully alleviate this situation in the near future. IE 8 has functionality that should allow an ActiveX to be installed in a user's profile, which would not require administrator privileges (since malicious code should not present a danger to the system from the user space).
• Appeon is taking steps to streamline the license key registration process, which is really needed for companies like ours that deploy this solution to multiple clients. As we look further down the road to upgrading an installed client base, these types of seemingly minor licensing issues can quickly become major issues.

Summary
Our aggressive year-end goal was achieved, and we shipped the product to our first customer in December 2008. We have had other installations in 2009. We are still learning how to respond to questions on the new platform from our clients and how to streamline the deployment and licensing processes. Developing and releasing the product is just the first (albeit major) step in a long journey of learning how to support a new platform and product architecture. Educating your sales force, support staff, and implementation specialists are significant tasks that need to be incorporated into a product rollout plan. If your co-workers and clients are really engrained in a long-standing tradition of your current client/server application, consider the learning curve that they have to work through too.