In this article we will take a high level look at the BPM equivalent of a simple RPG program. Here is a really important point about this exercise: for purposes of comparison we have designed the BPM application to work very much the same as the RPG application, however, in actual practice you would typically take some very different design approaches. But for the purposes of putting RPG and BPM side by side we have made them very similar.
Let me first thank David Knapp of Apex Process Consultants for developing the BPM example. Apex is a Premier IBM BPM Business Partner who has been working with IBM to develop BPM as a migration path for IBM i applications.
The example application is a very simple master file maintenance program. Technically this is not much of a BPM process in itself, but again, for purposes of comparison this is how many RPG developers will want to start.
In Figure 1 we see the two RPG screens on the left and the equivalent BPM screens on the right.
As you might imagine, the RPG program adds, changes and deletes records in a simple master file and does some validations along the way. I will not show the RPG and DDS code as I’m sure most readers are already familiar with what it would look like.
The starting point for this little development project is that we already have a student master table defined in the database. On the BPM side we have also modeled a simple corresponding student master business object.
Define the Process and Its Activities
So let’s take a first look at what we’re doing in BPM. In Figure 2 below we have designed a student setup process which consists of this maintenance program and then an activity to order a welcome packet to be sent out. Typical business processes can be much more elaborate than this for such things as order processing, loan underwriting, etc.
This diagram consists of two activities and is probably mostly self-explanatory, but I will point out two things:
• In the upper left corner of each “activity” is an icon; in the Maintain Student Data activity the icon is a person meaning this is a “human” service; in the Order Welcome Packet activity the icon is a set of gears meaning this is a “system” service
• On the far left there are labels of two swimlanes – these are the actors in this process, Admissions Specialist and System
An important point about this BPM model we are building: it is itself executable! This isn’t a piece of documentation, this model is what is executed by the process engine.
RPG comparison: While some processes could be represented by a single CL program, typical processes span multiple users and system tasks over an extended period of time. There really is no equivalent facility in traditional coding for process modeling and management. There’s certainly not something a user could look at and comprehend.
Let’s drill down now into the Maintain Student Data activity as shown in Figure 3:
Define Each Activity’s Implementation
You can see on about the fourth line down from the top that we are working on Maintain Student Data. This diagram controls the internal flow of that activity and the components are as follows:
Yellow Boxes – these are screens, known in BPM as “coaches” in that they coach the user through the activity; we will look at how these screens are defined in just a minute
Small rectangular buttons – these represent user actions such as clicking on a button; you can see the names of the buttons, e.g., Update, Save, etc
Light Blue Boxes – these are “integration services” that perform system logic; we will see these in a minute, too
Diamonds – these are decision control points, known in BPM as “gateways”
Key point: in actual practice you would probably consolidate some of these components, but for purposes of clarity in this article we’ve itemized things out pretty explicitly.
RPG Comparison: The nearest RPG equivalent would be the internal infrastructure of a program, i.e., the disparate lines of code that control the flow of screens, database processing and other logic. Again, that is not something that is typically visible and comprehensible to a user, nor is it something you can quickly reconfigure by dragging and dropping.
Define A Screen
In figure 4 below, near the upper left, you can see we are working on the Update Student screen within Maintain Student Data.
Key points about this screen definition:
• The screen layout is defined by dragging layout elements (e.g. Table) and fields (e.g. Last Name) from the palette onto the canvas
• In this example you can see that Last Name is the control currently selected; in the bottom panel are various attributes you set for that control; this is where you would also bind the control to the variables defined in the process
• In reality you would most likely consolidate the screens for add, update and delete into one screen
RPG comparison: In the IBM i SDA would be the nearest equivalent of this BPM function. Obviously SDA does not provide any sort of GUI capabilities or binding of fields.
Define Services for Database Access and Other Processing
Looking back at our process definition for Maintain Student Data in figure 3, recall that there were several integration services for between screen processing. In figure 5 below we drill down to examine the integration service called Read Student. As you might imagine, this service reads in the data for the requested student and populates the fields into the variables being used in the process:
The Read Student integration service consists of four steps:
• Prepare an SQL statement – this is the first box, which is highlighted and whose contents are shown in the bottom panel
• Execute the SQL statement
• Use a gateway decision control to route the logic based on whether the student number entered was valid
• If a valid number was entered then return a student object with the student’s values
RPG Comparison: This type of functionality is typically just lines of RPG code that do input, output and transformation operations on data. The difference here is that these integration services are visible to users and are also always reusable throughout the application (and even across applications).
For those of you who have done development in GUI environments you are already familiar with the fact that many types of validations done in RPG applications are dealt with differently on GUI screens. Rather than validate, for example, the state code that is entered, a dropdown box is provided showing all valid states that the user can select from. Validating the state code is therefore not necessary as the user is prevented from making invalid entries in the first place.
In this small application the only validation on the second screen that cannot be accomplished by similar means is to validate that the city, state and zip code belong together. In this example the validation is realized by creating an integration service as shown in figure 3, Validate State and Zip Code.
The Validate State and Zip Code integration service follows the same pattern as the Read Student integration service shown in figure 5. The service would rely on a table correlating valid combinations of cities, states and zip codes and the SQL retrieval result would determine whether the user’s entry was valid.
RPG Comparison: Because green screens lack GUI capabilities, RPG ends up doing a lot of validation that can be eliminated by GUI facilities. One of the struggles of RPG applications is the tendency to have validation business rules scattered throughout the application with no visibility or centralized control. With BPM all validations can be defined as integration services, which are visible, centralized and reusable. Because the typical design pattern is table-based, they are also under the full control of the user for quick changes.
What’s Not Shown
This article is an overview of BPM development and what it shows are the main artifacts that comprise a BPM process. What I have not shown are some details such as where fields are mapped between the database, the process, the services and the screens. These are pretty much just drag and drop operations. There’s nothing mysterious there, just the sort of field by field mapping you would imagine.
Architecture of a BPM Application
Re-engineering legacy RPG applications into BPM provides a logical, flexible migration path. BPM itself does not run on the IBM i , rather on Windows or Linux platforms. However, besides the inherent value of the BPM platform, there are also some BPM capabilities that facilitate re-engineering:
• BPM was designed from the ground up to integrate with many types of platforms, including the IBM i
• The IBM i database is fully supported
• Existing RPG code may be packaged as stored procedures and called as services from within BPM – this can be done as either interim or permanent measures
• The combination of these points means that a re-engineering project may be designed with multiple phases of flexibly varying integration between the old and new systems – a key point for any such project as most organizations want to avoid a big-bang deployment
Because a multi-phased deployment of a re-engineered application is nearly unavoidable for most organizations, the integration capabilities of BPM are a useful feature.
The Big Payoff of BPM
If you just looked at what you saw above you might think, ok, it’s another GUI application IDE – I’ve seen this in Visual Studio, Eclipse, etc. But you would be wrong.
What we put together comes with some truly amazing BPM advantages:
• Most crucially, the model created is almost entirely visible and comprehensible to users; much of it is even manageable by users; this accelerates IT-business collaboration to unprecedented levels. Compare to that RPG, Java or .Net.
• The model created is immediately executable at all times for testing and even deployment whenever deemed to be ready; users can reconfigure processes on the fly if needed
• When executing:
o The status of all executing processes are traceable and visible within the model UI
o Metrics are collected for all processes and activities and may be viewed through reports and dashboards
o Users have built-in social collaboration capabilities with other users to work on process transactions for joint work or assistance
• Complete governance, audit and change control facilities are built-in
• With increased business collaboration and so many built-in ease-of-use features, applications can be developed much more quickly in an iterative, agile fashion; the business is provided with greatly improved application flexibility and time to market
As mentioned in the previous article in this series, Phil Coulthard, Chief Architect of BPM for IBM and former AS/400 architect, suggests that BPM provides an excellent migration path for legacy RPG applications. What should be interesting to owners of legacy RPG applications who seek to re-engineer those applications, is both the pathway along the re-engineering effort that BPM can provide, and the final destination of BPM itself.
This article was originally published in IBM Systems Magazine.