Getting Started

[corvair61]

Our shop has two developers.

We are both seasoned (hahaha) but neither of us has bridged bringing the Web to the system.

What we want to do:

We have over 100 stores not connected to the IBM machine (what's it called now?). Each store has limited credit available. Usually to civic organizations and churches and such.

As they come into the store and want to use their credit the store has some cumbersome process that verifies them and prints out a document they can then use at the register.

We want to create a website they can open to get direct access to our IBMi system, using RPG.

We will verify the information and print their credentials. Not too complicated.

Can someone give me a quick guideline as to where to start?

Maybe a Start here, then this, then this type of thing?

I see the CGIDEV forums. Is this outdated or still relevant?

Thanks in advance for any help.

[chris_hird]

Re: Getting Started

I would use PHP to build the interface, no need for RPG if you have the credit limits in a file and have the HTTP server running on the IBMi. Simply use the ability to use DB2 connectors in PHP to access the data especially if this is going to be a read only operation. If you need to know more let me know as we have a similar process we have just implemented for another client that needed to know stock positions.

Chris..

[danlong005]

Re: Getting Started

I agree with Chris. If you have done any RPG Free then PHP is a good place to go with your web stuff. I am pasting a good PHP tutorial for beginners in here. Also I am putting the link to zend(where you can get PHP for the i).

http://www.webmonkey.com/2010/02/php...for_beginners/
http://www.zend.com/en/solutions/mod...hp-get-started

[JonBoy]

Re: Getting Started

I wrote a series of articles which introduce PHP from an RPG perspective. iProDeveloper bundled it as a $15 ebook here: http://iprodeveloper.com/php-rpg-perspective

Or you can just read the individual articles:

Part 1: http://www.iprodeveloper.com/article...e-basics-64331
Part 2: http://www.iprodeveloper.com/article...unctions-64526

Part 3: http://www.iprodeveloper.com/article...unctions-64684

Part 4: http://www.iprodeveloper.com/article...otpourri-64863

Part 5: http://www.iprodeveloper.com/article...e-access-65023

Part 6: http://www.iprodeveloper.com/article...ose-ends-65253

RPG is also a perfectly valid approach, but if you are entering the web world for the first time you will find a lot more PHP assistance available than RPG CGI.

[Scott Klement]

Re: Getting Started

I have the opposite opinion. While PHP makes it easy to embed HTML in your programs, tools like CGIDEV2 give you that same capability in RPG. But, switching to PHP means that it's much more cumbersome to write business logic, database logic, etc. It also means you need at least a basic familiarity with the Unix environment, because it does not run in the native IBM i world, but rather runs in PASE which emulates AIX (IBM's Unix) in an environment. Using PHP, you won't have the world that you're used to having of call stacks, job logs, etc, thus you're losing out on what I consider to be some of the key features of the IBM i operating system.

