The infoCDC is a unique product that we feel requires further elaboration is needed regarding the intent for the product’s creation as well as its functionality. Therefore, we wanted to create this blog to address some of the most common questions we have received about our new product.

Is infoCDC installed and run on the IBM i?

infoCDC is installed and operated on the IBM i.

Once the product is configured, is there any manual coding required to leverage the product?

infoCDC enables customers to capture IBM i data changes and stream via Data Queues to the integration platforms such as Confluent Kafka or MuleSoft, with no custom coding required.

How does the product capture the change on the selected table on DB2?

infoCDC continuously listens for DB2 journals, selects relevant entries per product configuration, and sends them to the respective Data Queue.

Once infoCDC is installed on an IBM i server, is auto discovery enabled on the server?

Customers would have to define each table to be replicated within infoCDC configuration. This enables the product to only send changes for relevant tables, and exclude unnecessary data movements.

Does the infoview team offer POC’s with customers?

Absolutely! Our service team is here to assist with product configuration, first use case implementation, defining tables, full installation of prod in sandbox/non-prod, and corresponding connector configurations to ensure everything works from the IBM i perspective.

Does infoCDC require timestamps on the table?

Time stamps are not required, as the product is not polling periodically based off time stamps. infoCDC connects directly into DB2 journals, almost like Kafka persistently log of data and events, whenever change happens, one or more entries pushed into journal that immediately is made available for a process on our end.

How Much CPU or memory is needed for the infoCDC to run on the IBM i?

Overall, implementation of the product will be relatively easy on IBM i system performance. Listening happens with a specific job, one per journal, resulting in a lightweight and responsive solution as compared to trigger or DB polling integration options.

Why did Infoview choose to invest in a CDC based product?

There are several products on the market focused on mass scale replication, but are often heavy, expensive, and are not easy to implement. We envisioned this product as a lightweight, easy to use alternative, that’s more accessible and requires less time to implement.

Must the infoCDC be leveraged with an existing Infoview connector?

The way the infoCDC was developed, it expects a consumer to be listening to its outbound interface (currently, it’s a data queue with an associated format table). When bundled together, Infoview’s products are highly complementary and supported by our in-house team members. At the same time, any application capable of listening for Data Queue entries could work with infoCDC.

To find out more material about the infoCDC please refer to the links below. If you have any questions or are interested in hosting a discovery call, please contact us below: