arch-09: transforming a complex application apprise® is a registered trademark of apprise software,...

ARCH-09: Transforming a Complex Application Apprise® is a registered trademark of Apprise Software, Inc.

TranscendixSM is a service mark and trademark of Transcendix LLC© 2005 All Rights Reserved

Transforming a Complex Application(ARCH-09)



Outline

• Why convert?• Goals of converting• Follow-up projects• What are the choices when converting? • Dynamic or static screens?• How could converted code work?• Code and screen samples• Questions



Why Convert?• All the things you have heard at

Exchange already• Progress client server applications are

beginning to look stale which affects the sales cycle

• System wide features that we wanted to add

• Localization • New form factors• Ease of deployment



Goals of Converting• Technology will change - it shouldn’t be as

hard next time• It should look like Windows• It should act better than Windows • It should provide a platform for the future• It should make system wide changes easier• Localizable



Goals of Converting• Customizable• Thin client architecture• Ease of deployment• Consistent user experience



Follow-up Projects• Localization • Regionalized• Service Oriented Architecture (SOA)• …



Conversion Options• Total rewrite

– Take a team of people and develop a new system from scratch using your old system as a guideline

• Screen by screen– Take a team of people and go from the first screen to

the last screen and convert them one by one

• Conversion tool– Take a team and develop a way to convert your code

from the way you have it to the way you want it programmatically



Total Rewrite• Pros:

– You get to use the latest and greatest technology and you don’t need to worry about what you already have

– Few limits except your budget

• Cons:– The team is going to work off a code base and feature set and

unless you plan on stopping new development on the existing software you end up with two products with different feature sets

– The new application generally ends up much less feature rich than the old one for a long period of time

– Time to market– There is a very high probability of project failure



Screen by Screen• Pros

– Provable milestones– Can have a staged release

• Cons– Development needs to stop on the old module while

converting or need to retrofit new work– As the standards evolve for the new product you need

to revisit the already converted code and update it – Will have a mutated product to sell for a while



Conversion Program• Pros:

– The conversion can be run often, resulting in little loss of feature development on the old application

– As the standards for the new system evolve and improve, the process can be rerun allowing fixes to the conversion utility which will fix the rest of the system

• Cons:– This takes the longest amount of time before you can

show the first couple of screens.



The Other Conversion Choice• Dynamic screens vs. Static screens

– Static screens:• Faster load time• Use standard tools to modify (Visual Studio)• Harder to upgrade next time

– Dynamic screens:• Easier to allow user customization• Easier to replace next time• Enforces standards /allows changes to standards better• Simpler Globalization configuration• Simpler look and feel• More options



How Would It Work?• There are 3 application layers

– DB server on any Progress platform– Application Server

• Progress AppServer running the business logic of your application

• No direct client interaction done at this layer• UNIX or Windows• Can be the same machine as the DB server

– Client Computer• Running on Windows• No connection to the database• No knowledge of the application at this level



How Would It Work?• Two connections

– Application Server to Client Computer• Pass requests to do work• Using standard procedures • “Update this field on the screen”• “Validate this data”

– Application Server to DB Server• All the traditional Progress db communications such as

FOR EACH, FOR FIRST, etc.



How Would It Work? (By Example)

• Setup



How Would It Work? (By Example)• User types in “motors” and hits TAB to leave the field



How Would It Work? (By Example)– The AppServer reads the changed data and updates the server

program with the new data (the category screen value is “motors” when before it was blank)

– The AppServer then translates the request (leave the category field) into a call to a procedure

– The server code runs on the AppServer which calls the database as needed

– The old code that updated the screen directly has been modified to a call that updates the request table to send back to the client

– When the procedure is done the Application server returns a list of updates to the screen that need to be processed (mark this field as sensitive, put this value in this field, hide this button, etc.)



How Would It Work? (By Example)– Finally



• /******* existing code *******/• ON LEAVE OF scr-cat IN FRAME F-Main /* Category */• DO WITH FRAME {&FRAME-NAME}:• IF scr-cat:SCREEN-VALUE <> scr-cat THEN• DO:• ASSIGN scr-cat.• FIND FIRST category WHERE• category.category-code = scr-cat• NO-LOCK NO-ERROR.• IF AVAILABLE(category) THEN• ASSIGN scr-cat:SCREEN-VALUE =

category.category-code• scr-cat• save-cat-key = category.category-key.• END.• END.

Old Code vs. New Code



Old Code vs. New Code• /******* converted code *******/• PROCEDURE leave_scr-cat :• DO : • IF get-screen-value("scr-cat") <> scr-cat THEN • DO: • ASSIGN scr-cat =get-screen-value("scr-cat") .• FIND FIRST category WHERE• category.category-code = scr-cat• NO-LOCK NO-ERROR. • IF AVAILABLE(category) THEN • DO: • RUN set-state ("scr-cat“,• "SCREEN-VALUE",• category.category-code ).• ASSIGN scr-cat = get-screen-value("scr-cat") • save-cat-key = category.category-key .• END.• END.• END.



Before And After Samples• Menu system - before



Before And After Samples• Menu system – after



Before And After Samples• EIS Information - before



Before And After Samples• EIS Information – after



Before And After Samples• Product Maintenance - before



Before And After Samples• Product Maintenance – after



Modify Screens and Logic



Add and Rename Fields



Add Dashboards



Individual Look and Feel

• Icons• Colors• Fonts• Tool bars• Screen designs



Questions?

• Jeff Broadhurst – Apprise Software, Inc.– [email protected]

• Kevin Ryer – Transcendix LLC– [email protected]

arch-09: transforming a complex application apprise® is a registered trademark of apprise software,...

Documents

new system

new development

new product

code work

old system

new workas

timedynamic screens

couple of screens