The Company

Articles

This article describes a strategy to migrate OpenEdge (Progress Software) applications, e.g. from CHAR UI to .NET UI, or classic OpenEdge UI to HTML5 UI. This method is known as ‘Soft Migration’, ‘Step-by-Stop Migration’ or ‘Soft Transformation’. The description uses OF-1 as example, but it is not bound to OF-1, it can be used with all OpenEdge development systems.

Today often the main target of a modernization project is web (or mobile), that means mostly HTML5. The big bang approach approach is dangerous for this scenario: You need to develop a new application and maintain the existing one at the same time. The soft migration strategy allows to release versions during the transformation process. It allows the application renewal during ongoing work, accomplished by the staff which does the maintenance.

Soft migration uses unique features of OpenEdge and the Framework OF-1. OpenEdge allows to mix legacy code with the brand new type of code (like OO). OF-1 has the ability to integrate existing screens in the main desktop and it has multi-UI capabilities (.NET, HTML5). During the migration phase old and new screens (programs) co-exist, until all relevant parts of the application are renewed.

Step 1 – Integrate ‘old’ programs in desktop / menu

In this initial phase the existing menu system will be integrated into the menu OF-1. The entries will be loaded into the OF-1 repository. The program starter from OF-1 will be modified, so that it knows the way to start existing programs. The result is that existing programs can run in OF-1 desktop, like this example.

Old style program runs in new application desktop

Step 2 – Renew programs

Program by program should be renewed and replaced by an OF-1 screen. Usually large parts of the screen logic and the business logic could be reused. The big advantage is, that the application can be deployed to the customers! Some screens are new and some are old.

Framework stucture

2.1 – Business Logic

The business logic will be bundled in Business Entities. As this migration is a sustainable migration, the process starts with creating Business Entities with PCase, the OpenEdge Case tool. Existing code will be integrated and enhanced to modern OO Business Entities.

2.2 – Screen Logic

Screen logic will be integrated into the client hooks. All database related code is removed and integrated into the Business Entitites. Usually the resulting screen logic code is much smaller than before.

Adress program renewed with mutiple subviews

2.3 – Standard data programs

The standard data programs often only need to be painted in OF-1 and then they are ready. So these programs could be migrated by trainees or students – it is just a bunch of simple work.

Step 3 – Add features

Additional features will be added, depending on the project scope. When the target UI is the web (HTML5) then these features must be able to work in the web. Functional solutions are avaialbe for al of these features: (Cloud) Printing, TAPI integration, , office integration, webmailer, Workflow Engine, Corticon integration…

Desktop with new type-by-find search in multiple areas

Step 4 – Run application in the web

When the programs (or most of them) are migrated, then the application can be used with both UIs: .NET and HTML5. So the application can be sold as on premise solution and as a SaaS (Software as a Service) solution.

Advantages

Ability to release during migration

Good Business Entity (AppServer) as result

Small extra budget needed

Only ABL (OpenEdge) skill set needed

Multi-UI / SaaS ready when done

Disadvantages

Screens look different during migration

Limited flexibility during project

Summary

The Soft Migration strategy allows to migrate an OpenEdge Application during the normal maintenance and application enhancement cycle. It can be also accomplished with a small budget, then it will take longer. Experience and expertise from various projects is available, to help to make the project a success.

On September 8th IAP is celebrating their company anniversary of 25 years. For that event IAP is organizing technical workshops in the IAP office and in the evening a big celebration party at the beach club Del Mar.

Over the day, there will be live demonstrations of OF-1, a discussion of OpenEdge migration possibilities, also a Progress business update and in detail discussion of tunig possibilities to make OE-applications faster. During the presentations, there will be the opportunity to talk with our programmers and consultants for further discussions.

The day will end with a big celebration party at the beach club Del Mar, directly at the river Elbe. At this weekend the Hamburg Cruise Days will take place, so the whole port will be full of ships and is blue illuminated.

