Re: IBM i upgrades / Dev Tools

I am curious how this conversation pans out. Lots of things sound good in
theory and can even be proven to be implemented, but there are so many
other factors that can potentially bite you in the butt later on. FWIW, I
participated in such an architecture where the front-end was .NET and
back-end was SQL stored procedures fronting RPG code. All database
interaction went through the RPG code and the stored procedures numbered in
the thousands. Deployments were **painful** and missed deadlines were many
because of complexity. Sometimes complexity is warranted but it needs to
be very carefully balanced.

For example, and going back to Nathan's example, what if some INSERTs
should send a confirmation email and others shouldn't; and what if it
depends on what user interface is writing the row? You could pass the
interface (web vs. 5250) into the trigger but then you start being guilty
of "leaky abstraction".

With that said, I am a firm believer in things like foreign
keys/constraints and SQL stored procs where they've proven their need in a
given project (based on PHP business logic failing) , but to start out a
project declaring all logic must exist in them is making a lot of
assumptions.

At the end I guess what I am getting at, Nathan, is that there is more than
one way to skin a cat.

Aaron Bartell
litmis.com - Services for open source on IBM i


On Tue, Nov 3, 2015 at 1:44 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Any guidance is most appreciated.

Any guidance is most appreciated? I doubt that, since you hastily dismissed
my previous advice about placing data validation, RI constraints, and
business rules "in the database" behind triggers.

I believe that what I'm suggesting is very sound advice. Moreover, what you
seem to be insisting on in placing that type of processing in PHP, is poor
architecture.

Anyone having a connection to your database can bypass your "business
logic". You may be enthralled with PHP right now, but there may come a time
in the near future when something comes along, say single-page
applications, or responsive UI design, or whatever innovation which
improves the user experience which PHP is not well suited for. You may
change your mind about PHP. But your business logic should nevertheless
remain intact.

Here's a link to an RPG sample which handles data validation, which is
evoked by a before-insert / update trigger.

http://code.midrange.com/ee85fb606a.html

I don't understand your perceptions about RPG being "archaic". But since
you are so predisposed, allow me to point out a few elements which show the
elegance of the design.

The source module compiles into a "service program" which exposes three
procedures namely:

init();
process();
term();

init() and term() procedures "initialize" the module when first loaded into
memory by a piece of plumbing known as a "mediator", and "clean up" after
the mediator notices the module no longer being used (a period of
inactivity).

The process() procedure implements "data validation" and generating a
surrogate key for a record, prior to "insert".

Since RPG runs in the same address space as the database, and has direct
access to records, it can simply call a a procedure to "retrieve" error
messages or completion messages, and return them to "callers", using a
single statement. Notice msgGetText() - retrieve a formatted message from
a DB table and trgMsgAdd() - add a message to an array.

Invalid data prevents the update from occurring, no matter who the caller
might be, regardless of whether PHP is the middleware du jour, or not.

This interface can also be configured to work asynchronously. Say rather
than "validations" process() is used to compose and send email, generate an
order for a bank card and a PIN. Is there any reason to tie up the UI while
waiting for such back-end processing to occur? If you want to provide your
users with the best user experience possible ...
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.