Clearspace Server Syndication Feed

iSeries DevCon Podcast

JoePluta — Tue, 15 Sep 2009 21:59:59 GMT

I have presented session at iSeries DevCon pretty much since the conference's inception, and this year is no exception. Of course, I'll be doing the heavy lifting on EGL and some other related topics, but there are lots more great speakers and sessions. In my humble opinion, there isn't another conference that better provides both true nuts and bolts programming techniques with a solid application of future-proofing technologies.

Trevor Perry and I have recorded podcasts about what you can expect; click on the link to go to my podcast.

You'll have to enter an email address to get the real link, though.

See What i Can Do - V2R1 (Complete!)

JoePluta — Sat, 12 Sep 2009 23:48:55 GMT

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.

See What i Can Do - V2R1 (Update)

JoePluta — Wed, 09 Sep 2009 23:22:42 GMT

Okay, with expert guidance from Chris, I managed to engineer a Java-free RUI application architecture. It's not exactly simple. In test mode, any REST request goes through an invisible proxy in the workbench. The request that your service sees is not what the proxy sees; the EGL JavaScript runtime actual wraps your request inside a larger request which is sent to the proxy. The proxy unbundles that and sends it to the target service. The proxy then takes the response, rebundles it and sends it back to the runtime.

So, if you're writing your own RPG version of the proxy, then you have to do all that bundling and unbundling. Then you have to invoke the target service. I, however, skipped that. Since I have control over all the pieces, I extracted the actual business logic and re-wrote the target service to call the business logic. Then I added code in the proxy to call the business logic directly.

It's not quite as complicated as it sounds and it works really well as a proof of concept. I can now say with certainty that it is entirely feasible to write a complete, Java-free EGL Rich UI application, using only RPG as the back end.

I'll clean up the code and export the project (including a savefile with the RPG code) in the next day or two.

See What i Can Do - V2R1 (Status)

JoePluta — Mon, 07 Sep 2009 02:22:24 GMT

It looks like I may have bitten off more than I can chew with this little project. I'm not completely certain, but it looks like the concept of an EGL Rich UI application using nothing but an HTTP server is not going to work. Unless I'm mistaken it looks like the Rich UI REST calls go through a proxy servlet. This is done for a practical reason; it allows the Rich UI to make calls to services other than the original host, a feat which is not allowed in normal AJAX calls. However, it does mean that even if the actual REST service is served by Apache (such as my RPG-CGI service), the proxy servlet still needs to be running in a web application server on the host.

Thus the vision of a Java-free Rich UI application has hit what may be a fatal roadblock. (Note: the reason it worked in debug is that evidently the workbench has that proxy server magically enabled. I still don't have all the details on that bit of sleight-of-hand, but I'll let you know if I get more specifics.)

It was still a useful learning experience, but all in all I'd have preferred a better outcome. In any case, I think it's time to put the Java-free RUI on the side and get back to traditional Rich UI development. And if nothing else, I've got a cool widget written.

Look for the "normal" version in the next day or two.

See What i Can Do - V2R1 (Notes)

JoePluta — Fri, 04 Sep 2009 02:48:19 GMT

Well, this has been an interesting little excursion. I really wanted to make sure that I tried to test the boundaries of the "Java-free" EGL/RPG architecture and as soon as I did, I ran into a little bump.

The problem is that you can't use a variable as the URL of the REST request. I don't understand the limitation and I haven't really asked about it yet, but the limitation is real for now. And because of that, you can't just pass your parameters as variables in the URL and then retrieve them with simple calls to QzhbCgiParse in your RPG-CGI program.

All is not lost. As it turns out, when you call a function in a REST service the parameters for the function are passed to the REST service as a JSON string. The JSON string is somewhat buried in the POST data and to make it even more challenging the data is in ASCII, but the parameters are more or less accessible, depending on how hard you're willing to look.

