Rather than rewrite older business applications, consider using a method such as APIs, stored procedures, or UDFs to access legacy app functions
By Laura Ubelhor and Christian Hur
Making the decision to include Web applications as part of your business systems doesn’t mean you have to scrap the applications already in use. It might make sense to leave some of these applications as they are, and only deploy select applications on the Web. Many organizations already have applications in which they have invested considerable resources, time, and money. Many of these applications are stable and still well suited to the business requirements. There is no reason to rewrite all your applications unless a business need requires a change.
It’s wise to consider whether legacy code can be reused. Doing so might well affect the design, choice of tools, and framework for Web application development. It isn’t always feasible to rewrite legacy code or maintain two different versions of programs that do the same thing. If you have existing applications that include detailed and complicated logic, it is possible to include these applications without a complete rewrite. There are many ways you can reuse legacy code. We discuss a few options here.
An application program interface (API) enables one program to communicate with another. For example, an API can be used from within a PHP, JSP, or ASP.NET application program to execute and share data with a legacy application. APIs were developed in response to the need to exchange information between two or more different software applications. APIs have been around for a long time, and most systems can use them. Stored procedures and user-defined functions are two types of APIs.
A stored procedure is a subroutine available to applications that make use of a RDBMS. Stored procedures are typically used for data validation, access control, or to trigger execution of a legacy application. Stored procedures are used to consolidate and centralize logic that was originally implemented in applications. Stored procedures must be invoked using a call statement (unlike user-defined functions, which can be used like any other expression within SQL statements). Here is an example of a call statement:
CALL procedurename(parm1, parm2)
Stored procedures can be used to return data result sets or may be used as a method to initiate another application to execute. Stored procedures may also receive and return variables, making it possible to pass parameters between the Web application and the stored procedure. While the call to the stored procedure is quite simple, you need information specific to your platform and DBMS to create the stored procedure.
On most platforms, a stored procedure can only be used to execute SQL statements and directives. Stored procedures are cataloged in the SQL system catalog using the CREATE PROCEDURE statement. On an IBM i system, however, the rules for stored procedures are relatively relaxed; the stored procedure can be written in several languages, including RPG, COBOL, FORTRAN, PL/I, REXX, CL, and C. Stored procedures written in a language other than SQL are usually referred to as external stored procedures. External stored procedures do not necessarily have to include embedded SQL statements, and they do not need to be cataloged. Other platforms provide similar functionality. You will need to verify the platform that you are using provides this functionality.
One example of how a stored procedure can enable reuse legacy code is to create a stored procedure that executes a legacy application. You pass required parameters within the stored procedure call within the Web application. This enables you to access and use the complicated code or extensive business logic of the legacy application without a rewrite.
Figure 1 provides an example of creating a stored procedure using SQL on an IBM i to initiate running an RPGLE program. In this example, a stored procedure named MYSTRPRC is created in library MYLIB. The procedure created references the RPG program named MYRPGPGM in the library MYLIBRARY. In this example, no parameters are passed.
Step 1: Create the stored procedure on the IBM i
CREATE PROCEDURE MYLIB/MYSTRPRC ( )
DYNAMIC RESULT SETS 1
MODIFIES SQL DATA
CALLED ON NULL INPUT
EXTERNAL NAME 'MYLIBRARY/MYRPGPGM'
PARAMETER STYLE GENERAL;
Step 2: Call the stored procedure from a Web application
CallableStatement cstmt = connection.prepareCall("CALL MYLIBRARY.MYSTOREDRPROC");
Figure 1: Using a stored procedure to call an IBM i RPGLE program
Figure 2 shows another example of creating a stored procedure using SQL on an IBM i to run a CL program. This example is very similar to the one in Figure 1, except it calls a CL program rather than an RPGLE program. Also, two parameters are passed: PARMIN and PARMOUT. The call statement is from a Java program.
Step 1: Create the stored procedure
CREATE PROCEDURE LUBELHOR/HITACHICLP (IN PARMIN CHAR(120), PARMOUT CHAR(120))
MODIFIES SQL DATA
CALL ON NULL INPUT
EXTERNAL NAME LUBELHOR/HITACHICLP
PARAMETER STYLE GENERAL
Step 2: Call the stored procedure
CallableStatement cstmt = connection.prepareCall("CALL LUBELHOR/HITACHICLP (?, ?)");
Figure 2: Using a stored procedure to call an iSeries CL program
User-defined functions (UDFs) are another possible option to reuse legacy code with minimal or no changes to the code. Most database management applications with SQL roots allow the use of UDFs. Calling legacy code is not the sole purpose of UDFs, but it is one of the possible uses.
Like a stored procedure, a UDF is executed by a call statement. The main difference between stored procedures and UDFs is that a stored procedure must be invoked using a call statement, while a UDF can be used like any other expression within a SQL statement.
Figure 3 is an example of how to create a DB2 UDF on an IBM i for referencing an RPGLE program. (The syntax for other database systems and platforms will vary slightly.) In the example, an integer variable is passed and will return a 15,0 decimal value. Once created, this function can be executed within PHP, JSP, or ASP.NET.
CREATE FUNCTION MYLIBRARY/MYFUNCTION(INTEGER)
NO EXTERNAL ACTION
RETURNS NULL ON NULL INPUT
EXTERNAL NAME 'MYLIBRARY/MYUDFPROGRAM(MYPARM)'
PARAMETER STYLE DB2SQL;
Figure 3: Creating a UDF
While stored procedures can have input and output parameters, UDFs have only input parameters. An output parameter must be returned as a return value. However, just because UDFs return a single value does not mean they can’t include applications with complex logic.
Some DBMSs with roots in SQL may allow use of user-defined table functions (UDTFs). A UDTF is a UDF that returns a virtual table instead of a single value. Using a UDTF, you can return a set of values. Like a stored procedure, a UDTF allows code reuse with minimal changes, enabling you to use legacy applications in coordination with Web applications.
The create function statement in Figure 4 identifies the function name in this example, MYFUNCTION, within the library MYLIBRARY. The external name keyword specifies the ILE CL program the function calls. In this example, it is MYUDTFPGM, found in the library MYLIBRARY. The example uses two parameters: PARM1 is a character value, and PARM2 is a decimal value.
CREATE FUNCTION MYLIBRARY/MYFUNCTION ()
RETURNS TABLE (
PARM1 CHAR (10)
, PARM2 DECIMAL (5, 0)
PARAMETER STYLE DB2SQL
CALLED ON NULL INPUT
NO EXTERNAL ACTION
NO FINAL CALL
EXTERNAL NAME MYLIBRARY/MYUDTFPGM
Figure 4: Creating a UDFT
If you want to reuse legacy code within Web applications, research the possibility of using a UDF or UDTF. The syntax is usually pretty similar from platform to platform. The answer to the question “how to” likely can be found within your DBMS documentation. Which one you use is best answered after thoroughly reviewing the documentation specific to your platform. The Web is another good resource for research. UDFs have been used in many organizations for legacy code reuse. If the DBMS you are using provides for UDFs or UDTFs, you’ll easily be able to find examples of them on the Web.
Many platforms provide software applications that can be used to convert legacy programs from one language to another. Sometimes, the conversion tools are referred to as migration tools. On some platforms, the tools may be provided for free to encourage the use of newer technology. In other instances, the tools must be purchased. If you’d like to keep legacy code but don’t want to rewrite applications, it is worth researching conversion tools. The work required to complete the conversion may be done by in-house staff or by an outside service provider. Conversion may also be used to move software from one platform to another in a format that can be used on the new platform.
Conversion likely will not be worthwhile if you only need to reuse a select few applications. If you need to reuse a large system or all your applications, however, a conversion tool might well be the right solution.
About the Authors
Laura Ubelhor owns and operates Consultech Services, Inc., a Rochester, Michigan-based technology consulting company. She is an author of HTML for the Business Developer (MC Press, 2008) and many technology articles. She also helped write the COMMON certification RPG and Business Computing Professional exams.
Laura has been involved in the Southeast Michigan iSeries User group since 1988, and has served as group president for over 15 years and as lead organizer for the group’s annual MITEC conference. She is also a longtime volunteer for COMMON, the IBM i and Power Systems user group, and has spent much of her career advocating for IT professional education.
Christian Hur is an IT-Web Instructor at Gateway Technical College in Racine, Wisconsin, where he teaches courses in Web Development and Microsoft SharePoint. Christian also manages Gateway’s Ubuntu (Linux) Web server, which runs on an IBM Power 8. Christian has a BLS from the University of Wisconsin-Oshkosh and is an MSCIS candidate at Boston University.