Hello Henrik,
I think we've said all there is to say about the security side of
things, but I will address some of your other points.
On 6/14/2015 1:14 PM, Henrik Rützou wrote:
1) RPGOA. If customers just want a browser based GUI why not just screen
scrape their 5250 environment? There are very advanced screen scrapers
today that require no rewrite of 5250 code.
Because screen-scraping is limited to what can be put on 5250 screens,
and RPGOA is not.
Imagine you want your RPG program to calculate some tooltips visible
only on a mouse-over. Or perhaps your program wants to control the
color or font of data on the screen. How do you do that?
In a screen-scraper, the only way you can communicate between the RPG
code and the GUI is by placing data on the 5250 screen. So if you want a
tooltip, you have to write the tooltip as a string taking up space on
the screen. The GUI can then hide that data (maybe by applying a CSS
class with visibilty:hidden) and use JavaScript or whatever to load it
into a tooltip over the GUI element. This is clumsy.
With RPGOA, you can connect variables in your record format to anything
in the GUI. They are just variables being passed across, they do not
need to be printed on the screen. So you just tell the GUI to read the
tooltip from the field in the record and you're done. Same would be
true for colors, fonts, etc..
Those are just very simple (maybe too simple?) examples, of course.
Suppose you're loading data into a chart (such as FusionCharts) or need
to provide a picture of a product, where the image file referenced might
be different depending on calculations in the RPG program... same
thing. With RPGOA you can set a field in the record format to point to
the image, and connect that to the "img src" property in your web
screen. With a screen scraper, the only way to communicate is by
printing data on the screen itself, so you'd have to put the URL on the
5250 screen, hide it, and load it into the image, taking up valuable
real estate.
Another problem with 5250 screen-scraping is that you are generally
stuck with the limitations of 5250. Suppose you want to create a
subfile on the screen with 50 records per page? Can't do it, the 5250
screen will only support 24 or so lines per page. Or maybe you want to
have more than 132 columns? Same problem.
Yet another problem is identifying which screen to show. In RPGOA the
program executes a record format, and that's what's displayed. In
screen-scraping, however, the GUI has no clue whatsoever what your RPG
program is doing. It doesn't know which record format you're
displaying, so you have to tell the GUI to look for strings on the
screen. "Look for 'APRZ001F' in position 61 of row 2, and that
identifies this screen". That's how screen-scrapers do it -- and that
works fine if you always have identifiers like that, and nobody ever
duplicates them... but when someone accidentally duplicates one, or
when you have screens (including the ones in the OS) where there are no
identifiers, you can have problems.
Also, the GUI doesn't know the field names of your fields on the screen.
Imagine that you want the GUI to show a drop-down on the screen
instead of an input blank... all screen-scrapers support this, but do
you think you can go and say "I want to change the PRODCODE field to be
a drop down!" No, you can't do that, because the GUI has no idea that
the field is named PRODCODE. The 5250 controller told it "put a blank
in row 5, column 10" (or wherever it happens to be) and that's all... it
doesn't know the field name, so you can't use that field name in your
GUI. Whereas in RPGOA you do know the field names because you see the
actual record format, so you can use the same names in the GUI that are
in the RPG program.
Screen scraping is a useful tool because it lets you incorporate screens
that you don't have the source code for, or are written in languages
that don't support OA (CL, Cobol, etc) or for things like the operating
system screens (WRKSPLF, WRKACTJOB, WRKUSRJOB etc are sometimes
incorporated into people's applications.) It also gets you up and
running very quickly.
But it is limited and clumsy by comparison to RPGOA for the same screens.
2) RPGOA. Since the UI CGI programs and the REST(CRUD) services are
totally separated the REST(CRUD) service doesn’t know what information
(fields) that are passed to it. In the same time the UI CGI programs are
“design” driven based on the user settings. This means that the same UI CGI
program may generate a form with 5 fields for one user while another may
have a form with 100 fields both using the same base REST(CRUD) services
for data handling.
This can be done from RPGOA as well. You can write a screen, display it
with EXFMT, and that screen can contain JavaScript that does AJAX calls.
We provide both REST and SOAP JavaScript APIs in our framework.
Or, instead of coding the web service calls in the screen itself, you
could do them from the RPG program that drives the screens using tools
like HTTPAPI or IBM's IWS, or the various commercial tools out there for
calling web services.
It's true, this does mean re-writing your screens instead of just
re-using the existing 5250 ones... but we have customers who have done
this with great success.
Using RPGOA/EXFMT will not tell the REST(CRUD) service which fields that
are passed to the handler. Using CGIDEV2 mydata = zhbGetVar(‘var1’); will
neither. But powerEXT’s mydata = getExtVar(‘var1’:mydata); will search the
input buffer for the variable and if not found return the default value in
parameter 2 to the input field.
Typically customers would put text boxes on the screen with the default
values, and set visibility:hidden so the user can't see them... then
they'd get the default values back into their programs. That happens
very often, and it's easy to do. They can hide/unhide fields based on
their RPG logic, so can put out different numbers of fields for
different users/situations. This could be done by connecting the
visibility to a field in the record format, or it could be done with
some JavaScript code on the display.
midrange.com
