Here is the approach which works quite well for me and it's synchronous as well:
1. RPG - call CL program or CL program wrapped with CL command with parms to Run Python code.
2. Python code outputs return info via STDOUT console output to database/IFS file or to a predetermined database file location.
3. Read resulting return values from the STDOUT file location from the RPG app.
4. Repeat.
Same general concept works for Java, Node, PHP or anything else that can write console output to STDOUT.
STDOUT is console output similar to the joblog for those of you who are new to this.
I prefer this direct return approach rather than trying to add a data queue into the mix because that adds extra layers, but that would probably work as well.
Also gets you out of the business of single point of maintenance libraries like HTTPAPI so you can start plugging into the larger community that develops plugins for Python.
Best of both worlds interconnected via console output (STDOUT) which is also used a lot in the multiplatform world.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
----------------------------------------------------------------------
message: 1
date: Sat, 2 Jun 2018 14:07:38 -0400
from: John Yeung <gallium.arsenide@xxxxxxxxx>
subject: Re: [IBMiOSS] RPG parameters to Python and back
On Fri, Jun 1, 2018 at 5:30 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
The irritating part is that the Python is essentially a perfectly
self-contained unit of work. I just need to plumb it in for a
finished application and I worry that the plumbing will be ugly.
Maybe I should stop worrying and keep writing code :-)
Indeed. Often plumbing is simply ugly. That's why we generally hide it behind more attractive exterior layers. ;)
Prettier plumbing can be expensive. Sometimes prohibitively so.
I'm looking for options to be able to have an RPG program fire off
these Python 'services', have them work with the web service, and pass
the results back to RPG.
Do you need something "tighter" than dropping off the return values in a stream file or database table?
Ultimately, I think if you're going to rely on Python (or other technologies of a similar nature, such as Node.js, Ruby, PHP, etc.) then you will have to accept that "calling" and "retrieving values"
are two separate steps performed by the caller. The caller can poll the designated drop-off site to see when the returned data is ready, or there can be some kind of arrangement where the callee notifies the caller that the data is ready to be picked up. Off the top of my head, having Python populate a data queue via iToolKit is the tightest thing which still seems "kinda simple" to me. (I don't personally use data queues; I'm just imagining that folks experienced with them would find them easy to use, and they seem to be a decent fit, conceptually.)
If you really want that immediacy and "single-step" feel of a call with output parameters or return value, you have to use something other than Python. I think the main choices are probably Scott's HTTPAPI (which of course is a lower-level programming interface than the Requests library, but there are examples and people who can support you) or perhaps some Java stuff, since RPG can receive output parameters or return values from Java, if I understand correctly.
For green-field (not green-screen!) programming, of course just using Python throughout would be a good option. (And you *can* plumb a *PGM or *SRVPGM into surrounding Python quite cleanly.)
John Y.
midrange.com
