As you're probably already well aware, the .Net WebForms target was removed from PowerBuilder beginning with the 12.5.2 maintenance release. The reason it was removed was because of a third party control that was implemented in the later versions of it (11.5.x, 12.x, and 12.5.x) which SAP is no longer authorized to distribute. As a result, they had to pull it from the product as well as remove any EBFs or maintenance releases that contained it.
The question that came up quite a bit in the "Latest News from the PowerBuilder World" webinar, and which I've recieved by email since, is "what do we do now?". This document is an attempt to address that.
Note that I've created it as a document rather than a blog post so that others can contribute as well. If you know of a good alternative solution, feel free to add it.
Please don't feel compelled to criticize the suggestions made by others though. Let's leave it to the end user to make their own evaluation of the pros and cons of the various approaches relative to their own environment. Just because a solution works best for you doesn't mean it works best for everyone else.
1. Stay with WebForms. If you are already using WebForms, there is no need to stop using it. As noted in the release notes for 12.5.2, subsequent EBFs are configured so that they can be applied to both the original 12.5.1 MR and the 12.5.2 MR. If you want to continue to use webforms, simply don't apply the 12.5.2 MR.
2. Appeon. Appeon is a third party tool that takes PowerBuilder Classic (soon to be renamed to PowerBuilder Native) code and coverts it to a web application. They recently also released a mobile version of their product that supports deployment to iOS as a native app with plans to expand the capability to Android and Windows Mobile in the near future. Because the tool takes existing PowerBuilder code and converts it, you continue to do development using the PowerBuilder IDE, minimizing the amount of code rewrite necessary to support the web platform.
3. Use RDP. One of the presentations at last year's PowerBuilder Developer's Conference by Dimitri Joosten was entitled "VHG-Tools Platform PowerBuilder .NET, Expression Blend, Web and Cloud". He later did a similar presentation on PowerBuilder.TV. The approach was to move the application to PowerBuilder.NET in order to modernize it's appearance, and then use products like 2X to allow access to the application via the web and/or mobile devices.
4. Rewrite to provide services to be called from HTML5. Another of the presentations at least year's PowerBuilder Developer's Conference by Marcelle von Wendland was entitled "How to use PowerBuilder .NET to Architect Powerful Mobile Apps for Mobile Workers". She also did a series of articles for the ISUG-TECH journal outlining the approach. The approach was to migrate the application to PowerBuilder.NET and convert it to web services which are then accessed through a new HTML5 based front end.
5. Create visual assmblies and then use those in a WPF Browser Application. Unfortunately, PowerBuilder.NET's support for WPF doesn't extend to WPF Browser applications. There are ways that it can be tweaked to support them, but the approach is risky. However, with the release of 12.5, PowerBuilder.NET does support the generation of visual assemblies, and those can be used as the basis for a WPF Browser application written in Visual Studio. I demonstrated a rather simple example in a recent blog post.
6. ASP.NET MVC Framework with PowerBuilder generated assemblies
Convert your business logic into assemblies using transactions and datastores (non visual only).
Use XML export templates to render data in HTML, map protect column property to the new contentEditable HTML5 attribute, different templates could address different devices. Use XML import templates and possibly XSL validation to import data into datastores.
Needs a lot of rewriting, good knowledge of .net and web techniques.
- SAP Managed Tags:
8 Comments
