|
Thank you for taking the time to answer Trevor.We did a similar project but used a different approach. We used a dataque. Every three or four minutes we poll the website data, and if there is an order there we create a dataque entry. The dataque feeds a program that takes the entry clerk to a familiar place, but with a lot of information already filled in. A lot of the keying is already done by the web user, like name & address, but we don't count that time because they're not on payroll.
We did find substantial improvements in performance. Trevor Perry wrote:
Wow, lots of detailed questions.I used the tools from looksoftware to reface and repurpose the order entry application. The issue was that the green screen application had a large amount of rules that had to be used for order entry. Human interaction is required on each order at this time - to confirm inventory, check price levels, etc.. We left all those in place and automated the entry of orders from their website. Previously, they were receiving an order via email, which they would print and re-key. We asked for a web service from the order website, but they had no concept at the time, so we settled for an FTP file. We used that to automate each order entry.We could have FTP'd the file to the iSeries and coded RPG to process the order, but using the looksoftware tools was incredibly faster than any of the possibilities with the green code. I would expect that with a small amount of RPG effort, we might have been able to enter orders a little faster. To gain a two time or more speed increase would have required a large application development effort.Now we have the best of both worlds - the RPG application has all the rules, and we modify them in one place. The entry itself takes place on the clerk's PC and we have taken advantage of all the desktop integration. We use automatic cut and paste from another desktop application. We automatically create an email from Outlook. We open a web page to confirm the order for the order website. All this is done during the automated process, and the clerk spends an average of 6 clicks to enter an order, rather than all that data entry typing. I do have two development tools, but the maintenance on the automation process has been minor over the last 2 years.Of course, this is simply the first step in modernizing the application. The next step is to integrate the web order entry tightly with the back end RPG order entry application. This will allow inventory levels to be real time, and the order entry process will become just a confirmation of any orders that are flagged as needing attention.----- Original Message ----- From: "Booth Martin"Subject: Re: VisualAge RPG for AS/400?I hear you Trevor. These changes are needed in many of the old legacy applications, no question about it. As Jon said, I am sure you took advantage of all the design choices that improved performance. I am curious though. What is the interface? Browser? Visual Basic? Also, as you say, the application was not so much replaced as it was transformed. As you look back on it do you have a feel for how much transformation could have been made if you'd opted to transform, but use green screen? Would the advantages still have been 5 to 1? Am I reading between the lines here? Are you saying the development time with the tools was also much faster than green screen development?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.