A few months ago, I wrote about the Integrated Language Environment (ILE) and told you about my introduction to service programs, sub-procedures and activation groups.  I would like to expand a little on that now by investigating how the ILE can help you implement a tiered structure on your code.

Tiering, or layering, refers to the separation of the various modules used for user interface (UI), business logic and database access. And to be strict about this, layering usually refers to the division of labour within the application code on a single machine, whereas tiering refers to the division of labour within over different machines. As I only intend to talk about using RPG within the ILE to separate the different parts of the application code running on one single machine, I may interchange the terms.

When I first started working on our intranet project, we had a consultant come in to help with our architecture and migration path from Net.Data to JSPs running on Struts. We asked at the time why there were so many different layers to the project and we were told that one of the most important things to accomplish was the separation of the different tasks within the application. For instance, we needed to have a distinct layer for database access. This would give us the ability (if it ever was necessary) to change our underlying database from DB2 to, say, Oracle if we moved from the System i to a different platform.

On top of this we had a database interface layer. This would provide the access to the database layer, but would allow us to possibly provide our solution to other members of the company who may run different databases without having to re-write all the links to our business model. 

The next layer was the EJB layer, which was initially set up to allow us to host different parts of the application on different machines to give us a true multi-tier system. However, we ended up stripping this layer out as it was unwieldy to code and it didn’t suit our future plans. It also enabled us to run a much lighter application footprint which helped speed things up slightly. This enterprise layer subsequently plugged into a façade layer which was used to isolate the enterprise layer and all layers below it from the Struts framework and is an example of one of the many design patterns used in object-oriented programming.

Finally, as I mentioned, we had the Struts framework which allowed us to build our application in the model-view-controller (MVC) style. The benefit of doing this was presented as that it provided a degree of abstraction so that we could swap out or remove tiers and the code above or below would not notice any changes. This was shown when we decided to remove the EJB layer. The limited amount of business logic that was contained in there was moved to the database layer and we were able to pare down our application to make it easier to maintain and to speed up both the development and the application itself. 

The second reason for designing the application this way was to allow for scalability. Had we suddenly become hugely successful overnight, then we wanted our application to be able to grow in size. These two factors, abstraction (or encapsulation) and scalability are apparently the cornerstones of tiered architecture and as RPG programmers new to OO programming we wanted to do things right first time round.

The idea that we could do it right by planning out all the future possibilities and covering what we thought were all the requirements was possibly a throwback to our usual waterfall or linear way of coding. In RPG-land, you started with a goal to work towards a fixed result that, with a lot of planning and requirements gathering, would eventually become a suite of programs giving the user everything they had asked for. It would be a fixed solution, working from a database that we had used for decades and that was never expected to change.

On day one, the functionality would be inscribed on stone tablets, similar to the Ten Commandments. On day two, the analyst would create documentation and everyone would view it and marvel at its accuracy. On days three to five, the coding would be given to the developers and they would be thankful. Day six would be devoted to testing and not one system test would be missed even though it was day six and the pubs were open. Day seven was usually the day for implementation and woe  betide anyone who had led to the delay of the project. 

In this respect, the world of OO programming was like someone switching on a light that slowly began to illuminate a huge room. I remember my initial Java course when we were introduced to the ideas of UML diagrams and OO analysis and design. It made so much sense in theory but my early attempts to put use cases into practice were akin to a duck practising merchant banking. However, it came to me. And then when I moved back to coding in RPG, it stayed with me. 

Recently, I have moved jobs and I have found another one of those remarkable light switches. Now, it has to be said that I view myself as somewhat of a pretender. I didn’t have a background in programming before I ended up working on the AS/400.  I haven’t got the dedication or inspiration to write my own XML parser in RPG and my article a few months ago on the ILE was my first real step towards viewing RPG as more than just an old language. But I have now started to work with some of the most intelligent people I have ever met. These people have taken RPG and applied some of the principles I encountered in OO programming to create tiered RPG applications where the possibility of change is catered for. 

These visionaries have realised that outside RPG-land there exists a whole lot more than just display files and report layout utility and that it doesn’t just involve a full-scale migration to Java and browser technology. A lot of their system is built on legacy code, like many iSeries shops, and they don’t want to lose it if they ever have to restructure. 

What makes it possible is the Integrated Language Environment. It allows business logic and database access to occur in sub-procedures within service programs and focuses on ensuring a total separation of the user interface layer from the underlying platform. If it is designed correctly, then the current green-on-black UI layer can be stripped out and replaced with, for instance, a browser front-end.