In today's world, few people still code HTML inside their applications. The more modern approach is to use a framework, which means you won't be coding HTML in your applications anyway, rather you'll be outputting things like JSON or XML. And you'll output the exact same JSON, XML (or HTML, JavaScript, CSS if you're still doing it that way) from RPG that you would output in PHP. So, in my opinion, it makes more sense to use the languages that make it easiest to do your database and business logic, and I've found RPG to be the easiest way to do that.

IMHO, the big advantage to stuff like PHP is that it's cross-platform. So if you wanted to move the front end to a different platform, that would be one good reason to use PHP. Another good reason is that there is a larger base of open source tools available for PHP, so you can get the existing tools (Wikis, Shopping Carts, CRM packages, etc) and run them on IBM i. These are good things, but for the most part, for my own applications, I would prefer RPG over PHP.

[JonBoy]

Re: Getting Started

In today's world, few people still code HTML inside their applications. The more modern approach is to use a framework, which means you won't be coding HTML in your applications anyway, rather you'll be outputting things like JSON or XML. ...

Not often I get to disagree even partly with Scott but ...

RPG is by far the best for business logic. No argument. But in the OP's question it did not sound like a lot of processing was required. In his case it sounds as if one or two stored procedures would do the job and they are not hard to call from PHP.

Agree everything is going towards JSON etc. (Including a lot of things that have zero need for the added complexity) and frameworks are certainly the way to go. Indeed
_if_ there were a number of RPG frameworks I would agree completely with Scott. But there aren't. I'm only aware of two that are "free" in the RPG world. Valence from CNX (https://www.cnxcorp.com/valence/) and Renaissance from Coraltree (http://www.renaissanceframework.com/). If there was a free GUI designer for it I guess we could also count Profound's OS UI tools but as far as I know there isn't and without a designer it is hard to build framework based apps.

It is also a lot easier to hire PHP talent than it is to find RPGers that can code for the web.

[MichaelCatalani]

Re: Getting Started

Below are some live examples of the different ways you can have an RPG program either serve out a web page, respond to Ajax calls from a webpage, or communicate through webservices to RPG.

I agree with Scott on the approach. Quite frankly, I can spin up an HTTP server instance, throw a static page on the server which makes a CGI call to an RPG program to get some data based off of a command button click, and create an RPG program that can be invoked, read the input query string, and output the data back out to the HTML page, in about 30 minutes. In fact, my suggestion would be to do just that. CGIDEV used to have examples on how to do all of that. I dont use CGIDEV myself (I have my own suite of service programs that create JSON, XML, HTML, etc), but that would probably be the quickest start for you guys. And you would be doing everything in RPG like you are used to.

I would clarify some of your requirements as well. The one thing that caught my eye is that entities from the outside world need access, and then to print something off to take to the store. If I read that correctly, then this could be accomplished by generating the printer output by overriding the printer file to *PDF, copy the spool file to the IFS, and then stream that to the browser. This will allow the customer to print / email / viw the PDF document from which ever browser / printer setup they have. Again, not overly difficult with this approach.

Below are some examples of how I have created a browser front end and have it communicate to an RPG backend. Modern front ends almost always utilize some sort of framework. In the examples below, I have some frameworks, and in some cases, I generate the browser front end from the back end.


http://www.AcceptanceInsurance.com (Responsive Framework Talking To RPG Webservices)
If you click "Get Quote", and enter a zipcode in one of the states we write business in, you will see the process in action. (We write business in AL, FL, GA, IL, IN, OH, PA, SC, TN, TX, and VA) This is a "responsive" website , meaning that the website will respond to the footprint of the browser it is executing in. This enables the same website to handle browsers on smart phones, kindles, all the way to 1080p monitors. The responsive website communicates to an RPG backend consisting of webservices. The website uses angular and the twitter responsive framework. RPG not only drives the business logic (there is not one iota of business logic in the front end), the website completely responds to commands from the backend as far as each view it needs to display, and what needs to be on that view. Every piece of information, including the data in the list boxes, are being sent via a webservice. The beauty of this design means we can make a majority of website changes without modifying the front end at all. Which is great, because there are some weeks where we can push more than a dozen website modification to production. This is one facet of enterprise development that is often missed; you do not want to make front end modifications if you dont have to. It is much more difficult and cumbersome to push a front end modification than it is to push a backend modification.

http://provatosys.com/Bid.html Serving A Static Page Which Makes Ajax Calls Via CGI
This example is a static HTML page on a simple HTTP Apache server. The HTML page makes an ajax call to an RPG program via CGI in order to post updates. The type of ajax call being made here is known as a pseudo-push or long polling. The page immediately makes an ajax call, passing a last update key to the RPG program. The RPG program looks at the incoming key to see if it is different. If its the same key, the RPG program delays for about a tenth of a second, and checks again. Once the keys are different, the RPG program pushes the new key and data back out to the browser.

http://provatosys.com/gui/DiskPerformance.html Sencha Framework With CGI Ajax Calls
This is a live view of the disk drives on my machine. You may have to watch it for 30 seconds or so to see the drive activity. This is a static html page loaded on an HTTP Apache server instance, which contains a Sencha animated chart. This chart is updated via an ajax call, with a simple string of data coming back from RPG. I have another version of this view on my corporate boxes, which includes processor activity, and the data returned is in JSON. I cant link a live page, but below is a screen shot of it.




http://www.cpjungle.com RPG CGI Driven

This is a very old website design (originated in the 90's) where every page after the first index page is completely created by RPG. This was really cool back in the day, but you do not want to design this way today. In this example, the html, css, and in some case javascript is all generated by RPG and streamed out. An RPG program is invoked via CGI, and that program looks at the query string parameters passed through the STIDIN to see what action it needs to take. For instance, the link http://cpjungle.com/cgi-bin/catalog?CATEGORY=SUPPL calls an RPG program called "CATALOG", and passes a querystring parameter of CATEGORY=SUPPL. This tells the RPG program that the customer wants to see the catalog for the "Supplies" category. The RPG program would then create the HTML page for supplies and stream that back out. Again, you do not want to code a system this way today. (You basically dont want your entire front end stuffed into the backend).


http://bootstrapbay.com/preview/nift...mplate-B61222B Nifty Framework From BoostrapBay

I cant show a live example of our corporate application portal, but I can show you the framework we used to develop it. The application portal is where our modern applications are launched from. These applications are browser based which communicate to an RPG backend just like our website. We have modified this framework to fit our needs. The left hand side contains a navigation window to hold the menu for the logged in user. Once a user signs in, the menu tree fills out with all of their available menu options. This nav window is collapsible to free up real-estate, which is really helpful for mobile devices and lower resolution monitors. The right hand side has a "nag" window that can be automatically opened from the backend, and this contains quick access action items for the user. The center of the display was modified to contain a tab panel, where multiple applications can be accessed and toggled through at the same time.

I wanted to show this framework off to give you an idea of what a framework can give you. For $20, we received a framework that was responsive (works on mobile devices as well as desktops) and had a layout very similar to what we were looking for. It gave us a giant head start on developing the portal so that we did not have to write the entire portal from scratch. And our users and senior team will have access to it anywhere, including their mobile devices.

There are different frameworks out there, that handle different parts of the front end development. The beauty in all of this is that it does not matter which front end or framework we use, we can use the same backend for all of it. Which is why I would stick to using an RPG backend like what Scott suggested. Front end technology is changing at a feverish pace in order to deliver new technologies across all browsers. You cant keep your sanity on front end development right now, but you can keep your sanity, and all your code and business logic, on the backend.

[corvair61]

Re: Getting Started

I agree with Chris. If you have done any RPG Free then PHP is a good place to go with your web stuff. I am pasting a good PHP tutorial for beginners in here. Also I am putting the link to zend(where you can get PHP for the i).

http://www.webmonkey.com/2010/02/php...for_beginners/
http://www.zend.com/en/solutions/mod...hp-get-started

Thanks. I've had some PHP training , I just haven't used it yet. Obviously this would be a good opportunity.

I'm aware the Zend server comes with the i. Is there a cost anywhere? I'm trying to get this off the ground without asking for money other than my time if that is possible.

I hadn't responded had a chance to really spend some time on this until today.

I've done some reading.

Feeling like a grain of sand on a beach right now.

[corvair61]

Re: Getting Started

Update:

I used CGIDEV.

I have created a series of pages where the manage/user at a store can search for a company in the AR system and select down to authorized individuals and on the last page they print the credentials along with a barcode.

This is taken to the register and the cashier will scan the barcode for customer details, which will be turned around and fed back into receivables with the purchase amount.

I am not finished and am sure to hit more of the walls I've stared at already, but the working shell is in place and management is extremely pleased.

Thanks for the suggestions.