Eagle Systems, Inc. (ESI) is part of the Eagle Group based in Wenatchee, Washington, USA and a leader in intermodal transportation with locations throughout the USA and Canada and operating authority in virtually all states. Using the Visual LANSA Framework, ESI built a dispatch system, called eDray, which integrates with its core Synon 2E-based logistics system. LANSA Integrator is used to exchange dispatch information via SMS with drivers and send real-time EDI status updates to customers.
Larry Ronhovde, President of Eagle Information Systems, says, “Our decision to use Visual LANSA Framework saved us a lot of time, especially considering we are new to large Windows-based projects. The framework acts like an on-site mentor who helps get things done the right way the first time. It gave us a head start on proper coding techniques and standards, instead of starting with a blank page.”
The framework acts like an on-site mentor who helps get things done the right way the first time. It gave us a head start on proper coding techniques and standards, instead of starting with a blank page.
Intermodal transportation involves last-mile logistics, such as ramping and de-ramping containers at railway hubs or shipping ports, delivering containers by truck to the final destination and returning empty containers to the railroad or shipping company, typically over short distances.
“Intermodal trucking is to regular over-the-road trucking what retail is to distribution,” explains Ronhovde who supervises application development and support for the Eagle Group. “In regular transportation, a driver may take a week to carry a load across the country. But in intermodal transportation, a single truck driver may move several loads per day. The high frequency and large number of loads that we handle each day require a high degree of coordination by our dispatchers.”
ESI’s paper-based dispatch system was error prone and did not integrate with other systems. T-shaped cards representing a load were moved around a large planning board by dispatchers who wrote notes on them indicating schedule, destination, driver and status. While billing information from the T-cards was manually entered into the core iSeries system, it was of little use for dispatch management or history and the physical T-cards were kept for five to ten years.
Chreston Knutson, Director of Information Systems at ESI, says, “The only way to access information was to look at the board in each dispatch terminal. Occasionally a driver would call after office hours for clarification on a load, but we couldn’t look it up on the computer.”
ESI wanted to improve the efficiency and capacity of their dispatch function by replacing the manual card system with a graphical drag-and-drop Windows solution that integrated with its core Synon 2E iSeries application.
Ronhovde evaluated several development tools before selecting Visual LANSA. “We looked at Java and also at the 2E follow-on product Coolplex. In terms of the graphical interface, drag-and-drop capability and iSeries integration, Visual LANSA was a clear winner.”
As a Synon 2E user, Ronhovde was already accustomed to consistency in its development and maintenance environment, so improved productivity was crucial. “With Visual LANSA, and even more so with Visual LANSA Framework, we can rapidly create intuitive systems that are easy to maintain,” says Ronhovde.
We looked at Java and also at the 2E follow-on product Coolplex. In terms of the graphical interface, drag-and-drop capability and iSeries integration, Visual LANSA was a clear winner.
Using Visual LANSA Framework, Ronhovde’s team developed a Windows-based dispatch system, called eDray, which interfaces directly with the iSeries database of its core Synon 2E logistics and billing system.
The graphical interface creatively mimics the card-based manual system. Small boxes, representing containers, can be dragged from one location to another and right-clicked to select functions like re-scheduling and changing drivers or status. Colors group containers, while the location on the form indicates a geographic area or containers status, progressing through open, available-for-pick-up, active, when ESI takes possession, to delivered to the customer and finally to completed, when the empty container is returned.
“The new interface retains all the benefits and flexibility of the manual T-card system, but is more accurate and the information can be accessed electronically. It also eliminates the need to enter data manually into the billing system,” says Knutson.
“In fact, during pilot trials we uncovered small procedures that, until the physical T-cards were gone, nobody knew the dispatchers were following. We had to cater for all these exceptions in eDray.”
“The Visual LANSA Framework shielded our newly trained LANSA developer from the complexities of inter-form communication, navigation and form management,” says Ronhovde.
“It gave us a head start on proper coding techniques and standards, especially since eDray was our first major event-driven development project. Instead of starting with a blank page, we started with a framework into which we could add our business objects, filters, lists and detail forms.”
“The framework approach saved us a significant amount of time. We didn’t have to deal with a lot of the base decisions and base coding requirements. We could just focus on building the business application since we could use the Framework’s default settings for security, forms design, message handling, and so on.”
“What we are gaining with LANSA is versatility in development, in terms of our ability to add or change functionality. For example, LANSA’s Repository and Object Access Modules, lets us make database changes without having to go back and re-visit every existing function.”
“It took just one dedicated LANSA developer about nine months to develop and implement the system. And we continue to drive and maintain the eDray system with just a single developer. So, from a productivity standpoint, we achieved a lot with Visual LANSA. It is hard to be exact, but I am sure it saved us a couple of months,” says Ronhovde.
The new interface retains all the benefits and flexibility of the manual T-card system, but is more accurate and the information can be accessed electronically. It also eliminates the need to enter data manually into the billing system.
“At the moment truck drivers call our dispatchers and write down load details, then call again when they deliver their load so the dispatcher can record the status change. Dealing with so many phone calls and sometimes unclear lines, it is hard to avoid mistakes,” says Knutson.
ESI is currently piloting automated SMS messaging to exchange load details with driver’s cell phones. LANSA Integrator exchanges XML transactions via a Java-based freeware application from ConWare to send and receive SMS messages with details about the container, when and where to pick it up, where to deliver it.
“We considered PDAs with a larger display, but the transactions, especially the reply messages which are just an automatically date and time stamped status update, are very short.”
“Informing the drivers via SMS and getting status updates back electronically will dramatically reduce the number of phone calls and significantly improve efficiency,” adds Knutson. “Eventually the dispatcher will only be called for missed appointments, broken containers or other exceptional situations.”
ESI also uses LANSA Integrator and Gentran to send its customers container status updates via EDI transactions when a container is picked-up, when it leaves the ramp and when it is delivered. Currently, the EDI transactions are generated when the driver calls the dispatcher who updates the system. But when the SMS-based messaging is fully implemented, this will happen in real time.
Informing the drivers via SMS and getting status updates back electronically will dramatically reduce the number of phone calls and significantly improve efficiency.
“Our decision to use LANSA’s framework environment has saved us an awful lot of time, especially considering we are fairly new to large Windows-based projects. The framework acts like having a mentor on site that helps you to do things done the right way the first time. It gave us a head start on proper coding techniques and standards, instead of starting with a blank page,” says Ronhovde.
“We want to move all the 5250 applications used at the terminals to LANSA. Redeveloping such a huge number of 2E and RPG programs will take us a long time, during which the operations people at the terminals would have to live in both systems and switch continuously between Visual LANSA rich-client programs and the traditional 5250 screens.”
“We are currently doing a LANSA RAMP proof of concept to provide a modernization shortcut by letting our people at the terminals access re-animated versions of the existing 5250 screens through a single, consistent, easy-to-navigate graphical application environment.”
“RAMP should really shorten the amount of time our users need to bounce between Windows and 5250 navigation while we redevelop our 2E and RPG programs in LANSA.”
“In addition, RAMP will help us identify those functions that we should rewrite in Visual LANSA and those that we don’t really have to worry about and can simply reface.”
“Ultimately we plan to develop everything with Visual LANSA Framework. It will make our team more effective to have everything in one place and improve long-term maintainability. I feel confident that our investment in LANSA is the right one,” concludes Ronhovde.
Ultimately we plan to develop everything with Visual LANSA Framework. It will make our team more effective to have everything in one place and improve long-term maintainability.
Eagle has recently implemented NetSuite Financials, a cloud-based solution, but will keep using its heavily customized IBM i-based ERP system to run its transportation management business. To synchronize and integrate the two disparate systems in this hybrid cloud environment, Eagle uses LANSA Composer and Web services.
Eagle is also using LANSA Composer to automate EDI and other transactions with its partners and to streamline the individual process flows and FTP transmissions with its container maintenance customers.