IBM_iOne of the most important decisions when modernizing your application is deciding what the overall blueprint for your stack will be and which parts of your development team are responsible for what. The overall makeup of what languages you should use, how they should communicate together, and where your Business Intelligence should

For example, our current application is completely green screen and RPG based with code that was started 25 years ago and has been updated and improved annually at every customer site for the past 25 years. It is comprised of a giant processing job run every night (we call it our Night Job) and an interface based on DDS. That age of code could seem like a liability to some, but in our world (Inventory Management and working with the Buying Process) certain algorithms and routines takes years to test if they are producing accurate results.

When we started trying to decide how to modernize we knew that we didn’t want to abandon our BI that exists in RPG and has done a remarkable job. To start over and write these routines in another language would lose our advantages over the competition. But the front end had to evolve and modernize to meet our current and future customers expectations. The night job has potential of one day being updated to Node.js when the maturity level of the technology reaches a certain point and the availability on IBM i becomes more widespread.

We decided our users will have a web based front end built on Zend Server for the IBM i. If you picture a traditional ‘CRUD’ interface we have this front end responsible for just the ‘R’ (review). This will use PHP, ZF2 (and migrate as we go), and Twitter Bootstrap. ZF2 has built in DB2 support that allows for abstraction of the function to build our multiple screens. When it comes to displaying data and changing workflow this stack allows the

Where this idea really shines though is the limitation of our front end developers not being allowed to C, U, or D to the database. While updating a field in our database is simple enough using ZF2, the important piece that is lost is all the considerations our current setup must take into account. If a vendor belongs to a certain buyer group and the user changes that buyer group it is possible there is up to 200 other updates to the database that must be made so that change is effective, causes no problems, and is logged appropriately. Instead of trying to teach the ZF2 dev team how to understand the BI we have set the RPG team (aka the backend team) the task of creating an API for our web application to call whenever CUD (and I will throw in a 5th term, Calculate) must happen. Our RPG dev team is creating a library of single purpose RPG programs to accomplish all the tasks needed. For example: If we want to delete a Vendor in our system it is not as simple as just removing the vendor record. There can be thousands of products that would be abandoned as well as many checks to see if the Vendor is active in our processing. The user (and the front end team) just wants to delete the supplier and not have to worry about all the considerations when calling the program. Our RPG program (which is actually a CL program calling an RPG program in case there are errors to handle) takes in our parameters, does all the necessary checks, and either returns a success or failure code with a fail message to be displayed to the user. All the experience and knowledge of our RPG programmers to our business remains where it should. We also are taking the time to comment in our API what is happening and why so that future updates to move to another language will be easier.

With all these single purpose API calls we the web dev team now has the ability to do some ‘cool stuff’. On install of our web app the user has a chance to set the API. This is just way to future proof and allow us to migrate to another API if we decide to move off RPG (we have no plans for this but it pays to plan ahead!). Just a simple key value pair in our service manager:

return array (
		'k3s_settings' => array (
				'api' => 'rpg',
Now that that is set we create a ZF2 module to house all the RPG we need to call. We create a controller to handle RPG programs that work on a specific concern. If we are going to do operations on the vendors we put the CUD operations in that one controller for vendor. We then use the action to decide which program we are going to call:

Instead of returning a view model so a user can go to a screen, we want to return JSON. We have now created an API access to our RPG API. This might seem convoluted, but it allows some really neat stuff. We can now use jQuery tools to call some RPG when we need to update. Using a tool called jEditable I am taking in 50 parameters, checking for all considerations, updating my vendor, adding all additional changes to the database needed, and logging what the user did. To the user it was simple and quick and painless! To the web dev team they don’t know how difficult the operation was that was just performed. To the back end team they aren’t concerned with all this UI interaction, they just have their responsibility of the interface and it worked!

Now that we have this setup and have correctly given responsibility to the right teams we are able to develop faster and stronger application without losing the fidelity of the current program.