Figure 1: RPG programs often take and receive aggregate data.

Figure 2: A properly encapsulated JavaBean makes invoking RPG from JSP easy.

Figure 3: The code within a JSP should present information, not manipulate it.

Figure 4: Each RPG program you access from Java should be encapsulated with a JavaBean.

To access the RPG program, a JSP merely has to create the mc.Rpg001 JavaBean, invoke the call method (passing the required input string, decimal, and date arguments), then retrieve the output parameters with four getter methods: getOutChar, getOutDate, getOutDecimal, and getOutArrayOfDates. That's the way it should work. The JSP itself should not contain the complex code required to invoke the RPG program. If it did, other JSPs requiring access to that RPG routine would have to contain similar code. And, to include such complex code in the JSP, the developer would have to be knowledgeable about RPG programming.

The Bean Interface

Though the JSP code is trivial, the JavaBean shown in Figure 4 is moderately complex and, therefore, requires a more in-depth explanation. I called my RPG JavaBean Rpg001 so it would have the same name as the RPG program that it wrappered. The JavaBean's constructor establishes a JDBC connection. It then creates a CallableStatement object to invoke the RPG via the Connection object's prepareCall method:

The string argument passed to the prepareCall statement qualifies the name of the stored procedure that wrappers the RPG program (which I'll explain later). It then lists the seven arguments required by that procedure as question mark (?) placeholders. One requirement for using stored procedures in Java is that all output arguments must have their datatypes registered with the CallableStatement's registerOutParameter method:

Note that the number 5 correlates to the fifth question-mark placeholder in the string passed to the prepareCall method.

The prepareCall method would not have worked if I hadn't earlier created the stored procedure, shown in Figure 5, with interactive SQL.

Figure 5: SQL stored procedures can be created to wrapper access to an RPG program.

Of that stored procedure, all parameters but the last are self-explanatory. That last argument is to store an array of 10 dates, but SQL doesn't support arrays for procedure parameters, so I had to stuff them into a string of ten 10-character values. (RPG dates are stored in the CCYY-MM-DD format).

The Call Method

To make it easy to invoke the RPG program, I created a call method that takes the three parameters required by the Rpg001 program: a 10-character field, a 10-digit packed field with no decimals, and a date. The associated Java datatypes for those three fields are String, BigDecimal, and Date, so the prototype for the call method is as follows:

The Rpg001 class's call method then uses setter methods to insert the passed parameters into the values required by the CallableStatement. The decimal argument, for instance, is set with the following setter method:

Note that the number 2 correlates to the second question-mark placeholder qualified in the prepareCall method. Once each of the three input arguments is set, the CallableStatement's executeUpdate method is called to invoke the RPG program. When the RPG routine is completed, the return arguments are retrieved with the
CallableStatement getter method that correlates to the appropriate datatype: getString, getDate, or getDecimal. For instance, the decimal return value was retrieved with the following method call:

Note, once again, that the number 5 correlates to the fifth question-mark placeholder.

After the three atomic values were set, the Rpg001 class's call method had to convert the 100-character string into 10 dates. The code looks a little complex, but, with the help of the String class's substring method and the Integer class, I was able to reconstruct the 10 dates from the returned string.

The Bean API

The Rpg001 JavaBean contains a simple API: a call method and four getter methods. The call method takes the input values required by the RPG program, and four getter methods contain the RPG program's return values. The JSP author--whom I hesitate to call a programmer, because he may be a Web developer with little or no programming expertise--is able to easily use that API without implicit knowledge of the RPG program.

There is a caveat, however, with the strategy shown in this article. The RPG program runs in the same job as the JSP, that of the Web application server. This means that if 100 Web-browsing users access Rpg001.jsp, 100 users are hitting at the same RPG program instance. For this itty-bitty RPG program, that may not be much of a problem, but with more robust programs, you may experience a performance bottleneck.

You can avoid performance bottlenecks by using data queues to communicate between Java and RPG. The RPG program reads the input parameters from a sequential data queue and then places the response to a keyed data queue. The Java application writes a request to that sequential data queue, with a unique number (such as the HttpSession number), and then reads the RPG's response from the keyed data queue, using that unique number. The RPG data-queue server is launched as a batch job, and, if it becomes overly taxed, you can simply launch again and have multiple RPG servers handling the same data queue.

Don Denoncourt is a Java consultant, trainer, and mentor. He is author of Java Application Strategies for iSeries and AS/400--Second Edition, co-author of Understanding Linux Web Hosting and editor of iSeries & AS/400 Java at Work. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..