PCaseis the leading Case Tool for OpenEdge. The user can extend PCase with macros. These macros are ABL programs, mostly used for code generation or data import and export.

PCase comes with a bunch of predefined macros, these can be used as examples.

This article describes how to join a project (OpenEdge Architect / Studio) with PCase, so that everything for macro development is ready. For preparation PCase must be downloaded and installed for the version of OpenEdge which will be used for the work.

The screen-shot shows a typical macro usage situation, where two tables are selected and the little green wheel in the upper right is clicked and a wizard shows the table macros – which are default macros of PCase.

To develop and add user macros from an OpenEdge project to PCase, PCase and the project must know each other:

Add PCase classes to OE project, so that a project related macro can inherit PCase classes and call PCase functionality.

Extend PCase macro search path, so that PCase can find the macros in the Studio / Architect project.

SHOW THE FULL BLOG POST

Add PCase classes to a project

When PCase is installed with the default settings, then PCase ist installed in the OpenEdge installation directory. PCase has an independant ABL run time, so an Eclipse (Architekt / Studio) project does not know anything about it.

OE Installation:

d:\dlc\113

PCase base directory:

d:\dlc\113\oeide\eclipse\plugins\de.iap.t4p_2.1.0\PCase

Macro directory:

[base]\macros

Step one: Add the PCase DB read only to the project:

Open project properties

Go to Progress OpenEdge database connections

Then go to “Configure database connections”

Add a new one, call it like “PCase DB RO”

DB: D:\dlc\113\oeide\eclipse\plugins\de.iap.t4p_2.1.0\PCase\db\t4p.db

Other Parameters: -RO

(That’s it, no SQL connect, no autostart)

Save DB and add it to the project

Read only mode is used, because the PCase DB is usually open in single user mode from PCase and the user project should not write into the PCase DB.

The PCase directory is used for direct accessing PCase resources. The PL (Procedure Library) file contains the PCase programs (classes). The macros may access these, e.g. when using a wizard.

Extend PCase macro search path

During start PCase scans the file system for OpenEdge classes, which are macros. A PCase macro is imlementing a specific interface (which will be discussed in the next PCase article), and PCase is scanning for this interface.

If PCase should find the macros from the project, then the project path must be added to the PCase macro search path.This is done in the file “startup.p“, which resides in the PCase directory.

First the project needs to be added to the propath of PCase. Then PCase is able to find resources (programs, images…) in user created macros.

1

2

3

/* ke, 01 Mar 2017; Add you project path here. */

PROPATH="D:\dev\small-projects\IAP\PCase Macros\,"+PROPATH.

Second the user (OE Architect/Studio) project must be added to find macros. It is best practice to let point the search path to a subdirectory. PCase will scan all class files which are in that directory and the subdirectories – so using the root directory of a large project will produce a log of scan calls. It is possible to add multiple directories with multiple calls.

In the example below the first call is the default call, the second call is the additional for user project macros.

Eingeladen wird von dem Vorstand der PUG

The hard migration is useful, when the goal is, to migrate an OpenEdge application the fastest way, let’s say from ADM to HTML5 UI. The copy, paste and change approach keeps the work flow and logic of existing programs, so the migration risks are low.

This migration strategy is based on the unique structure of OF-1, where any source code is ABL. To program data fetching or handle user interactions – so called client logic or screen logic – you can use more or less the same code as is use in an ADM/2 or GUI Builder / Appbuilder.

Tasks to migrate a program:

Rebuild UI in OF-1, using same Widget names or similar

Rebuild UI in OF-1

Any ADM component exist similar in OF-1 (Query, Browser, Viewer…)

Copy phase

Copy Screen Logic to OF-1 Client Hooks

Copy Business Logic to Business Entities

Includes on AppServer are reused

New functionality will be added later

DMS

Workflow Engine

SHOW THE FULL BLOG POST

Phase 1: Rebuild UI in OF-1

