• Legacy Modernization

PowerBuilder Modernization Frequently Asked Questions

Business aspects

Q. After migration, will the development team be fully maintaining Java or .NET and PowerBuilder 100% phased out?
A. Yes. You can forget about PowerBuilder after migration.

Q. Can you send us a few case studies?
A. Have a look at following links:

Q. What are the parameters that are used to estimate the modernization project?
A. Please fill out our questionnaire at
PowerBuilder Modernization Questionnaire

Q. Can we do a Proof of Concept with our application, before committing to the project?
A. Yes. Usually we perform a "visual horizontal slice" of the application as a proof of concept - all the windows, menus, visual user objects and data windows of your original application can be shown in a browser environment. If you need a "functional" PoC, it is also possible. After getting your application we will estimate cost and time frame for the proof of concept sub-project.

Q. What are your business models?
A. We have 3 major business models (please contact us for more details):

General Migration Questions

Q. What version of PowerBuilder are supported?
A. We support PowerBuilder versions from 5 through 11. If you have PowerBuilder 12 and want to convert the application to Java environment, the modernization project is also feasible, though may require more manual efforts to convert advanced features. If you have PowerBuilder 12 and want to convert it to pure .NET solution, with CSharp instead of PowerScript as your programming language, our migration process can also be a solution.