This may seem commonplace to many of you but to me it was only something I read about in System i NEWS or on MC Press. The departments I had worked at in the past weren’t capable of implementing such methodologies. The cost of re-training their developers, the planning behind reorganising their systems, the time it would take to implement these new ideas, these were all barriers that prevented me from exploring this new RPGLE-land. Hopefully, without plagiarising their ideas and without giving away any of their techniques, I would like to show you a simple ILE solution to the timeless maintenance program. 

This maintenance program is one that allows a file to be displayed within a subfile and for minor maintenance, including deletion of records, to be performed.  There are three screens: a ‘work with’ screen, a view/maintain/delete screen, and a prompt window. We also need the business logic to be able to build a subfile, perform the selection of a record including validation of any option selected against the subfile, and validation of any data used to amend the record. We would also like to be able to delete a record from the file, but only after checking if it is possible.  So, given a few rules, how can we do this? 

Firstly, what are the rules? Well, from looking at our tiered system from the Java application before, we would like the business logic and the database access to be separate from the presentation layer. Ideally, we would like the database layer to be detachable from the DB2 database, but more on that that later. We also want the business logic to be accessible from any presentation layer. Now, if we follow these rules, the presentation layer cannot contain any business logic or perform any database access so that means no tables or files to be coded in the display programs.  It also means that the business layer can never assume that any global variables have been set from a previous call. It might be that we have a browser-based presentation layer that allows multiple access of the RPG code within a batch server process. How do we cater for this eventuality?

If we put our database access and business logic into service programs, we can write the presentation layer in such a way that common tasks call the same sub-procedure, and that the sub-procedure requires certain parameters to complete correctly. In the simple case of building a subfile, we would normally need to know the SFLPAG value, along with any RRN to allow us to position the view on the correct ‘page’ of information. We also need to know if we have reached the end of the file, so the SFLEND indicator can be set off or on. 

If we do this in a sub-procedure, we can simply pass in the number of records we require along with a record to start displaying from. Using embedded SQL within the service program gives us even more flexibility so that we don’t need to use OPNQRYF or special logicals to display the returned information in the correct order.  It also makes it easy to use filtering on our subfile. We can pass back a multiple-occurrence data structure from the sub-procedure to replicate passing an SQL result set which can then be used to build the subfile or HTML table, depending on the front end. This sub-procedure can then be used any time we want to display that information, as long as the parameters are passed in correctly. 

We can even send back more information than we require, allowing the same sub-procedure to be used by many different presentation layers and, if the end of the file is reached, we can send back an indicator to set the SFLEND indicator off or on.  We can have sub-procedures to allow us to validate fields we enter into the presentation layer in the same way we have methods in Java that allow us to validate HTML forms. These sub-procedures can even return arrays that allow us to set indicators on or off in the display file. Using service programs, we can even code for error handling within the sub-procedures, throwing messages back to the calling programs to allow the presentation layer to decide what is important and what isn’t. 

You could even take it further and ensure that every file had to be accessed from its own ‘getter’ and ‘setter’ sub-procedure and, if you really wanted to, you could even abstract the business logic from the database altogether. Using some of the System i APIs (as was proven by one of my colleagues) you can make the layer database-independent by working on offsets – that is to say, you use the API to read the file and using the known offset and the record length you can retrieve the information from any database. 

Given all this, we can build a tiered RPG system whereby we can separate the presentation layer from the business layer and subsequently replace our green screens with a browser-based system or have our own iSeries mobile applications hosted from a portal running on Apache on our favourite black box.

You could even look at the System iNetwork website and browse Bill Blalock’s blog (now there’s a tongue-twister if ever I heard one) on developing rich clients within Eclipse. He is using iSeries data queues to pass the messages between his presentation layer and his server, and thus building MVC applications where the business layer is written in RPG and the view/controller is done in Java. It can be found at http://www.systeminetwork.com/isnblogs/eclipsercp and it was also listed in the article by Seamus Quinn about the System i blogosphere in last month’s (March) issue of System i NEWS UK. I highly recommend this blog to anyone out there whose interest I have piqued with this. I, however, shall go back to see what other techniques I can pick up from my new colleagues and perhaps I will be able to share some with you in the future.

This article originally appeared in the April, 2007, edition of System i NEWS UK magazine.