This document is aimed at those making a GeneXus version conversion or important platform changes, as well as working with a specific technology for the first time.
Even though some general aspects are explained, focus is on the technical aspects and resources available to carry out these projects.
We must start by defining the conversion type. Sometimes, this is defined beforehand (for example, a Web module development or the conversion of an entire application); in other cases, it depends on the associated cost-benefit relation.
Therefore, we assume that there are endless possibilities. Each situation is different and depends on the solution and its design, the technology for which it has been implemented, the required technological change, etc.
Taking this into account, we define two basic criteria:
- All the information provided below is based on a conversion to GeneXus 9.0 or higher GeneXus version. However, much of this information applies to technologies from previous versions.
- Because it is not possible to cover all conversion cases, we have defined two large groups defined by the conversion scope, called "Application Improvements" and "Modernization". Within "Modernization" we focused on the most common cases.
Although the conversion cases have been separated in two large groups, reality indicates that both groups are frequently mixed, making improvements in a specific part of the solution and a total "modernization" in other parts. Anyway, the general lines apply in any case.
It is essentially about update the GeneXus version and keeping the same features or making minor functional changes (oriented towards the optimization of some processes, improvements to the user interface, etc.), keeping the same platform (language, DBMS, etc.) or making minor platform changes that affect the development (access technology, DBMS, etc.).
The database structure is maintained, possibly with minor changes (attribute length, data types, indexes, etc.)
In brief, it is about keeping the same functional solution with minor changes as far as GeneXus is concerned, such as DBMS, data types, and even the language for which it is generated, all this taking advantage of the implicit or explicit improvements of the new version.
Implicit features are those included without any intervention from the developer. For example, GeneXus 9.0 has included the use of
Ajax in Web generation. Therefore, if the solution is implemented in a Web environment, it will be able to take advantage of this technology with no intervention from the developer and with no cost, and to obtain, for example, "Field to field validation". In version 9.0 there are other
implicit features.
Explicit features are those requiring the intervention of the developer. For example, version 9.0 has included a Master Page that allows setting the framework where a Web object will be presented; this implies that the developer must define these frameworks (master pages) and set up what objects will be related to what frameworks.
The converted solution will be improved in two ways: in the final solution provided to the customer (direct benefit) and in the development/productivity environment of the group in charge of the conversion (indirect benefit).
Going back to the examples, in the field to field validation, the solution provided to the customer will be better, and will have a friendlier and more interactive interface. It will add value to the final solution, with clearer benefits for the end customer; this is a direct benefit.
In the case of master pages, the user may not notice the difference between versions and the improvements to the development environment or the solution ?for example, it requires less maintenance and has a better interface, etc. This will not affect the end user directly, it is an indirect benefit.
The conversion scope will be defined by the project leader, by considering both dimensions: one related to the cost (implicit and explicit) and one related to the benefit (direct or indirect). This person will also define the minor changes mentioned before.
Lastly, there are four more points to be considered regarding costs: training, compatibility, testing and implementation.
These aspects are dealt with in deeper detail and in relation to some characteristics of the solution here.
This conversion type is typically defined by important changes at architecture or functional level, such as the Web conversion of the entire application or part of it.
Functional changes cannot be generically defined beforehand; therefore, this document is focused on technological changes. Most of them imply functional changes, such as the scope of a function or user interaction with the application. For example, the use of GXquery for reporting is a technological change, but it is also a functional change.
This conversion type provides more direct or indirect benefits (according to the previous definition), and many times it implies a technical or functional system reengineering, which results in higher conversion costs.
Usually, these conversion processes are not isolated but combined; this is also part of applying the general criteria to each specific case.
The variables (solution, change to be made, etc.) make it impossible to provide a guide for each specific case; therefore, we apply the above mentioned criteria, which is to follow the most common cases of technological changes.
In this sense, we define the following cases: