For the DataFlex programmer contemplating the rewrite of legacy applications, it quickly becomes apparent that the new Object-Oriented user interfaces, both GUI and Character-Mode, represent only a portion of the full functionality of an existing application.

Processes that run with little or no input from, or output to, the user, such as some posting routines in an accounting application or a batch import of data transmitted from some outside source, would seem to not require being rewritten to accommodate the new user interface.

The access methods for these processes, i.e., the mode of initiation, vary. A relatively short process could be a subroutine contained in the main program. Longer processes are more typically contained in separate program files that are initiated using the CHAIN command or initiated from a menu system with minimal or no user intervention. These traditional access methods are not always compatible with the object-oriented programming style.

Migrating Legacy Process Code for Use in OOP Style Programs

by Dan walsh

Is the developer faced with the prospect of time-consuming rewrites of these processes in order to deliver an updated product to his customer? While some re-coding is necessary, the answer, as presented in this paper, is no.

The questions then, are what is the method for making this transition and how long a process will it be? The purpose of this paper is to describe a relatively quick method for moving legacy process code to the object-oriented paradigm using the Business Process Object (BPO).

Presented in this paper are three coded examples of a business process that converts a quotation to an order. The first is the process in its original format. The second is a minimal rewrite in which the original code is encapsulated in an object structure, and the third, a fully converted object-oriented code segment complete with data dictionary support. This last example will also show the replacement of all obsolete coding as recently directed by DAC.

The first example shows the original code in the form of a small, self-contained program accessed using CHAIN WAIT syntax. The program is passed one parameter on the command line, the quote number or ID. It finds the quote, creates an order header record and then, in a subroutine, creates the order detail records. Inventory is updated as order detail records are created, with the Customer record updated and the quote record stamped as an order at the end of the process.

The second example shows the minimal rewrite of the original code, the "Drop & Pray" approach. This description is born of the author's experience of having to move legacy code to a newly created Order Entry program for demonstration at a trade show. The code in question had been written by another programmer and involved a reasonably complex, industry-specific process. Facing a deadline, the following approach allowed the incorporation of the process with a minimal rewrite and without the programmer needing a full understanding of exactly what the code did!

The lesson is, code that works, works. The premise is that, while there is a more accepted coding style for business processes, legacy code can, when necessary be made to work with a minimal amount programming time. The following details the steps used to move the original code to our second example. The steps can be followed in the second example code segment.

.

1. Identify the code to be converted. In our chain-wait example we simply take the original code text and rename the file. If the process in question were in the form of a subroutine, we would cut and paste the subroutine and any supporting code (variable declarations, called subroutines, etc.) to a new file.
2. Move the code into the BPO container. The Object/End_Object code lines are used to encapsulate all of the code following the file open statements.
3. Encapsulate the main process code as the "OnProcess" procedure. We identify the main process in the original code as beginning with the finding of the quote record and ending with the posting of the order number to the quote record.
4. Restate global variables as properties of the BPO or local variables of the procedures. The global quote number variable, which is used throughout the process is declared as an object property (4a). The dToday and iDaysOld variables are made local to the OnProcess and CopyQuoteDetail procedures, respectively (4b).
5. Replace any GOTO syntax. All of the error conditions that routed the code to an exit label in the original code are rewritten as Begin/End code blocks that declare the appropriate error and then exit the procedure.
6. Convert subroutines to procedures. The subroutine that creates the detail records becomes a procedure called by OnProcess.
7. Create an access method. The procedure DoCopyQuoteToOrder is created and passed the quote number by the calling program. Its function is to set the quote number property and send the DoProcess message that activates the sentinel and, in turn, sends the OnProcess message.
8. Update the Sentinel object. At key points in the process, the Update_Status message is used to appraise the user of the progress of the process.

This completes our initial repackaging. With a minimum of re-coding we have moved our legacy code into an object package file that can be "used" in any main program and accessed by sending a message that the business process object understands. Our next challenge, when time allows, is to incorporate a data dictionary structure and make our BPO conform to the same business rules we have established for our data entry objects.

Our third example moves the process to a fully converted object-oriented code segment complete with data dictionary support. Compare examples 2 and 3 through the following steps.

1. Insert a data dictionary structure. As our fictional business process is based on the standard Order Entry example, it was possible to simply cut and paste the necessary data dictionary object structure from the existing code. Assuming that the files the business process is updating are also updated by direct user entry, this "cut and paste" method will often be available.
2. Modify procedural code to process utilizing the data dictionary structure. All code that addresses the record buffers is changed to use the DDO's.
3. Remove code superceded by data dictionaries. The code that assigns an order number and updates Order Header, Customer and Inventory totals is removed.
4. Replace outdated coding methods. Data Access has stated its intention to streamline its programming language. Shown in this example are:
• Replacement of indicators with integer variables.
• Elimination of the EQ, GE, GT, LE, LT operators in favor of their expression equivalents.
• Replacement of obsolete commands.

These changes complete the migration process from legacy code to object-oriented code. In the process, we have demonstrated a method to effect a minimal, object-oriented coding style for those situations that require legacy code to become part of a new user interface but where time constraints prohibit a total rewrite.

Download

bpo.zip ~ 12 Kb