In the first phase the UI is rebuild in the GUI builder of OF-1. This is very simple and straightforward, any ADM components have comparable components in OF-1 (besides that, OF-1 has a lot of enhanced components). When widget names are the same (or alike) the names in source program, the code will run OF-1 with very little changes.

The component classes of OF-1 have an abstract UI implementation. During run time the screen will be rendered in .NET or using the Skin-Client rendered in HTML5.

Phase 2: Copy and change logic

The application has – in a very rough view – two parts, the Screen Logic (everything manipulating the widgets) and Business Logic (everything loading, storing and manipulating data).

Any screen will be rebuild in the OF-1 Screen Designer. This could done very fast, and names of widgets should be the same as before or derived from source widgets. The Screen Logic will be reused in the client user exits (also called client hooks or client UI trigger) of OF-1. Any operation like ENABLE has a similar call in OF-1, so copy and change (search & replace) will make the old source working in OF-1. If dynamic widgets are used, they can be created in a similar way in OF-1.

The old code

1

2

3

4

5

6

7

8

9

10

11

12

13

14

/***** Old code, ADM style *****/

/* Access screen widgets */

ASSIGNvonobjekt:SCREEN-VALUEINFRAME{&FRAME-NAME}=""

bisobjekt:SCREEN-VALUEINFRAME{&FRAME-NAME}="".

CASERadio-Set-1:SCREEN-VALUEINFRAME{&FRAME-NAME}:

WHEN'1'THENDO:

DYNAMIC-FUNCTION('hideWidget':UINh_btbank_auszug,INPUT'Mobjekt').

DYNAMIC-FUNCTION('ViewWidget':UINh_btbank_auszug,INPUT'objekt').

DISABLEeinzelinvestorWITHFRAME{&FRAME-NAME}.

HIDEeinzelinvestorINFRAME{&FRAME-NAME}.

END.

WHEN...

The new code

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

/**** New code, OF-1 / OO style. *****/

/* Access abstract OF-1 component objects */

ASSIGNovonObjekt:cSCREEN-VALUE=""

obisObjekt:cSCREEN-VALUE="".

/* Attributes like SCREEN-VALUE are accessible in

OF-1 in similar attributes like cSCREEN-VALUE */

IForsWegMv:cSCREEN-VALUE="WEG"THENDO:

ASSIGN

obrw_hv_tbank_auszug_Mobjekt:lVisible=FALSE

obrw_hv_tbank_auszug_Objekt:lVisible=TRUE

ocbInvestor:lVisible=FALSE.

END.

ELSe...

The Business Logic of master data programs is literally zero! OF-1 has logic for data handling (find, udate, sort and so forth) build in – it is a core part of the framework, implemented in the system classes.
When Business Logic is more complex, it can be reused in the server side user exist (also know as server hooks, or AppServer trigger) of OF-1. A Business Entity will be created for any screen of medium or high complexity level. Existing code will be reused and include files will be also reused. Due to the approach to be fast, only minor changes will be done in Business Logic.

Phase 3: HTML5 and new functionality

When the application is completely transformed into an OF-1 application, it runs as .NET UI application or as HTML5 in a browser. New functionality will be added when the project is stable.

The old application:

Rebuild UI in OF-1 (Phase 1):

.NET UI application or in browser as HTML5 (Phase 3):

Advantages and Disadvantages

Advantages

HTML5 UI – Address the SaaS market

Fast – Fastest known migration concept

Simple – A trainee is able to build screens and copy/change simple to medium logic

Low risk – The working application is rebuild

High user acceptance – User can go on working with a similar application

Improved application – OF-1 hast a lot of build in functionality, which is active

Disadvantages

Same workflow – Workflow and screen enhancements are done later

Code not better than before – Everything if OF-1 is OO, but in general code stays the same

Many Business Logic classes – Simplification process can start after migration

Summary

The unique structure of OF-1 allows to reuse existing screen and business logic with copy and change in the fastest possible way, to bring ADM style OpenEdge applications to .NET or HTML5.