I'm going to take the time to write a simple procedure to extract the parameter string from the POST data. Then in order to make things simple I'll write a second procedure to treat the parameter string as a single string parameter (if that's not too confusing). It will assume that any REST function has only a single parameter of type string.

With that, I can then build comma delimited data in the Rich UI client and parse it in the RPG program using %scan. It's not quite as seamless or flexible as the magic Record-to-Data Structure conversion of EGL, but it will prove the point. Once that's done, though, I think it will be time for me to move to a true EGL Service implementation.

Anyway, that's what I'm working on. Hopefully I'll have it done in the next day or so. It's just a little bit of a speed bump.

Comments would be great. And if an IBMer happens along this and thinks I'm doing something completely bizarre, feel free to let me know...

See What i Can Do - V2R1 (Preview)

JoePluta — Wed, 02 Sep 2009 03:23:59 GMT

Given how easy it was to create an RPG-only service, I've decided to kill two birds with one stone with V2R1. I'm going to create my first persistent widget, and I'm going to do it without any Java code (and thus, without the requirement for a web application server). I'll eventually return to this code and rewrite it using traditional host-side EGL for the service, but this first non-Java version will be an interesting exercise.

The concept of a "persistent widget" is going to be crucial to this project. The term means a widget that persists between accesses and can be accessed by multiple sessions. In its simplest form, a persistent widget is simply a widget backed by a database. In my first go-round I think I'll create a "Poll" widget. A poll will have a unique name, and for children it will have choices, each of which has an attribute of choice text and number of votes.

The EGL record for this will be wonderfully simple, and unless I'm mistaken the RPG program will be very simple as well. I think that by my next blog entry I ought to be able to create an RPG program that not only returns a Poll object, but also allows update. That should then make it almost trivial to create a user interface that allows anyone to vote in the poll.

What do you think? My idea is that we ought to be able to create a whole library of self-contained persistent widgets which can then be used to build applications. What other widgets do you think might make sense?

See What i Can Do - V2R0 - Reprise

JoePluta — Mon, 31 Aug 2009 21:37:56 GMT

Okay, this was a lot easier than I expected. I'm not saying it didn't requier a little research; the QzhbCgiParse API is not for the faint of heart. But a little research, a little careful reverse engineering, and I was able to create a program that responds to a Rich UI REST request. And it takes nine lines:

QzhbCgiParse( '-v Cust': 'CGII0100': cust: %size(cust):
              bytesRead : dsError);
if (bytesRead > 1);
  cust = %subst( cust: 1: bytesRead-1);
endif;

data = 'Content-Type: text/html' + CRLF + CRLF;
QtmhWrStout(data: %len(data): dsError);

data = '{"result" : "' + 'Name-' +
       %trim(cust) + '"}' + CRLF;
QtmhWrStout(data: %len(data): dsError);

return;

The simplicity of the code is rather impressive. The first line gets the data from the URL, the next three strip off the trailing LF that QzhbCgiParse insists on giving you. The next two lines send the header, the last two send the response formatted as a JSON string. That's all there is to it. There are obviously a couple of prototypes, and the ubiquitous error data structure that is familiar to anybody who codes API calls in RPG, but those can be /COPY'd in. The meat of the code is the eight lines above (nine counting the return).

The code in the test program is even simpler:

testService testService { @RESTBinding
  {baseURI = 
    "http://IRUIHOST/cgi-bin/RUIT1.PGM?Cust=77654"}};
call testService.getName() 
  returning to ts1listen
  onException ServiceLib.serviceExceptionHandler;

It's a standard REST call, except I change the baseRUI to pass the parameters. Now, I haven't gotten around to figuring out how to pass the parameter via the actual method call, but for this particular proof of concept I don't care about that. The point of this exercise is to prove that anything you can do with "traditional" EGL - that is, a web service written in EGL and deployed in an application server that calls an RPG program - can be done using nothing but the Powered by Apache server and standard RPG-CGI - that is, no Java, no WebSphere, nothing you wouldn't have to know for any other approach. You just have to learn the EGL Rich UI syntax.

Now, I wouldn't recommend this approach since if you can write EGL Rich UI you can write host-based EGL just as easily, but if you absolutely cannot run WebSphere or Tomcat, then this will allow you to still use EGL Rich UI.

Nifty, huh?

Let me clean up the example to something a little less trivial and I'll post this project, probably tomorrow sometime. As I noted at the beginning, I'm doing this solely in my free time and I used up most of that time tonight writing this blog post .

See What i Can Do - V2R0

JoePluta — Sun, 30 Aug 2009 23:31:24 GMT

Okay, I'm now in the pre-flight phase of version two. I'll leave V1 alone for the time being, although I may circle back to it later in order to investigate other pure client-side issues. But I want to get right to the core of what's important to EGl and i, calling business logic on the i. The purpose of V2 is to address the issue that EGL Rich UI requires WebSphere (or some other web application server) to run.

That's simply not the case. Rich UI handles both SOAP and REST service calls, which means that it talks to anything that does either of those. Most platforms can create SOAP services. The problem is that SOAP is over-engineered bloatware; the correct answer is to use REST.

Unfortunately, I don't have any examples of using pure RPG-CGI as either a SOAP service provider or a REST service provider. I could use the wizard provided with the standard i5/OS web administration tool to create a "Web Service Server" but that's still a SOAP service. I'm going to try a sidetrack to write my own code that will provide a simple REST response.

As always I'll be relying on groundwork done by others, in this case I'll probably be reviewing and probably liberally re-engineering code from Craig Pelkie and Scott Klement, as well as making use of Chris Laffra's service monitor. I'll need all the help I can get, because this is completely untraveled territory.

Wish me luck - I'll get back to you in a day or two.

See What i Can Do - V1R1

JoePluta — Sat, 29 Aug 2009 19:38:23 GMT

Although still in the "hello world" stage, I think ther are a few basic web functions that I can verify before moving into the more rarified world of business applications.

One problem with a language like EGL (or indeed any program generator) is the potential for lock-in. While it does a lot of things really well and really productively, you have that nagging feeling at the back of your mind that you're going to hit a wall somewhere, and that's when the proverbial other shoe will drop.

For example, you might want to incorporate some nifty widget from the outside world. Typically, this involves hacking the generated code, those hacks then get wiped out the next ttime you generate. This has been the bane of 4GL programmers forever. But EGL is supposed to be better than that - it's supposed to be designed with extensibility in mind. To that end, I used this version (V1R1) to see if I could take advantage of outside code.

To do that, I went to one of the roughly sixteen million web sites that allow you to create free hit counters, and I created one. I then added the generated HTML to my RUI page using the "HTML" widget. The results were expected: the counter works fine.

The new PIF file can be found on the See What i Can Do thread.

See What i Can Do - V1R0

JoePluta — Sat, 29 Aug 2009 18:04:53 GMT

Okay, I think I may have a slight glitch in the process here. I thought I would be able to add files to my blog posts, but I don't see how to do that.

Instead, you can get the file from a discussion in the forums. Go to this forum post.

I'm also going to try to post these into the EGL Exchange, although that's a more involved and less immediate process. Anyway, here's the first one, which is just a Hello World. I'm going to immediately revise it, and you'll see another blog entry on the new version.