HVR Data Integration Has A Place For IBM i
November 8, 2017 Dan Burger
Data integration is powering changes in enterprise computing. And although it doesn’t get talked about a lot, relational databases are major factors in the enterprise business analytics. Transactional processing systems that are the workhorses of enterprise applications such as ERP are rock solid and critical to data analytics regardless of the hoopla and hyperbole that “modern” databases create.
Fitting a relational database into a heterogeneous environment that is pumped full of continuous data integration from a variety of sources can be a problem, but lessons are being learned as data integration becomes more platform inclusive at more companies.
HVR Software brought support for Db2 for i databases into its assortment of integration platforms almost three years ago. Its business profile is working with large, complex environments — large scale from a data perspective and from the number of source systems. Centralized control for logging and monitoring multiple systems is one of its strengths.
“We see organizations with a lot of different technologies. The common use cases are organizations that want to centralize their data onto a platform they refer to as their data lake,” says Mark Van de Wiel, CTO at HVR. “Our customers are continuously moving data to that system and making it available to data scientists who analyze it. Providing support for Db2 for i is important in that sense. We see a fair number of our clients using Db2 for i as one of many systems that become a source for data analysis.”
Van de Wiel estimated the number of HVR customers with Db2 for i integration requirements as between one and two dozen. Manufacturers running SAP and Oracle‘s JD Edwards ERP systems are the most common IBM i customers for HVR.
HVR runs in a distributed setup, using the resources on multiple systems to scale. The software is typically used for offloading data to be analyzed (the data lake example), but it also feeds real-time data warehouses. From Van de Wiel’s observations, there’s an increase in data integration happening between on-prem data centers and cloud-based systems. That includes the purposes of data migrations or for high availability, disaster recovery, and geographical distribution.
HVR runs on either a Windows or Intel-based Linux server. Van de Wiel says Linux is a popular, cost-effective choice used by many customers, but HVR does not compile its software for Linux on Power. “I’ve not heard requests from customers to exploit that option,” he says.
Continuous data integration in heterogeneous environments includes the copying of table definitions to the destination system as one example. Although the integration with Db2 for i is similar to the integration with other relational databases, when it comes to log-based data capture used by HVR, there are differences in data types supported.
“We can capture any and all changes and move those changes to another system,” Van de Wiel says while using examples such as adding or altering tables and columns. “If a new table is added to the system, it can be duplicated with manual adjustments. The automatic pickup and propagation to the destination environment of these changes — available for Oracle and SQL Server — is not available yet for Db2 for i, but it will be delivered in early 2018.”
HVT supports the SQL version of Db2 for i using the database’s API interface. Van de Wiel says the demand from IBM i customers has been from the 7x versions of Db2 for i. HVR does not support non-SQL versions of Db2 for i.
HVR runs SQL statements to get the data from Db2 for i. From an incremental change data perspective, it’s done via APIs calls in the Db2 database to retrieve log fragments, which are parsed to identify database changes and propagate the changes.
Regarding performance, the CTO says, the continuous log-based change data capture comes down to keeping up with the volume of changes and that HVR has not had any issues capturing Db2 for i data volume. Configuration of the systems and bandwidth, however, would be factors.