How Sofrepost modernized their commercial PowerBuilder applications

Sofrepost is a subsidiary of La Poste (the French mail). They develop and sell SPS, a management system for post offices. Their clients are national postal systems from a dozen countries on several continents.

SPS is composed of 5 packaged applications, developed with PowerBuilder, representing around 150 Mb of code, 400 windows and 1200 DW.

The initial development of the application took place in 1996 and required approximately 10 man years. The application has since been regularly modified to extend its functionalities.

More recently, the requests of their clients have led Sofreport to study solutions to modernize this system, with three main objectives:

  1. Web migration: the clients wish to lessen the deployment costs to their many post offices. They also need to offer access at a distance, in particular for the use of financial services, via a simple web browser.
  2. Makeover: over the years, presentation standards have evolved. They therefore need to redesign the graphic interface to give it a new, modern look.
  3. Flexibility: the more the functionalities have been extended, the more difficult it has become to provide an application that exactly responds to all needs. Clients have regularly asked for adaptations. The first requests were dealt with by modifying the code, but that resulted in the later need to maintain multiple versions of the application. It became necessary to make the application flexible and configurable so that clients are able to adapt their copy without needing to modify the code.

Original Application
The original appliation, developed in PowerBuilder

Which strategy?

Sofreport first needed to choose a strategy and technical platform:

  1. Redevelop the application: writing a web version of the system would probably take place in Java or .NET and would require several years and a budget of several million Euros. This strategy would also risk failure tied to the adoption of new technologies and the considerable length of the project.
  2. Adapt the existing application: staying with PowerBuilder presents fewer risks, but it will also require specialized solutions to attain the objectives listed above. After study and confirmation, this is the strategy we adopted.

 

Which tools?

Web migration:

The applications were web-deployed with Appeon for PowerBuilder.

  • They were first modified to be compatible with this tool : certain unsupported PB functionalities were replaced by others
  • Of the 5 applications in the system, 3 needed to be migrated to the web. Each migration took approximately 3 months.
  • Migration was done once and for all: Appeon includes a tool that will guide our developers so that all future development in PB includes only the functionalities supported for web deployment. The next versions of the application can therefore be developed in PB and the next web deployment can be performed immediately, without requiring additional changes.

Makeover:

The user interface was adapted to the new style guide:

  • Certain modifications were performed with PowerBuilder
  • Others were done with Customization Studio: they were first saved in a repository, and then automatically applied to the source code. This process allows all changes to be saved in an independent repository, to then be applied to other copies of the application adapted for specific clients.

Flexibility:

  • Customization Studio was integrated into the application to render it entirely configurable. The users can modify screens and reports directly from the executable version of the application.
  • Reduces cost: integration required a few hours of work. The customization will be done by the clients according to their needs. There is no license cost for the company: clients using this tool will purchase an OEM license.

 

Results?

Web migration:

Users can access the application via a web browser. They find the same as the client/server applications. Response time varies according to the transactions from 1 to a few seconds.

Makeover:

The functionalities are the same, but the application’s style has change (see the screenshots)

Flexibility:

Clients can now customize the system themselves, reorganizing screens or adapting reports. They define these modifications on an executable version of the application, without accessing the source code. The changes are stored outside the application and can easily be deactivated if there is a problem.

Updated application
The updated application in client-server

Web application
The updated application deployed on the web with Appeon

Conclusion:

Strategy: the choice to adapt the PowerBuilder application, rather than to develop it in another technology has proved to be worthwhile: all their business objectives were achieved for a fraction of the cost of a redevelopment, with a timeframe of several months and a significantly lower risk of project failure.

Recommended for all PB projects? Not necessarily. It will of course depend on your objectives and technical constraints. If you want an opinion on this subject, you can contact Novalys, who were responsible for the success of the project.

Key figures:

Application Size Application Type Migration Time
Back Office
Application
50 PBL, 45 MB,
700 DW, 200 Windows
MDI application, with many input windows and reports 3 months
Front-Office
Application
30 PBL, 25 MB, 150 DW Includes a very complex window with many tabpages and DW 3 months