[UPCOMING WEBINARS] Save on Development Costs and Open Up Your IBM i via APIs. REGISTER NOW
[UPCOMING WEBINARS] Save on Development Costs and Open Up Your IBM i via APIs. REGISTER NOW.
Home ยป System Integration ยป Data and Process Integration ยป What’s old is new again
Home / Blog / What’s old is new again

What’s old is new again

by | Jun 24, 2013 | Application Modernization, Data and Process Integration | 0 comments

Guest Blogger: Tom Mavroidis, president of NTM Consulting Incorporated

As part of Tomโ€™s portfolio he manages the Computer Department for ITWAL Limited, Canadaโ€™s national network of independent distributors. In this article Tom shares how multiple vendors worked together to deliver a successful modernization solution for ITWAL.

When we were asked to take 40 years of custom development, hundreds of patches, thousands of lines of code and business rules, mix them all up and come out at the other end with a streamlined integrated customer ordering portal we were thrilled. Finally, we would have an opportunity to review the areas of code which have caused us the most grief over the years and eliminate miles of legacy code lurking under the covers. We agreed that it was a fabulous idea not realizing that we only had four months to get it done before our annual buying show. You could have heard a pin drop as everyone started edging towards the exit door prompted by my lead. How in the world could we expect the team to come together to define, let alone deliver a project so bold that it touched almost every area in the operation? Time was short so we had to get busy.

As technology matures, budgets seem to be tighter and demands greater, it must have something to do with todayโ€™s expectations and the tremendous press that โ€œTechโ€ companies dole out. It becomes increasingly important to use proven tools and techniques right at the onset of the project if you expect to have any chance of success. Part of our extended toolkit affords us the ability to outsource the portions of the project that we cannot comfortably handle in-house.

With the overwhelming success of ICON (ITWAL Custom Ordering Network) it was assumed that we could deliver an equally impressive extension without too much difficulty, but this would prove to be a formidable task far greater than anyone imagined.ย Some key design requirements were:

  • Enable ITWAL to standardize their electronic data collection methods and create a single point of entry into their main processing system.
  • Decommissioning of the external Electronic Commerce System and EDI server and running it natively on the IBM i.
  • Provide EDI access to any member/customer who was EDI compliant.
  • Lay the foundation for zero operator redundancy (this insures that at least 3 people can interchangeably perform every operations job in the computer department).
The ICON (ITWAL Custom Ordering Network) system offers focused functionality that targets directly what it is that members need to do to place an order.

The ICON (ITWAL Custom Ordering Network) system offers focused functionality that targets directly what it is that members need to do to place an order.

One of the objectives for this stage was to prepare for future succession planning, such that at no one stage of ITWALโ€™s ordering and procuring processes there is dependency on a single person. Daily operations had become second nature to career users who take for granted much of the experience they have gained through years of repetition and consider it common knowledge. ย Trying to put to paper the details of your day to day tasks becomes tedious and detailing it so a programmer can produce a working final product is daunting.

As with most order systems that evolve over time, there were far too many ways for a member/customer to submit their order and multiple works in process files in play with not one standard set of input files. The IBM i handled the day-to-day processing; the electronic commerce system maintained B2B transactions between customer/members, and the quasi-custom EDI system posted directly to the core of the IBM i. Additionally, there was a custom translator for those who did not fully comply with EDI standards allowing for some strange codes to come across the pipe. Developing for the future meant adopting a standards-based approach that would serve to both document the existing processes and allow new methods to be introduced easily. This effectively lays the groundwork until the next refresh.

Before starting on a project of this magnitude, some hard decisions had to be made so we took time and laid down steadfast rules that everyone had to agree on for us to move forward. There were some challenges as members/customers had to make changes to their current order interface so they would be compliant with our new platform. ย Decisions included things such as offering only two methods of order input into the system instead of the anything goes approach. We would allow either an order entered via the Portal or electronically via EDI. All orders coming into the system would be visible via the portal no matter how they were placed.

The Project

This project proved to be challenging not only from a business perspective, but also as a design goal. A logical reworking of the underlying data files had to be made to allow for integration of new features and set the path for future growth. ย This required large portions of the existing system to be redesigned, including the fact that the Accounting software no longer lived on the IBM i, but on a Windows server running Sage 300 ERP (formerly Sage ERP Accpac). ย A secure method to query the Sage 300 ERP server for invoice information was needed and to further complicate things, the existing EDI processing had been custom built in code for almost each trading partner with no two being identical.

So before the fun of modernization was to begin we had to align four development groups together and have them point in the same direction, this called for a town meeting. Guests included representatives from each group:

  • LANSA for the web based transaction processing system and EDI
  • Enflexwork Technologies for the IBM i Java pivot tables (used by IBM SPSS Statistics Processor)
  • BAASS Business Solutions ย for interfacing with its Sage 300 ERP ย accounting solution
  • Along with the internal ITWAL teams – the programming department for the business rules and legacy interface, purchasing, customer service and marketing.

Each group was specialist in their respective field, but no one had much knowledge of the otherโ€™s involvement. ย Our good fortune was in having an IBM i as the root system which allowed us the ability to merge multiple technologies and deliver them to the end user in one standard interface. The customer doesn’t know or care where the data is coming from, but only that they can securely access their data in real time without too much fuss.

LANSA services were deployed to develop the web based solution to our end users via a portal. BAASS Business Solutions developed the hooks which post and pull from the Sage 300 ERP server via stored procedure SQL calls. Enflexwork created the EXCEL pivot tables on the IBM i that run in a JVM and our internal team created the environment that allowed all these processes to talk to each other. Further improvements allowed for the posting of orders entered via the order desk using traditional green screen entry and have the details posted as if the order was entered via the Portal. All systems were to be fully integrated so the member/customer had full visibility of order status at a glance.

The Outcome

With our objective to retain the same family of products, we decided on deploying the LANSA Composer product to handle our EDI processing along with the LANSA AS2 Direct product for transport. Although the primary attraction to both LANSA Composer and AS2 direct product was how seamless they fit into the Lansa frontend, one of the greatest advantages was that they lived on the IBM i and could be accessed via the same proxy device which serves our ecommerce site. Not only does this ensure that our IBM i is not directly connected to the web, but it allows us to consolidate the number of servers we require. ย As an added bonus our programmers can access the data natively using RPG in case they want to push out a quick report or two. This also reduces maintenance headaches, consolidates backups and reduces costs by ย maintaining fewer pieces of hardware.

For network redundancy we chose two points of presence to eliminate a single point of failure. Automated failover of networks was not a requirement since the audience is a closed group and the secondary URL can be accessed instantly in case of difficulty. The IBM i is configured with Raid 6 to give us an added level of resiliency eliminating the need to mirror, and we opted for 99% uptime which gives us ample time to promote our development box to production in case of failure.

The IBM i is configured with Raid 6, providing an added level of resiliency.

The IBM i is configured with Raid 6, providing an added level of resiliency.

Hindsight being what it is, I can confidently say that this time around there were no surprises. Although timing became an issue due to the short go-live date and especially tense once we hit the point of no return, but almost everything went as planned. ย If it wasnโ€™t for the complete dedication of the entire group who participated in this project, it would have never have been completed in time.

Now, a few months later, everything is smooth sailing. While everyone who participated on the project deserves thanks, a special thanks to LANSA, BAASS Business Solutions and Enflexwork who were always on our side at a momentโ€™s notice when the need arose.

RECOMMENDED POSTS

0 Comments

Submit a Comment

Table of Contents