Project

General

Profile

Conversion Process and Technology

What inputs are required by the conversion process?

Please see Gathering Inputs.

How does the conversion process work?

A summary can be found in the Conversion Process Overview.

What manual preparation is required for the conversion process?

The following are required:

1. A "conversion project" must be setup/configured, see Project Setup. Initially, you should focus on getting the entire application parsing without errors. For details, see Resolving Preprocessing Issues, Resolving Parsing Issues and Parsing Object Oriented Classes and References.

2. After you have the application parsing successfully, you should run the standard reports (see Reporting). In addition to giving you a very deep look inside ytour application, you can use the gap analysis in these reports to identify ABL areas that aren't supported in FWD or which may need (or just benefit from) editing.

3. Depending on the ABL features in use, some ABL code changes may be necessary before conversion, see Code Preparation.

4. If there is missing support in FWD for features that are required for your application, that support should be added to FWD. You can do this and/or Golden Code can do it for you on a fee basis.

5. It is recommended to establish a certification baseline, if you do not already have one. This is a suite of certification testcases that can be used to prove that the application is working properly. Over time it can also be used to detect regressions as changes are made to FWD or to your application code. Automating execution of this baseline is very important and will yield many benefits over the lifetime of your application. Golden Code can help you with test automation if necessary.

6. Build the target runtime environment's configuration. The distributed application environment has required runtime configuration values such as networking addresses, digital certificates for encryption and so forth. Details can be found in the Installation Configuration and Administration Guide.

Optionally, you may wish to leverage these facilities:

What manual source code modifications are required after the converted code is generated?

None.

The result of the automated conversion process is a complete Java project that can be built (using Apache Ant or the equivalent) into one or more jar files. After the project is built, the server and clients can be started and used immediately.

All manual steps are handled in preparation for the automated conversion. Absolutely no editing of the result is ever needed to attain a compatible result.

How long do conversion projects take?

The majority of the time in conversion projects is consumed in two areas:

  • The manual preparation needed before the full automated conversion process can be run. See this for the details.
  • The testing needed to ensure that the result is identical.

For some applications (smaller ones or ones that don't have a great variety of code needed manual preparation), these two areas may be measured in days or weeks. For very large applications, these would be measured in months.

The actual time it takes to run the automated process (for the entire code and schema conversion process end-to-end) is usually measured in hours. Here are representative examples:

Size Batch Run Time
Small (800KLOC) 1.5 hours
Medium (5MLOC) 4.5 hours
Large (14MLOC) 10 hours

Interestingly, while the conversion of an entire large application (in a single batch) can take hours, the conversion of individual source files takes seconds to minutes depending on the size and complexity.

The data migration of each database instance will depend on database size (number and size of the records). The time is usually measured in hours for real production databases.

Could you use these same tools to transform, re-factor or modernize a 4GL application?

At a minimum, you can leverage the Reporting and the Call Graph Analyzer to understand your application in ways that are not easily possible otherwise.

To use the automation capabilities to handle transformations is possible, but the tools for automating some of the process are not yet created. The primary issue is that a Progress ABL "anti-parser" would need to be made and rules created to handle the improvement of the Progress 4GL abstract syntax trees would have to be extended to create new Progress 4GL syntax trees with the new refactored structure. The anti-parser is the real effort, because it must reflect changes back into include files which are not valid ABL syntax.

What re-factoring is done during conversion?

User interface (UI), business logic and database access have been separated as much is possible without breaking compatibility with the original application.

In the case of the user interface, all static elements of a frame definition are identified and removed from the business logic. These elements are combined into a single, separate frame definition (a Java class) that includes such things as which widgets are in use, their locations, sizes, format strings and all other static configuration for the frame. The business logic still must execute things like the Java equivalent of DISPLAY because this is necessary for the application to behave properly. In other words, there is usage of the frame in the business logic because the flow of control of the application requires it. While the analogy of Model-View-Controller (MVC) is not exactly correct, it is a fairly true statement to say the the business logic is the controller and the separate frame definitions are the views. So a statement like DISPLAY does only 2 things in the Java environment: it copies data into specific widgets and it makes that data visible on the screen. All of the other features of DISPLAY (related to defining the layout and formatting of the user interface) have been moved out of the business logic. All UI processing has been handled in this same manner. Any UI definitions that are stored in the schema are honored as well (if in Progress they would have been honored). There is no UI processing or dependencies in the resulting database schema at all. In fact, the generated frame definitions have no knowledge or dependencies on the database structure, even if a given widget is normally backed by a database field at runtime. Only the business logic has any connection to either the UI or the database (as noted above, it is the controller in MVC terms).

Database access is another example of re-factoring. Each database table has an object representation which represents a row in that table. For each field in the table, there are "getter" and "setter" methods. The object-to-relational mapping (ORM) is provided by a combination of Hibernate and the persistence portions of the runtime which Golden Code Development created. The table-level objects are called Data Model Objects (DMOs) and these are generated for the target relational database schema. Hibernate and the Golden Code Development persistence layer transparently handle the linkage between these DMOs and the data in the database. The business logic does define queries needed to obtain instances of the DMOs. Likewise the business logic does get and set the values of fields as necessary. Again, the data access was separated as much as possible without breaking compatibility.

Some refactoring of the schema occurs as well. For example, database fields with extents are re-factored into a separate (related) table and the multiple values are stored as rows. In other words, there is some normalization of the database schema. Note that this is completely transparent to the application.

Optionally, you can refactor the security and configuration aspects of the ABL application. Since there is no comprehensive and/or standard security/configuration model built into Progress 4GL, each application has a custom approach. There may even be multiple security models in use in the same ABL application. Part of the conversion methodology allows custom rules to convert the application-specific security model into a standardized FWD security model. As part of this, all of the security (users, groups, resources, rights, ACLs...) and other configuration data are migrated into the centralized directory (it can be LDAP or an XML back-end). This makes maintenance and support significantly easier over time. By default, this extra refactoring is not done and it is a non-trivial effort to implement. But if it is important, it is very possible and the results are excellent.

What code improvements are done during conversion?

The following is a partial list:

  • Abbreviations are removed.
  • Dead files are identified and removed.
  • Unreachable code in live files is removed.
  • Some duplicated code is removed and replaced with a single implementation (of a class or method) used from multiple locations.
  • Certain expressions are rewritten to be simpler without changing the calculated result.
  • Where there are multiple mechanisms in Progress 4GL for doing the same thing, these are mapped to a single standard approach in Java.
  • Progress ABL code that is live (it executes) but which is effectively a NOP (no-operation), is removed.
  • "Dead" options on language statements are removed. These are keywords that are tolerated in the source but for which no change in behavior occurs (they are ignored in Progress).
  • Block properties, scoping (e.g. frame, buffer, transactions), index selection and other hidden (and often confusing) behavior is now made explicit. This improves readability and reduces risk and effort in maintenance.
  • The generated code has a consistent and clean format throughout.

© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.