Nathan wrote
This has a lot of potential to bridge the gap between new Web interfaces,
and existing 5250 interfaces, or even new 5250 applications that folks may
have in mind, by deploying them all together under a Web portal.<<
Hi gents;
Actually it came to me after reading Nathan's fruity post: The biggest
potential might be the decoupling possibilities of 5250 applications to SOAP
services. I never thought that I would endorse a solution like this, but I
have changed my mind for a couple of reasons:
First - The type of 5250 applications you would like to plug into a SOA
architecture might be so "legacy" it is not worth or to complicated to
rewrite.
Second - A screen scraped web-service might buy you time when you are in a
transition phase between old and new.
Last - If you use the "IceCap" approach, your scripting language is good old
RPG and you can mix screen scraped logic with new logic. When the
implementation runs, you can decide whether or not to rewrite or just leave
it as is.
IMHO other screen scraper approaches fails because you need to run the
scraper scripts in languages you might not know or even on a different
platform or at least in a different environment.
IceCap runs as a native RPG application in a web session on top of one or
more 5250 sessions.
For that reason I have extended the "IceCap" Virtual Terminal Service with
some really handy functions.
Look at this following sample which is a complete SOAP web-service returning
the current CPU utilization.
This is simply done by the contents of the "WRKSYSSTS" panel.
Here is the source or the RPG "script"...:
---------------------------------------------------------------------------
<%@ language="RPGLE" pgmtype="webservice" pgmopt="MODULE(iceCapWs SVC242)"
%>
h nomain
/include qasphdr,iceCap
d pVts s * inz(*null)
d vtSession ds likeds(vtsDS) based(pVts)
d vtField ds likeds(vtFieldDS)
//' ------------------------------------------------------------------------
//' getSysSts - Get System Status webservice method
//' ------------------------------------------------------------------------
p*name++++++++++..b...................keywords++++++++++++++++++++++++++
p getSysSts B export
d getSysSts pi
d cpuUsed 5 2 output
d sysAspSize 7 2 Output
d sysAspUsed 9 4 Output
d panelFound s n
d decp s 1 inz(',')
//' ------------------------------------------------------------------------
/free
//' Open the virtual terminal session if not open yet.
if (pVts = *null);
pVts = vtOpen();
endif;
//' Locate the "Work with System Status" panel
PanelFound = *OFF;
dou (PanelFound);
select;
//' logon if the signon is displayed
when vtSaaTitleContains(pVts:'Sign On');
vtSetFieldNo(pVts: 1 : 'DEMO'); // First field is the userprofile
vtSetFieldNo(pVts: 2 : 'DEMO'); // Second field is the password
vtSetFieldNo(pVts: 3 : 'QCMD'); // Program to run - QCMD
vtPressKey(pVts: vtENTER);
//' run wrksyssts if command entry is displayed
when vtSaaTitleContains(pVts:'Command Entry');
vtSetFieldNo(pVts: 1 : 'wrksyssts');
vtPressKey(pVts: vtENTER);
//' Refresh statistics in the system status is displayed
when vtSaaTitleContains(pVts:'Work with System Status');
vtPressKey(pVts: vtF10);
PanelFound = *ON;
other;
// !! TODO - invalid screen
return;
endsl;
enddo;
//' Got the panel - peek the return fields for the webservice
cpuUsed = num(vtGetScreen(pVts: 3: 29 : 10 ): decp);
sysAspSize = num(vtGetScreen(pVts: 4: 70 : 8 ): decp);
sysAspUsed = num(vtGetScreen(pVts: 5: 70 : 10 ): decp);
return;
/end-free
p getSysSts e
%>
---------------------------------------------------------------------------
One thing I am especially proud of in IceBreak is the implementation of
WebServices. It is all done in RPG and based upon the RPG source with a
little use of annotations.
Basically it is one (ore more) procedure(s) in a services program that acts
as method(s) in the webservice.
The name of the "method" in this case is "getSysSts" and it is returning
three properties. You can see the annotation added to the RPG syntax -
namely "output"
d getSysSts pi
d cpuUsed 5 2 output
d sysAspSize 7 2 Output
d sysAspUsed 9 4 Output
When the web-service is invoked it will start a new session on the virtual
terminal with the "vtOpen" and navigate to the "WRKSYSSTS" panel.
This is done by a new "IceCap Buildin" used like this:
When vtSaaTitleContains(pVts:'Sign On');
The vtSaaTitleContains procedure returns true if it locates the value string
- in this case "Sign On". The panel must SAA compliant for it to work ( All
IBM panels (except a handful) are SAA. SAA states that the title will be
centered and high lighted/white.
When the "WRKSYSSTS" panel is found I use a combination of Num() and
vtGetScreen() to pull data out of the screen.
The Num() procedure is a IceBreak build in which converts a string to number
disregarding invalid numeric chars.
vtGetScreen() on the other hand is the "grabber" interface. The following
returns the CPU % from a Virtual Terminal Session at line 3 column 29 and
the following 10 chars - decimal point can be "." for US or "," for Europe:
cpuUsed = num(vtGetScreen(pVts: 3: 29 : 10 ): decp);
When you refer to this IceCapWS.asmx file from a browser, it will compile
the webservice (if needed) and produce the WSDL that goes along.
http://icebreak.org:60000/IceCapWS.asmx?wsdl
The code can be verified by the excel spread sheet "SystemStatus.xls", where
I have imported the web-service and use it from within this macro:
---------------------------------------------------------------------------
Sub Macro1()
Dim ws As New clsws_icecapws
Dim sysAspSize As Double
Dim sysAspUsed As Double
Dim cpuUsed As Double
'Call webserice and return cpu% etc.
cpuUsed = ws.wsm_getSysSts(sysAspSize, sysAspUsed)
'Update sheet
Row = ActiveCell.Row
Cells(Row, 1) = cpuUsed
Cells(Row, 2) = sysAspSize
Cells(Row, 3) = sysAspUsed
'Move to next row
ActiveSheet.Cells(Row + 1, 1).Select
End Sub
---------------------------------------------------------------------------
I have zipped all the files including the "programmers guide" where chapter
6.1 covers web-services.
Find it at:
http://demo.icebreak.org/webfiles/IceBreak/WebServices.zip
The zip file contains:
IceCap.rpgle.h The IceCap header file for Virtual Terminal
IceCapWS.asmx The RPG Webservice demo
IceCapWS.wsdl The output from the service if you run it with ?WSDL
Svc242.c The Virtual Terminal 5250 wrapper and Parser
services.
SystemStatus.xls A testing XLS spread sheet that calls the webservice
Best regards
Niels Liisberg
IceBreak Chief SW Architect
System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Nathan Andelin
Sent: 9. januar 2009 17:40
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Niels IceCap 5250 was->Pete's web5250 was->Re:
Business Developers was ->Re: IBM Gives RPG Devotees Their Own Café
From: Niels Liisberg
The trace with both the screen and the JSON format is only for
debugging purposes.
Okay. I took another look at your code and saw that the "C" module was
outputting a trace in JSON format for debug purposes, while the RPG module
was outputing HTML and ExtJS code.
It's more clear to me how your design offers a lot of flexibility for RPG
programmers.
One one side, your "C" service program shields RPG programmers from the
complexity of the 5250 stream and exposes a simplified set of procedures and
data structures. I REALLY like that! It would be great to see that
interface extended to support *DSPF windows, and other *DSPF capabilities.
Then on the other side, the RPG programmer could generate an HTML stream, or
a JSON stream, or any other type of stream supported by the intended client.
That client might be using ExtJS or some other rich interface, or might even
be something else, other than a browser technology.
In "the real word" the JSON formatting has to occur in the "front
end" application. I haven?t have time to make that right, but that will
actually change the UI paradigm.
Yes. I understand that. Is Rob Dixon is paying attention to this thread?
If his database utility already offers a 5250 interface, an ExtJS client or
something similar could be a good alternative to the CGIDEV2/HTML approach
that he's working on.
I'd also be tempted to work on some sort of AJAX client, talking to an RPG
server, using your virtual terminal interface.
This has a lot of potential to bridge the gap between new Web interfaces,
and existing 5250 interfaces, or even new 5250 applications that folks may
have in mind, by deploying them all together under a Web portal.
Nathan.
midrange.com
