Re: What style of RPG program can communicate with PHP?

I have never created a web service but my understanding is that unless you
write Java that the web service takes your XML coming and transforms it
into PCML to pass as parameters to the RPG which puts you right back where
you started.

An example where XML makes things simple. I worked on a stored procedure
that processed a screen written in Java that was for invoice search. You
could enter one of a two dozen criteria and any combination which was
implemented as parameters so you had a program coming in with twenty some
parameters. The code was a nightmare. You had to look at each parameter and
see if it was used and then start building an SQL statement based on which
one they entered.

With XML, you just do what I sent in the previous example. The only code
that gets executed is the code for the customer and the date and it is all
handled by your expat parser.

Another example might be a GUI screen where you can pick a from a list and
inside each list you can then pick from another list. I had an example of
this in the past but I cannot remember what is was.

With parameters I somehow have to code parameters for arrays inside of
arrays and variable number of each. Now technically i could do it but it is
going to be a nightmare. With XML, I just have something like:

<request>
<customer>ABC</customer>
<shipto>ABC01</shipto>
<shipto>ABC02</shipto>
<customer>DEF</customer>
<shipto>DEF01</shipto>
</request>

No guarantee as to being right. Just thrown together. The point being that
I express any complex value with ease vs trying to make it fit into
parameters and what is sent is elastic.

We dealt with the whole issue of 32k limits by abstracting the interface
away. We built a java class that read a configuration file to determine how
to communicate to the AS/400(Program, Service Program, Stored Procedure,
Data Queue) and then we had mediators on the AS/400 for each type. In our
case we used user spaces to send data in and back out. If I did it again I
would use IFS files. To the Java programmer using the class they never even
knew the AS/400 existed. You could change the configuration and in a few
seconds you could be using a different method. It was just messages back
and forth. The business logic was written as service programs with the same
interface for everything. Performance was excellent.




On Fri, Nov 30, 2012 at 4:09 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

hi Alan,

On 11/30/2012 4:12 PM, Alan Campin wrote:

OK, but how do you parse the JSON? There are all kinds of choices for
parsing XML including built into the RPG language. Hard for me to believe
that XML has that much overhead.

Parsing (as well as transferring) XML definitely adds some overhead...
probably takes 4 times as long as straight parameter passing... but,
whether that overhead matters in the greater scheme of things really
depends on the application. In most cases, I'd say it doesn't.

I use JSON every day, and prefer it over XML. I use a JSON parser named
YAJL, which is open source and written in C. I ported it to IBM i, and
have written an RPG front-end for it. It's extremely fast. I evaluated
some of the other JSON parsers available for RPG before I did this, but
none of them performed well enough for me. YAJL was the fastest I could
find.

Some day, when I'm less burned out (sigh), I'll make my IBM i port of
YAJL available to the community, and write some articles about it.

Having said that, I'm not sure that JSON is the right option here. One
problem with JSON is that the {, }, [, and ] characters that are so
heavily used in JSON are "variant" characters in EBCDIC, so they can be
a real pain to work with in EBCDIC unless all of your data is always in
the same CCSID. In fact, a purist would say that JSON should _always_
be UTF-8.

Now, in a web application, that's generally a non-issue, since UTF-8 is
the standard encoding of the web world. But, in a stored procedure
call, you'll doubtless be using EBCDIC. I'd probably just go ahead and
use XML in that case.

Though, frankily, Alan your idea of passing XML to a stored procedure
sounds remarkably like you're reinventing the wheel... since that's
pretty much what web services do. However, using a database stored
procedure call as a transport is much more limiting (32k parameter
limit, threat of a security compromise is higher, static connection is
more susceptible to problems on imperfect network connections, etc.)

What is your objection to using web services?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.