Farmers Achieve Fine-Grain Control with RSP from ProData

September 30, 2008 Alex Woodie

When the Farmer’s Cooperative needed an easy way to enable farmers to access basic account information about their corn and soybean positions from the comfort of a Web browser, they knew a couple of things they didn’t want. They didn’t want to learn a new language like Java or PHP to access their i5/OS server, and they didn’t want to muck around with their DDS files. When the Iowa non-profit organization discovered ProData Computer Services‘ RPG Server Pages (RSP), they found a tool that suited them well.

The Farmers Cooperative (FC) is an agriculture co-op dedicated to serving farmers and ranchers in Iowa. Its main business is storing, buying, and selling corn and soybean for its 5,800 members from about 50 offices spread across the state. It also operates an agronomy department that markets scientific crop services to its members.

The FC runs its business on a combination of X86 servers and IBM System i servers running custom-developer ERP applications. It maintains a small IT staff of three full-time RPG programmers and four full-time employees working on the network and Intel-based systems.

Prior to its first attempt to Web-enable a portion of its RPG applications, the FC would communicate information to members in one of two ways. They would either send out a report, or farmers could pick up the phone and call one of the FC’s 350 workers and get a real-time quote on their grain positions. Obviously, these were time-consuming business processes that could be made much more efficient by putting the information on the Web.

The FC’s first experience with a Web-enablement project, which involved IBM’s WebFacing Tool, did not go very well, and had to be scrapped, according to Jon Sinner, a programmer-systems analyst with the FC.

“The problem was, as we were changing things on the background, we always forgot to go out and change things on the Web, and then farmers were seeing things that were not accurate,” Sinner says. “And after Randy [the original developer] left, we couldn’t go out there, because they destroyed the projects that were used on his PC. They didn’t know they had to keep those.”

Another drawback for the FC with the WebFacing tool was it ran under the QINTER subsystem. “During our backup periods, we shut that system down, so we were shutting down our Web site every night, which was not cool,” Sinner says.

The unpleasant experience with IBM’s WebFacing Tool made one thing clear, Sinner says–the next time the FC tried to Web-enable their RPG applications, they would pick a tool that would enable the group to serve both green screens and Web screens from the same development effort. “So that’s what started us looking at the RSP tool.”

The RSP Experience

Sinner already knew ProData’s Schadd Gray, the original developer of RSP. That relationship led Gray to createing a demo showing Sinner what using RSP could do for FC’s data. The demo was ready in a couple of days, and Sinner used it to impress FC’s senior management.

The application was a customer positions Web page that allowed farmers to see exactly how much corn or soy they have under contract with the FC, and how it’s stored, such as in an elevator or an open bin. It also shows the farmer how his contract is set up, and at what price point the FC is obligated to buy the grain from the farmer. This information is communicated through pop-up windows, drop-down boxes, images, and other Web 2.0-style development techniques.

“We just picked one of the contract types, because we have so many, and we did that really quickly. And they really liked what they saw,” Sinner says. “We decided to license the product at that point. Our entire customer Web site was then converted to RSP. Schadd helped me to do that, and I did a lot of it, too.”

Sinner learned the RSP product on the fly, and also picked up the needed HTML skills as he went along. “I had no Web skills at all, none at all. I’ve learned a lot of HTML, and I’ve learned some JavaScript. But the rest of it is all RPG code,” he says. “As long as you can write an RPG code and you’re willing to learn a little bit of HTML, this is no big deal.”

As far as the RSP product is concerned, the most important thing was to learn how to use the RSP functions. “There are less than 20 of these that you have to learn, and he’s got them well documented,” Sinner says. “They’re in a handy little ‘help thing’ on his screen.”

The biggest advantage to using RSP is its adherence to RPG and the fact that it maintains display logic in a single repository, Sinner says. “So the RPG side will call a function that provides some inventory balance, and present it on the green screen. That same function is called on the Web site, so when I change one of my applications, I have changed both of my applications. I reuse the code,” he says.

“That way I don’t have two separate pieces of code to provide that piece of information,” he continues. “I have one. So I don’t have to do a lot of extra maintenance, because somebody said, ‘Hey include this calculation in your inventory balance factor.’ I put it into one place, and it’s reflected in both spots. And that’s why we like it. We’re a small staff. And don’t have enough people to make changes in multiple places.”

New RSP Projects

Today, the FC has developed four or five major application built in RSP, with relatively little trauma. Farmers can log onto the FC’s Web site at www.fccoop.com and access their account information at any time of the day.

A few issues with JavaScript have popped up, but Sinner says ProData has been very helpful in resolving the problems. The fact that the product relies on standard technologies like HTML and JavaScript is a blessing. “There’s tons of stuff on the Web to help you. And you can always swipe somebody’s little JavaScript program and throw it in there,” he says.

Sinner is nearing completion on the second major RSP project at the FC: a Web-based invoice imaging and workflow system built on RSP.

The new application would provide a standardized way for workers in each of the FC’s 50 or so regional offices to submit invoices for payment. Currently, the FC utilizes a slow and error-prone paper-based system that requires workers to manually input invoices received from suppliers and code them correctly for the accounts payable (AP) system. The company relies on the U.S. Postal Service to mail the invoices to the FC’s headquarters in Farnhamville.

Under the new system, developed in RSP, the invoices are scanned into the computer and saved as a PDF document. An RPG program then distributes the documents to location managers, who must code them correctly. When the coding is finished, and all the costs have been broken out according to the organization’s rules, then the documents are routed directly into the AP system for payment.

The new system should save a lot of time, Sinner says. “We’re centralizing this process. We’re getting rid of the whole snail mail process. It’s all going to be done over the Web. And integrate straight into AP,” he says.

Sinner says the FC’s new RSP-based Web applications look as good as applications built in Java or PHP, but without the big programmer budgets those technologies would command. “I would recommend it to anybody. You do not lose your investment in the iSeries. You can continue to build on the investment you already have.”

The fact that the FC paid about $4,600 for the RSP tools (not including Schadd Gray’s billable hours for development services) is amazing to Sinner. “That’s awful doggone inexpensive for me. It’s way under the “I gotta go to the next level’ level,” he says. “It works well for us; it really does.”