ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Your Recommendations and Experiences, Please.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Your Recommendations and Experiences, Please.

    I would like to hear the experiences and recommendations of anyone who has implemented (or attempted to implement) a brower interface to replace or provide an alternative to green-screen applications.

    For example . . .
    • What tools did you use to build browser-based interfaces?
    • If you used a screen-scraper, did this satisfy the users who complained about the green screens and wanted a GUI instead?
    • Were you able to develop generic routines, or did each green-screen program have to be converted individually?
    • Did you separate business logic and presentation, or do your web aps handle business logic too?


    I would appreciate hearing anything you feel worth mentioning.

    Thanks,

    Ted Holt

  • #2
    Re: Your Recommendations and Experiences, Please.

    We made the decision to work with a business partner BCD. http://www.bcdsoftware.com/
    They have 2 version ? The RPGLE and PHP version. We chose PHP.
    This was a good solution for us because I have some experience with web development and PHP.
    Originally we purchased their portal tool, but have since stopped using it. We chose to write RPGLE programs
    that are called via PHP to validate users at sign-on. Each user is presented a unique set of menu options
    based on elements in a DB2 Table. All the RPGLE calls were written as PHP functions and are nice & easy
    to implement across multiple pages.

    BCD has a tool (at a cost) to convert green screen applications to PHP. I do not have experience with this tool.

    I must add that the help desk at BCD is the best I have ever encountered -- that would be both in & out of this field.

    We have rewritten the original screens and now try to review all requests for data and more often than
    not we write new request using PHP. My company is owned by another much larger one, that in turn owns
    many other like companies. We are number one in the amount of orders written per sales employee.
    Order entry is a green screen application and I do not see this changing in the near future.
    **Note: We do have a PHP version of order entry that is up and running now.

    Because we are running thin clients through the shop area, I can see some of our ?flighting? applications being
    converted over to PHP as well. Each order picker & Hubtex (fancy forklifts) are currently running wireless LXE devices using
    proprietary 5250 emulation to run RPGLE programs.

    The outside folks have all been converted to ipads and are able to connect to IBMi thru SSL and run green
    screen applications. The introduction of the ipads (because of the messy function key handling) has given us
    ammunition to rewrite these applications in PHP.

    With the foundation built using functions and solid well documented PHP code, we can bring any ?ole? PHP developer
    (without IBMi experience) in at any time to write applications and relieve program request backlog.

    I love PHP almost as much as I don?t CLLE..
    Attached Files
    All my answers were extracted from the "Big Dummy's Guide to the As400"
    and I take no responsibility for any of them.

    www.code400.com

    Comment


    • #3
      Re: Your Recommendations and Experiences, Please.

      Thanks, Jamie. We have the RPG version of WebSmart in my shop, & I have to agree 100% about BCD?s customer support. Those guys are fabulous.

      What is the portal tool you mentioned?

      Do your WebSmart PHP aps also handle business logic, or just presentation logic? To put it another way, if you had an RPG program that handled both database processing and the presentation (thru a display file), did you rip out the display file & make the RPG program interface to the PHP ap instead? Or does the PHP ap also do all that I/O (plus decision making & such?)

      Comment


      • #4
        Re: Your Recommendations and Experiences, Please.

        BCD has there own external security portal called NEXUS


        You can setup security in the portal by importing IBM userid's and also create ID's on the fly.
        Because our customers may have 1 to may userid's we purchased the portal to handle this.
        Over time I discovered that I could handle this with RPG calls from the PHP and just eliminated the portal.

        Ted -- We are in our infancy with the tool...
        The intranet was rewritten and it would be mostly for displaying of data....
        but there are date handling functions that allow for changing of delivery dates and order status.

        The shopping cart is pure PHP and does handle many processes that were once done in RPG.
        Data is written to non-production tables and I have written an RPG program that when called from
        the shopping cart "moves" the records to production and handles the HTML email out.

        As we get more and more comfortable with this solution, more applications that update and process
        production data will added to the web menus.

        The rewrite of the RPG version of the outside sales drones menus (which I originally wrote)
        will all be in PHP and there are many places where production data will be manipulated via Ipads...
        -- also I can see tons of decisions being made via PHP on our shop floor. Buying Thin clients with
        linux & ThunderChicken rather that CE & EXPLODER.

        As you can tell I am very excited about the future of PHP in our company.

        I really like that I can still write or use existing RPG within the PHP.
        super simple even I can do it
        All my answers were extracted from the "Big Dummy's Guide to the As400"
        and I take no responsibility for any of them.

        www.code400.com

        Comment


        • #5
          Re: Your Recommendations and Experiences, Please.

          Hi Ted,

          Originally posted by TedHolt
          • What tools did you use to build browser-based interfaces?
          I have done this with many different methods.
          1. I have re-coded applications in an MVC style, and used CGIDEV2 and written my own HTML.
          2. Same as #1, but with PHP on the front-end, and RPG on the back-end.
          3. Same as #1, but with Java on the front-end and RPG on the back-end.
          4. I have re-coded to use an AJAX style, and used ExtJS as a front-end.
          5. I have used a screen-scraper.
          6. I have used an open access tool.


          The first 3 options worked well, but require a TON of work. There's just a lot of work involved in coding the front-end HTML, Javascript and CSS to make everything work the way you want it to with all of the bells and whistles you need. It can be a real time-sink. I did not find that using web-oriented technologies like PHP or Java helped significantly -- in fact, in many ways they slowed me down because of the added complexity of having to call the RPG back-end routines via either database calls or web service calls.

          Option 4 worked much better. I coded the back-end as a REST web service in RPG and the front-end with ExtJS. The big problem here was that ExtJS is very technical, advanced JavaScript coding. I was able to pick it up, but it was not trivial. The other programmers that I worked with at the time were completely lost and unable to maintain this code. Although I found it much quicker to write the front-end with ExtJS vs. coding the HTML/Javascript manually, because the framework did so much for me (sortable columns, nice looking buttons, etc) it still required a lot more work to build my screens vs. a green-screen approach. I tried using Sencha's "Architect" product to build my screens instead, but I found it really complicated and cumbersome.

          The screen-scraper approach was very easy, but also had it's limitations. I know a lot of people who are satisfied with this approach, but personally, I don't like it as much. For example, when IBM i puts out a screen via 5250, you get the image of a screen. The screen scraper can detect where fields stop/start by looking for 5250 attribute codes. But, it doesn't know how to draw a proper scrollbar, for example, because it doesn't know how big your subfile is -- it just knows about one page at a time. It doesn't know the field names, since they aren't sent to the 5250 terminal. It doesn't know which part of the screen is a "Subfile heading" and which parts are just text that happen to be near the subfile. You are still limited by what 5250 can do... for example, you can't really have drag/drop interfaces. You can't put 100 rows of a subfile on the screen at once, because you can't fit 100 rows on a green-screen. So you can do some neat things with a screen-scraper, but you're always held back by the limitations of what works on a 5250 screen. But -- there's no question that a screen-scraper is by far the fastest and easiest way to get a web interface for your programs.

          Finally -- the one I really liked was the open access solution from Profound Logic. In fact, I liked it so much that I applied for (and got) a job at Profound Logic last year. I had offers from other IBM i shops -- but I picked Profound because I liked this product so much that I wanted to be a part of it. It allows you to drag/drop and build a screen in a manner very similar to the way you build applications with languages like Visual Basic or Visual FoxPro, except that it all runs on IBM i, and the output simply renders in a browser. Unlike the CGIDEV2, PHP, Java, ExtJS solutions you don't need to rewrite RPG programs from the ground-up, in fact, the RPG code will work as-is with only the addition of a single F-spec keyword. The screens have to be re-done, but Profound has a converter that can be used to convert the green-screens directly into the new "rich displays", so you only have to convert, not re-write. When designing new screens, it's just drag and drop, you don't need to understand the technologies (Javascript, HTML, CSS) and it's really aimed at being easy for an RPG programmer to pick up and use.

          The designer really makes it easy to build nice looking applications quickly without sacrificing functionality (like you do in a screen-scraper environment.)

          So... I liked Profound's Open Access solution so much that I now work for them. If you'd like, we'd be happy to set up a "Goto Meeting" over the web where we can show you the product and how it works. We also have a screen-scraper product we could demonstrate, too.

          Originally posted by TedHolt
          • If you used a screen-scraper, did this satisfy the users who complained about the green screens and wanted a GUI instead?
          In many (maybe even "most") cases it does, yes. But, personally, I find it limiting, and there are some users who agree with me. One nice thing about Profound's solutions is that our screen-scraper will work together with our rich-display tool, so you can use the screen-scraper at first, and gradually (one-by-one) convert your programs into rich display interfaces. It's a good way to transition.

          Also, we've found that sometimes it's really hard to completely remove the green-screen stuff from a program, because an RPG program might do something like run an IBM command like WRKSPLF that brings up a green-screen. So in our environment, you can use the screen-scraper for stuff like WRKSPLF that you don't have the source for, and the rich displays for RPG programs that you do hve the source code for and want to improve upon.

          Originally posted by TedHolt
          • Were you able to develop generic routines, or did each green-screen program have to be converted individually?
          Maybe I'm being dense, but... Not sure how you could have a "generic routine" for a screen, since each screen has different fields and asks different questions. Since the screens are always different, you'll always end up with a separate piece of source code for each screen, just like you have separate 5250 DDS for each screen today.

          But, at least with Profound, they are using a framework -- which is a set of common routines for displaying things like text entry fields, date fields, subfile grids, etc. Is that what you mean?


          Originally posted by TedHolt
          • Did you separate business logic and presentation, or do your web aps handle business logic too?
          I've done both. Personally, I think the "right" way to do it is to have the business logic separated from the display logic... I think that's important. But, I also see that as a long-term goal, something that will happen gradually over time. It's too much work to change it all at once for all of your applications (unless you have very few applications, I guess!)

          I personally feel strongly about keeping the business logic in RPG, because I just think RPG is a better language for writing business logic.

          However, with Profound's tools, or with any screen-scraper tools, you can certainly keep the business logic and display logic mixed together without changes. This is an easy way to get things up and running with modern screens, and you can work on modernizing the internals of the code gradually over time without the users being any the wiser.

          If you don't use something like open access or a screen-scraper technology, then you pretty much have to rewrite your RPG programs to make them stateless. Most traditional RPG code expects the code to be in complete control of the way the program flows, when to display a screen, etc. And that's the opposite of web technology (which expects the browser to be in control of the flow of the application.) So if you use techologies like CGIDEV2, PHP, Java, ExtJS, etc, you pretty much have to rewrite everything. If you have to rewrite everything, I think it'd be quite foolish if you DIDN'T use separate business logic vs presentation.


          Anyway, please take a look at Profound's offerings: http://www.profoundui.com
          and drop us an e-mail, and ask for a demo (these are set up by our sales department), I'd love to give you a demonstration of our tools: sales AT profoundlogic.com

          Comment


          • #6
            Re: Your Recommendations and Experiences, Please.

            I might have stuff to add to the thread, but I'll have to wait a couple more months before I can do much of it. So I'll just talk generalities for a while.

            We went in various directions looking for satisfactory GUI experiences. An OpsNav GUI/Java plug-in, WebFacing, HTML/Javascript, Eclipse, browser GWT/GXT... we developed multiple forms and multiple looks. All of them worked with varying degrees of effort. We managed it primarily because the initial effort was in separating the business logic from the presentation. Once that was done, we could go in different directions according to whatever Sales/Marketing managed to convince the bosses.

            And that was the only significant driving force. Sales people pounded away on the 'checklists' that prospective customers had, and the single biggest item we were missing early one was "Does the product have a GUI?"

            So we created some.

            As happy as it made Sales/marketing, and their 'prospects' (and it did positively affect sales of product), it was perhaps the biggest waste of time we ever ran into.

            After a few subsequent releases, our Test group began reporting various bugs in GUI versions that no customers ever ran into. In fact, I think only one customer ever asked for any bug fix at all. As more time passed, it wasn't clear why there'd be effectively zero Support calls except common questions during install/upgrade periods. The questions had nothing to do with actual usage, but rather were "Can we run the GUI on Win2K?" and "Do we need a user profile on the AS/400?" and similar.

            But eventually follow-up questionnaires confirmed that practically no one actually cared if GUI was really there as long as the green-screen functions all still worked. We only found one customer who actually used any of the various GUI versions (the OpsNav plug-in!)

            Now, we probably could have gone 100% GUI, and no one would have been too disturbed. It would have been expected and assumed to be natural evolution. But when the actual choice was available, the customers themselves made the decision.

            With some categories of automated functions, apparently a GUI doesn't add anything useful and sometimes it just adds a layer of complexity.

            OTOH, some GUI compatibility was highly successful. Where we saw the greatest success was in reporting modules. Giving output choices of spooled reports, database files or .CSV types of files was very well received and used by essentially all customers. By simply allowing dynamic selection of data (but with defaults) and choice of presentation, everyone got what they wanted. Far more customers were happy with simply being able to use Excel than with anything else we did.

            (Personally, that made me happy because I've never understood straight report generation. The continual collecting of spooled files on outqs, and regular requests to rerun reports because of accidental deletions even though no one had any intention of actually printing them, never made sense to me. The 'information' behind the reports was always where the focus should be in my mind.)

            Anyway, I'll stop rambling. I do have one thing that I think is related and that you and maybe some other members might find interesting. I can only show a couple pieces. This, for example:
            Click image for larger version

Name:	firefox400.JPG
Views:	1
Size:	39.2 KB
ID:	126674
            A fairly skilled co-worker, Ben Peters, has done some experimenting that has kept me very intrigued. That image is an actual portion of a WRKACTJOB display. The function shown is in fact an early Firefox build running in a 7.1 system. It's running under PASE, but running successfully.

            Here's perhaps a more interesting image:
            Click image for larger version

Name:	os400browser.JPG
Views:	1
Size:	50.3 KB
ID:	126675
            That's an image of what the browser is doing. We all wondered how often http://whatsmyuseragent.com/ got to report "OS400" in the User Agent string.

            The image is from the Xterm session, running through the system, that's displaying the browser. That's as much as I can post, but IMO it helps demonstrate possibilities that aren't fully understood yet.

            Other than that, I'd just recommend that lessons learned by others can be important in appropriate circumstances. A big example would be separation of business logic from presentation. GUIs can be useful and important, but they don't solve every problem.

            And finally, even the iSeries Access terminal emulator is a "GUI". It consists primarily of a big, elaborate text-box in the middle; but it's still a "GUI" product. It just shows how flexible a GUI can be.

            Tom
            Tom

            There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

            Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

            Comment


            • #7
              Re: Your Recommendations and Experiences, Please.

              Hi Tim,

              The biggest difference in the different way Scotts states is the EXTJS solution. I agree with Scott that this, from a RPGLE programmers view, has a steep learning curve since EXTJS unlike the other server centric methods are client centric OO javascript.

              In other words it is highly recommended to get education so you get the general architecture and overview in coding EXTJS and before that also obtain a fair knowledge of javascript and the basics in OO javascript. It is worth to mention that learning EXTJS/Sencha Touch is knowledge you can bring into and use on any server platform.

              In EXTJS you actually write a cross browser APP that is executed under the EXT framework running in the browser. Another good thing is that if you learn EXTJS you are very close to have leaned Sencha Touch that is their mobile framework that both can output browser based and native mobile APP?s.

              When you code in EXTJS the server side is actually quite simple and it is reusable if done correctly since the server role basically is reduced to send and/or receive raw data (in XML, JSON or in FORM/POST) through internal AJAX calls in the EXTJS code.

              As Scott states you have to recode the server side programs into stateless REST/CRUD services using SQLRPGLE, PHP or Java but if the BL in your native programs are already modularized it isn?t the big problem.

              To recommend one method from another is actually difficult.

              In the EXTJS/IBM I world there are several frameworks such as Valence, IceBreak, Websydian, RPGUI and my own powerEXT that will start you up but don?t take you the whole way without EXTJS knowledge and you will also find some EXTJS code in other frameworks since you can make advanced functions that are very hard to achieve in any other way.

              From a personal point of view you also have to consider in what degree you want to lock yourself and your own knowledgebase into IBM I proprietaries and where jobs unfortunately isn?t exactly hanging on the trees these days.

              The bottom line is that there is no ?one strategy fits all? ? you have to choose what in every aspect fits you, I do agree with Scott that EXTJS has steep learning curve from our IBM I perspective, but I do disagrees that EXTJS is for the few and for the record it already over 2.000.000 programmers WW is using it!

              Comment


              • #8
                Re: Your Recommendations and Experiences, Please.

                Henrik has summed up what I like about ExtJS pretty completely. I've been dabbling with CGIDEV2 and ExtJS for years. For the most part I worked on these projects on my own with plenty of time to devote towards them, so we were never re-working green screen legacy programs at mass to the web. Most often they were new programs with new functionality, so we'd start from scratch. CGIDEV2 has always been a component I've worked with. I found it easy to learn and was comfortable still working in RPG programs. At a previous job we wrote a portal to allow customers to view statements and invoices. That was done complete with CGIDEV2, MMAIL and hand-written HTML and Javascript. As others have pointed out browser applications can be a learning curve and a challenge to make the same app look "right" across browsers. Sometimes that's even a challenge when presenting in the same browser, but different versions! With my older CGIDEV2 browser programs I'd really hate to have to go back in and change the look and feel of the old applications now since the HTML code is so embedded with the RPG. It can definitely be done, but would be tedious.

                For the past few years I've been developing completely with ExtJS as our front-end and SQLRPGLE programs using CGIDEV2 to do the communications on the back-end. Keeping the front-end separate from the back-end, reworking the look and feel would be a snap. Now that my ExtJS knowledge is getting better, I find that I can roll out a grid, similar to a subfile in a similar amount of time. As many have pointed out, there is quite a learning curve and even 3-4 years into working with ExtJS ... I'd still like to go and get formal training to learn how to do it "right" and get into MVC. I made the choice to learn ExtJS directly, because it can be used with many back-end platforms. You could always get a front-end ExtJS guy to work with your back-end RPG/PHP guy and roll out work pretty quickly as I know a shop or two using that set up.

                Screen shot of test data on results panel with ExtJS 4 and Azzurra theme so that it's not so M$ Outlook looking!
                Attached Files
                Your friends list is empty!

                Comment


                • #9
                  Re: Your Recommendations and Experiences, Please.

                  Originally posted by jamief View Post
                  I love PHP almost as much as I don’t CLLE..

                  Your friends list is empty!

                  Comment

                  Working...
                  X