A utility might work. But what technologies would the utility use?
I would suggest an ILE based web service utility. Access it via an HTTP URL
such as:
http://www.example.com/wsu100/{{action}}.ws?object={{object}} where:
WSU100 might be the name of the ILE *PGM.
The WSU acronym stands for Web Services Utility.
{{action}} might be a placeholder for DB and SQL operations such read,
write, update, delete, select, etc.
{{object}} might be a placeholder for the name of any DB table or SQL view.
Additional parameters may be passed via JSON messages or additional
query-string parameters.
WSU100 runs as a JOB in an IBM i subsystem; processing requests from
clients as they arrive on a data queue.
An HTTP server plug-in forwards requests to WSU100 queues, and returns JSON
responses to SPA clients.
And what about cases where we want to perform some complex business logic
in generating the JSON response? I really hate working with beastly SQL
statements. I find them harder to understand and harder to debug than other
programming languages.
The vast majority of requests for data for most business applications can
be provided without complex business logic. I hate beastly SQL statements
too. I prefer using SQL views, and keeping SQL Select statements simple.
Occasionally, we build SQL views, which may select from other SQL views,
which may select from other SQL views, where each SQL view is a rather
simple statement, but together combine to fulfill just about any request
for data. Occasionally an SQL UDF may be deployed to generate column values.
Business logic pertains more to data validation, referential integrity
constraints, performing transactions, and database updates. I recommend the
use of DB event handlers for that. My idea of "DB event handlers" are
service program procedures which are evoked from DB write, update, and
delete operations, and are similar to DB triggers, but which run
out-of-process, may return descriptive error messages, and may run
asynchronously.
So your Web Service Utility need not handle complex business logic. It
would just perform I/O and possibly return descriptive error messages
generated by DB event handlers, which are tailored to each DB table, and
may include custom business logic.
And what if we want to make use of other IBM i data resources such as data
areas, data queues, spooled files, or IFS files?
A Web Service Utility could handle those types of requests, perhaps by
extending {{action}} to include various operations and extending {{object}}
to include data queues, data areas, IFS files, spool files, output queues,
etc.
midrange.com
