Re: PHP and SQL web developer re-creates all business logic found in RPG programs

Nathan, an interesting aspect of this is whether the I/O is isolated
from the business logic, or the business logic isolated from the I/O.

Let me explain.

Back in '95, I took a heavily used interactive BPCS program that handled
inventory location transfers, where that particular business logic was
only in the 5250 program but needed from batch, and isolated the
business logic to be callable from other processes, specifically an
interface to a shop floor control system that processed transactions
from the shop floor system against BPCS.

When I was done, the BPCS 5250 program, which was quite complex,
contained only one F spec, the WORKSTATION. All database file specs had
been moved to specific programs that handled logic in between EXFMTs.

In addition, I further isolated common logic into function specific
programs, such as warehouse, item, container, etc. business logic. This
is equivalent to what service programs would typically be used for now.

What I ended up with was a series of batch programs whose parm list was
all the globals accessed in between the EXFMTs. For compatability
purposes I also added a second parm data structure of the indicators.
The original complex subfile program worked identically as before,
although not one line of the original code other than EXFMTs still
executed in it.

The DS parms were of course not a new concept. BPCS had used that
architecture for their AS/SET rewrite of BPCS, which I worked on in '94,
and that architecture was Joe Pluta's who was technology guru at SSA at
the time.

However, my use of it was very specific, a different data structure
layout for every program, whereas SSA's use of Joe's architecture
implemented a more generic DS interface to function servers, which
programs were to call for validation and/or update, get everything, and
use what they needed. I think the generic is a lot harder to get right
because it's everything, although it seems simpler in concept.

But also harder was my use of a specific stream of fields from program
to program to implement very complex business logic. In reality, if I
didn't screw up it was guaranteed to work, because it merely relocated
working logic from one program to several smaller ones. And in fact when
the code was compiled and tested by a QA team (I did all the RPG coding
in a DOS text editor and never uploaded it to try compiling), after
resolving some typos to get clean compiles, one logic error was found in
comparing results from the original Item Move program to the newly
decomposed suite of programs. That fix required a flip of a GT to a LT
or something like that in one statement.

And that was calling from the new shell 5250 program. But it also worked
just as well now from the shop floor transaction interface, where the
programs getting parms didn't care if they were coming from a 5250
screen or a transaction record written with SQL from a shop floor PC.
Which is the whole point of business logic isolation.

That's how clean modularization of existng logic can be. But note that I
separated out business logic from user I/O, not user I/O from business
logic.

With the asynchronous nature of web calls versus the synchronous nature
of 5250 EXFMTs, that is even more important of a distinction.

I enjoy your posts as always Nathan.

rd


Nathan Andelin wrote:

Scott,

I appreciated your well considered reply. It motivated me to track
down various IBM i manuals, redbooks, and articles, and do more
reading about stored procedures and UDTFs.

I also pulled out the source code for an RPG program I wrote 20 years
ago, which I think is still in use today at about 250 credit unions
in the US, and supports over-the-counter teller transactions. The
program uses about 30 database tables and 1 5250 display file. And I
considered what it might take to separate the code, so that the
database I/O and business logic could be evoked by say a PHP client.

I concluded that it would be a lot easier to separate the screen I/O
and application control logic, from the business rules and database
I/O, than to rewrite the business logic in PHP.

This is more for Eric Lehti's benefit and others who may be
considering marriages between PHP (or something comparable) and RPG.
If I were modernizing a CRM package, I'd use my own ILE framework for
handling browser I/O, and database I/O. And drop the notion of a
marriage between PHP and RPG.

Stored Procedures and UDTFs do seem like a viable option, but may
extract enough pain, that folks may flip-flop back and forth between
the alternatives of building stored procedures or just rewriting the
"business layer" in PHP, depending on the particulars of each
situation.

In business applications, the same tables are used for both inquiry
and maintenance. And may or may not include calculated field values
where the logic would be easier to implement in stored procedures as
opposed to SQL selects. With stored procedures, both input and
output parameters are passed on the same call. And depending on
whether the database is used in an inquiry or maintenance context,
the call-level interface may change. So you end up writing multiple
stored procedures, or extending parameters to cover multiple
contexts.

So it seems to me, that in the long run, if one were really bent on a
marriage between PHP and RPG, something of a client-server
request-response protocol would be better. Where the structure of
requests and responses were more flexible. And where the state of
RPG servers might be persistent for individual users in some
applications, but support multiple users in other applications.

Nathan.