Q. What is the percentage of automated conversion without any manual intervention?
A. We estimate that about 80 percent of the source application is converted to a target platform automatically. This measure depends on how tightly the source application is coupled with the windows environment (OLE Automation etc.), what significantly legacy features of PowerBuilder are used ("goto", passing arguments to functions by reference etc.) and on the architecture change from rich-client to thin-client architecture. Usually we have a first stage of the migration projects as a "system learning stage" (see our "step by step" presentation http://maintrend.net/PB/PBModernization.pps). During this step we can estimate what manual effort will be required.

Q. Will the conversion work successfully with a home grown framework (if we do not use PFC).
A. Yes. We just consider this (as PFC or any other) framework as a part of the application.

Q. Are there special browser requirements for the resulting Java application (e.g. must use IE?)
A. We tested our solution in IE6 and above and in Firefox 3.0 and above.

Q. What is the nature of manual adjustments of the converted application?
A. Some PowerBuilder features or objects can not be directly converted to the target code. For example, passing method parameters by reference in Java, nulls for primitive data types, some default data type conversions (PowerScript is much less restrictive than modern languages, it allows, for instance, assignments between char arrays and strings), "goto" statements etc. Also some objects should be changed because of the architecture change (thin client instead of rich client).

Q. Is there any possibility for any type of functionality to be lost in the transition from PowerBuilder to Java or .NET?
A. Our modernization projects are built such that no functionality is lost in the migration process. If any functionality is not supported on the target platform, it can be replaced with some equmanager/htmlivalent functionality. For example, if your application uses text editing in rich-text format, this functionality can be replaced with html editors available for thin-client platforms.

Q. Does the PB application need to be well-partitioned before the migration (business logic in NVOs, window or control scripts)?
A. Some cleaning-up might be required before the modernization, though not significant.

Q. How does the migration work for Rich Text edit controls in PowerBuilder?
A. As a part of manual adjustment we can replace rich text edit controls with thin-client html editor controls. Another solution can be implementing some document management system which will allow you to edit the documents locally and then submit them back to the server. We will advice on the correct solution architecture after learning your application.

Q. Narrative in rich text format - write long detailed narrations for multiple users to store as "text" data type in the application's database. Retrieve large amounts of data from a text field into a control for display.
A. If the data stored within a text field is really large, we would recommend to implement some sort of "document management" system, where the server prepares document from the database fields and supplies the client with a link to download it, and then the document can be uploaded to the server. The more complicated solutions with hidden download/upload or with in-place editing documents via a hyper-reference link can also be provided. The correct architecture depends on the maximal size of the narrative texts. If it does not exceed, for example, 70Kb, it can be edited in html editors (with larger content html editors may eat too much browser resources).

Q. What is your plan to convert 3rd party controls such as Spell Check (e.g. JRSpell or Microsoft Word)?
A. Those services can be implemented as server-side services, or as a part of the document management system.

Q. How do you go about converting external windows API calls?
A. The strategy is to have all the functionality on the server side. How to perform this task efficiently depends on the application itself. We will advice what to do after learning of the application.

Q. Do modal windows work in the resulting application?
A. As the resulting application is a thin-client application, there are no really "modal" windows. Usually the functionality is reworked such that all the other "windows" opened in the browser environment, except the "modal" one, are prevented from regular user interaction (clicks, typing), and the appropriate server-side solution implemented to allow returning to the point where a modal window was called from.

Q. In your experience with large conversions, do you usually have a percentage of functionality that will not work in target platform? Does this require detailed discussions with the customer about how they will change their business processes?
A. Some functionality which significantly differs in thin-client and rich-client applications may change user experience. Therefore it is better to discuss the user experience change with the customer. But anyway the percentage is functionality from the source application which is not present in the target is very small and not significant.

Q. If a popup window has a large nested tree structure and the calling window displays information resulting from the modal window, will the calling window be updated when the modal window is closed?
A. The question here is not a size of the modal window's tree view control, but the amount of data passed from one window to another. Anyway, the architecture of the converted application implements server-side relationships between objects, that is, this modal window submits its data on the server side, than this data is passed to the server-side representation of the calling window, and it refreshes with the new information.

Q. What is your migration path for DataWindow Objects?
A. We have different models for Java and .NET target platforms.
In .NET environment we use provided by Sybase DataWindow .NET control, that is, we preserve all the existing flexibility and power of the DataWindow technology.
In Java target environment we have our proprietary framework, which we call JDataPanel framework. This framewok is similar to DataWindow technology, though not identical to it. For example, a DataWindow is a bundle of 3 layers in one object - data source access, presentation and some business logic. While converting DataWindows to Java target, we produce 3 different objects - an xml file with ".dsd" extension, containing data access layer definitions; an xml file witn ".jdp" extension, containing presentation layer definitions; and a Java class containing business logic - properties, field validations on the DataWindow level etc. To easily work with xml definitions for data access and presentation layer definitions, we provide our clients with appropriate graphical designers.
For both models our goal was to allow clients to preserve their existing PowerBuilder maintenance teams (as those developers know the existing business domain application architecture domains well) with required training just to know the target platform - Java or .NET.

Java-target Specific Questions

Q. What versions of Java EE are supported?
A. The lowest requirement is that the server-side supports Servlets and JSPs. That is, any Servlet/JSP container, such as, for example, Tomcat, can hold the resulting application.

Q. Are generated business objects POJOs or EJBs?
A. The generated business objects are simple Java classes and can be considered POJOs.

Q. Will the resulting JEE application use Java Enterprise Edition standards, such as JSF and JPA? Will it use any specific frameworks (e.g. Struts, Spring, etc.) or persistence layer (e.g. Hibernate)?
A. The resulting application implements a "Dispatcher servlet" architecture (very similar to the one used by Spring MVC), and therefore can be easily integrated with Spring framework. PowerBuilder's DataWindow objects are divided into 3 kinds of object - Data access layer objects, Presentation layer objects, and business logic classes. Data access layer objects can be adjusted to use some persistence layer in the background.
Hibernate data store adapter can be provided automatically, and Spring integration is a part of manual adjustments.
Hibernate platform can be used as a data source adapter for our DAL objects (DataStore objects). Some background: the best thing in PowerBuilder is its DataWindow technology, a very powerful and convenient technology, which brought most of the gained by PowerBuilder success. Generally, each DataWindow object has its DAL, some of business logic and presentation layer definitions. Not a good thing is that all the layers within a DataWindow object are tightly coupled. During the conversion we split these layers to 3 parts: an XML file, representing DAL definitions (a ".dsd" file), an XML file, representing presentation layer definitions (a ".jdp" file), and a Java class, containing business logic and binding DAL and presentation layer together. DAL objects - DataStores in our terminology - can access data storages (data bases, XML files etc.) with a mechanism of different DataStoreAdapter classes - DataStoreAdapterSQL, DataStoreAdapterXML etc. If required, the set of adapters can be extended. For example, it is possible to use "DataStoreAdapterHibernate" class.

Q. What DataWindow styles are supported?
A. Tabular, Freeform, Grid, Group, Composite, N-up and Label styles are provided as out-of-the box solution. Crosstab, Graph, RichText and TreeView styles can be emulated with some manual intrusion. OLE style does not exist in a thin-client environment.

Q. Are nested DataWindows supported?
A. Yes. More than that, if in PowerBuilder nested DataWindows are not editable and used for reports, in JDataPanel framework nested levels are also editable. JDataPanel framework provides hierarchy of "JDataPanelGroup" objects, and each level of this hierarchy can be considered as a DataWindow equivalent.

Q. Are expressions on DataWindow attributes supported?
A. Yes. All expressions - both on computed columns and attribues - are converted to Java classes.

Q. How are DataWindow edit styles and formats handled?
A. They are converted to appropriate JDataPanel definitions.

Q. Are listener interfaces defined for all commonly used DataWindow control events?
A. Yes. We use JDataPanelListener classes to handle JDataPanel events.

Q. Are Swing components used? Is there also a JSF implementation for the web, or are applets generated?
A. No Swing componens are required for the thin-client environment, and no applets are generated. The produced components (Dispatcher Servlet, JSPs and Java classes) generate pure HTML and send it to the brower environment.

Q. What is the learning curve for the resulting framework? Do you have some documentation on the resulting framework?
A. We will provide training for your development team to get familiar with the resulting framework and the converted application. Usually it is a 3 to 5 days of training. Training materials are also used as a reference documents for the framework. In addition the framework is supplied with "open code" pattern.

Q. We looked at the generated sources and did not find a "main" method.
A. The converted classes are ignorant about the framework they will be working within. A simple framework, which we provide with the converted application, contains a dispatcher servlet, which passes requests from clients to ApplicationManager class instance. This object dispatches the requests to appropriate converted objects. The result is or pure html (in case the client window is to be opened or requires "redraw" ), or an Xml response to AJAX requests. Such an architecture allows us to build our solution within almost any framework. For example, in Spring framework the ApplicationManager class can be defined as a session-scoped bean. Such adjustments are a part of the manual completion.

Q. How does one make use of the DAL and presentation XML files for further Java development?
A. These files can be edited (or created in case of new files) with our JDataPanel builder tool (or even with a text editor, if somebody wants to). The tool is provided with the modernized application as a part of the supplied framework.

Q. In your site you mentioned that after automated migration you would be providing training to the customer's resources. What kind of training is it and why is it required.
A. The customer developers should be aware of what is the architecture of the converted application and how to use our JDataPanel framework. Usually 3 days with 6 hours-length training sessions are enough to understand the point.

Q. We had discussed about the proprietary libraries used and you had mentioned that only proprietary library used for Datawindow and rest of the PB features are in java, which would have complete source. Correct me if any other PB features added on proprietary libraries usage.
A. It is correct, the most of the proprietary libraries are JDataPanel + DataStore frameworks, which support converted DataWindow technology. The other part is a simple "control layer" framework (a front-end servlet and ApplicationManager classes set, some JSP and JavaScript files), which can be provided also with sources. In case of Spring utilization only a part of this framework will be implemented. Instead of a servlet with some supporting classes (a part of our out-of-the-box simple framework), which receives all the client requests and then calls service from ApplicationManager instance, the Spring framework will have this ApplicationManager instance as its session-scoped bean.

Q. How do you preserve your clients ability to independent maintenance of the converted Java applications?
A. We can provide sources for our run-time libraries under an open source license, thus the sufficient level of transparency will be secured and dependency eliminated.

Q. Can we use IBM Rational Application Developer 7.5 to maintain the resulting Java application?
A. Any Java IDE can be used to maintain the resulting application.

Database-related questions

Q. Do you have a solution for remote synchronization with Sybase Adaptive Server Anywhere that will work in Java?
A. Sybase proposes MobiLink as a session-based synchronization system, that allows two-way synchronization between a main database and many remote databases. This solution does not depend on the environment in which your applications are built and can be implemented separately from the applications. We can help you to use MobiLink system, or to build an application-specific replication system in Java - whatever suites best to your requirements.

Add this page to your favorite Social Bookmarking websites
Digg! Reddit! Del.icio.us! Mixx! Free and Open Source Software News Google! Live! Facebook! StumbleUpon! TwitThis Joomla Free PHP