HelpSystems’ Application Integration Begins With GUI

November 16, 2015 Dan Burger

Almost every IBM midrange shop faces integration issues. The next piece of the IT puzzle has to fit in with existing environment, or the system that was functional 15 years ago requires modernization to make it functional today and into the foreseeable future. You’re lucky if you are only dealing with one piece of the puzzle at a time. In fact, that rarely happens. You have to sort through a pile of priorities and make a plan. You need a road map.

Integration lessons come in all shapes and sizes and varying degrees of difficulty. Sometimes we learn quickly and other times it takes repeated blows to the head or kicks to the seat of the pants before we fully grasp the correct answer.

At HelpSystems, one of the largest IBM i ISVs, integration is a big deal. This is a company with a lot on its plate. Not that long ago it had a singular product line of system automation tools called Robot. But it has grown through acquisition into many other areas including security, business intelligence, and document management. It also acquired much of its competition in the systems automation arena. Matt Bresnan, vice president of development, directs an ongoing integration project across all the product brands.

It sounds like a big job, and it is, but it shares many similarities with integration projects that IBM i shops everywhere are dealing with on a day to day basis.

Bresnan looks at the product integration from front-end and back-end perspectives that are crucial to a long-term product roadmap. The first step is the front end. That means aligning the Web and mobile interfaces for the Robot products, which are mostly done, with the Web interfaces for the PowerTech and SEQUEL products, which are in development.

The goal is to create a single pane of glass, centralized console that allows HelpSystems customers to manage, at least to some extent, all the key products, most of which run on IBM I, but some run on other platforms, and some have multi-platform capabilities. It also includes unified dashboards that allow widgets from any of the products providing data to a common dashboard.

Application integration among multiple product lines at HelpSystems leads to a one pane of glass goal.

Bresnan says the front-end integration has a focus of creating a common mechanism that talks with all the products. When possible, that starts with the database, but in some cases it requires Web services.

“We are mostly working with IBM i apps that are database driven, so many times we can go directly to the data without using Web services,” he says. That simplifies the integration, but Bresnan says creating Web services has not been difficult for the most part. Some of the applications that are being integrated are already functioning with Web services, which makes the integration quicker and easier.

The HelpSystems development group has used Web services for a number of years, which means they have skills in XML and SOAP technologies. However, REST-based Web services have replaced SOAP and JSON has replaced XML in new development.

“The RESTful approach is a simplified approach compared to SOAP,” Bresnan says. “And JSON is much easier to work with than XML. It is an easy way to consume data, especially when dealing with JavaScript front ends. We use REST where we can, but where we have to interact with external customer’s Web services, we’ll support SOAP and XML. Our internal stuff will be REST unless there’s a specific requirement for SOAP.”

Sooner or later integration projects will hit snags. Some applications are not going to be architected as well as others and require more work to integrate. Some applications are a lot more complex than others. When there is a lot of technical data in a product, it will extend the time and effort involved in the integration. The degree of difficulty increases with the degree of integration.

Bresnan provided an example of an application with a Web server that output a proprietary markup language.

“To integrate it, we needed to be talking to that server to get the data. It’s not a situation where we can just go to the database. That’s a rare example of how the way things are architected make a difference. We had to modernize that application to be able to speak to it with REST. When Web development efforts originated at HelpSystems, GUI front ends were separately built for the Robot, PowerTech, and SEQUEL product lines without thoughts of integration. The Web development framework that was built accommodated that. With the advent of a product integration roadmap, that framework evolved along with the unified product integration planning.

“The framework is homegrown,” Brenan explains. “It uses a Java-Tomcat-Apache Web server data management layer on the back end. The Java layer is doing the data access through either JDBC or RESTful Web services. It also does the typical Web routing. On the front end, it’s JavaScript, jQuery, jQuery mobile and a variety of JavaScript libraries for templating and styling.”

From the overall look of things, whether it’s an IBM i perspective or an IT-wide perspective, application integration projects will take on a greater significance each year and continue for many years. Web services have been playing a major role and there’s no reason to think that will change. Integrating applications to meet new requirements will continue to be the choice over rewriting and replacing applications and the systems they run on. It makes the most dollars and cents as well as the most sense.