Okay, I've written the first-generation RPG proxy program. Basically the proxy's job is to extract the request from the EGL Rich UI runtime and invoke the appropriate business logic.
It's a little more complex than that. If you're testing locally your request is automatically redirected to the local proxy that runs inside the workbench. The proxy calls your CGI service and your service extracts the data from the request. The request looks something like this:
{"bindingName":"PollService","method":"getPoll","params":[0]}
And you return data that looks something like this:
{"result" : { "name" : "Language Poll", "choices" : [{ "choice" : "RPG", "votes" : 87},{ "choice" : "EGL", "votes" : 33},{ "choice" : "PHP", "votes" : 2}]}}
Not too difficult. However, once you deploy to your host machine, things get a little more complex. The runtime no longer uses the proxy in the workbench, and instead it has to send to your proxy. Your proxy program then has to unbundle the request from the larger request, which now looks like this:
{"uri":"http:\/\/IRUIHOST\/cgi-bin\/POLLSVC2.PGM","queryParameters":{},"method":"POST","body":"{\"bindingName\":\"PollService\",\"method\":\"getPoll\",\"params\":[0]}","headers":{"EGLREST":"TRUE","egl_statefulsessionid":"JSESSIONID","Content-Type":"application\/json; charset=UTF-8"}}
A little more ugly, no? Not only that, you have to also buffer your reply into something just as complex. However, I managed to hide most of that complexity in a single program named EGLPRSCGI. I then have two programs, POLLCGI2 and CGIPROXY, each of which calls EGLCGIPRS to get the parameters from the client. Each then calls POLLSVC1, which is the actual business logic, and then formats the response as needed (CGIPROXY does a lot more formatting).
Eventually, CGIPROXY would have to recognize all the various requests and call the appropriate service program. But for now, you can get the project, and you can see the result on the SWICD website:
http://see-what-i-can-do.com/poll2.html
It's pretty slick, actually. 
The project interchange file is on the project interchange discussion post.
EGL and i
Previous Next
JoePluta
in response to: Ortwin
Thanks, Ortwin - I'll post an updated PIF later tonight (I hope). Also, I've found that I can get the server to notice the change if I recompile the high-level programs (CGIPROXY and POLLCGI2). Getting RPG-CGI changes to be recognized is always an issue and I'm not entirely expert at it yet.
UPDATE: I uploaded the new project interchange file with the SWICDi project. Unfortunately, that's a web project and because of that it added nearly 10MB to the PIF file (mostly because of the fda7.jar file). I hope I can find a way to reduce that down the line, but for now I think I'm going to move the data definitions to the Rich UI project in the next release.
dod11
Hi Joe. Really like the direction you're taking here. Well done. 2 comments:
1. No COBOL on your poll?
2. The generated page source code is 'huge' to say the least, and takes nearly a full minute to load (using a high-speed company link). Anything that can be done about this?
-David
JoePluta
in response to: dod11
David, just for you, I added COBOL. Took less than a minute .
As to the download, that's not your fault or even the fault of the tool, it's mine. I am on a very slow link here, especially going up. I remember doing something with ZIPing the generated page; I have to ask Chris how that's done. That should significantly reduce the time.
UPDATE: I turned on compression on the HTTP server (very easy to do). It seems a lot faster to me here. How about you? Give it a couple tries to make sure it downloads the runtime and caches it.
ChrisLaffra
in response to: JoePluta
Joe,
You made a small mistake to publish an HTML file that is generated in DEVELOPMENT mode. This has all the EGL debug information included in it, plus a lot of other runtime overhead. Please change your generation mode to DEPLOYMENT and then upload your HTML again. This should reduce the size dramatically.
If you deploy your application using the tooling in RBD, we actually warn you about not deploying in DEVELOPMENT mode.
Even More Compression.....
Now, even when generating in DEPLOYMENT mode, we can compress the end result better. In http://www-949.ibm.com/software/rational/cafe/blogs/egl-rich-web/2009/02/09/honey-i-shrunk-my-own-bits-using-egl-rich-ui-to-compress-egl-rich-ui we explain how to do compress your deployed application in RBD 7.5.1.3.
We can automate this process, of course, and in EGL CE, we did just that by implementing automatic compression of:
1. generated and hand-written JavaScript (using Dojo Shrinksafe) and
2. resulting HTML (using gzip mod enabled for the web server)
This reduced the end result for a complex application I wrote that uses Dojo to something like 60K. Your original HTML file is close to 800K, so you still have a lot of opportunity for compression.
We are considering adding the automatic compression support to RBD 7.5.1.4
Chris
ChrisLaffra
in response to: JoePluta
Joe are you sure your server is gzip-compressing the HTML?
I see this when I run my compressed application (60K) on Tomcat 5.5:
Server Apache-Coyote/1.1
Etag W/"279777-1253061937765"
Last-Modified Wed, 16 Sep 2009 00:45:37 GMT
Content-Encoding gzip
Content-Type text/html
Date Wed, 16 Sep 2009 01:05:53 GMT
When I run your application (766K), I see this:
Date Wed, 16 Sep 2009 01:04:39 GMT
Server Apache
Last-Modified Wed, 09 Sep 2009 03:52:06 GMT
Etag "2c57e-bf929-1a9e580"
Accept-Ranges bytes
Content-Length 784681
Content-Type text/html; charset=windows-1252
I tried http://see-what-i-can-do.com/poll2.html at 9:08 PM, EST, Sept 15, 2009.
ChrisLaffra
in response to: ChrisLaffra
It's cool to see a proxy server written in RPG. I would love to see what that looks like...
Nice work, Joe!
JoePluta
in response to: ChrisLaffra
Thanks, Chris. I'll re-deploy in DEPLOYMENT mode. This is very much a spare time one-man project so I miss things like this .
As far as compression goes, I'm not certain. I think I configured compression in the Apache server but that doesn't necessarily mean I did it correctly. That's why I asked, and it seems like I might not have been successful.
Finally, the source code for the RPG is in a save file in the PIF. Look for the folder named "i".
Joe
This is so cool!!! Great job Joe!
Now for smaller projects (without web service calls) this architecture can be used.
Only thing, when I tried this project I noticed changes on the RPG will only become active after stopping and starting the web server.
Oh, and you forgot to include the SWICDi project, in which is the Poll record part, in the PIF.