Stelo + Microsoft Azure

Stelo takes full advantage of open standards such as DRDA, SQL, ODBC, and JDBC to maximize compatibility and interoperability within an enterprise network. We are an active member of The Open Group software industry consortium, which was responsible for the adoption of DRDA as an industry standard for database interoperability.

Currently, Stelo supports more than 30 ODBC databases and our Kafka interface can also be used to communicate with cloud-based streaming services such as Azure Event Hubs for Kafka, the Oracle Cloud Infrastructure Streaming service, Amazon Managed Streaming for Apache Kafka, and IBM Event Streams. Stelo can also populate Azure Data Lake Storage Gen2 (ADLSg2) and similar NoSQL data repositories.

Stelo continues to use our open standards approach to ensure that we meet emerging replication requirements. We are continually adding support for new technologies while supporting legacy systems. Stelo is designed to grow with your organization rather than lock you in to any specific database platforms.

Analyzing a company’s ongoing transactional or operational data can provide key insights that drive business decisions and processes. Many companies offload these operations to other databases, data warehouses, or data lakehouses to reduce source system load and save costs. However, replicating dynamic data from multiple source databases to one or more destination application requires real-time change data capture (CDC) to ensure all updates are automatically and reliably reflected. In other words, business insights are only effective if data changes are accurately captured and delivered across the connected databases over time.

CDC is typically the first stage in the data ingestion process and represents the “extraction phase” in the ETL and ELT approaches. CDC strategies often demand a tradeoff between latency tolerance and change volume requirements, but Stelo’s approach provides the ideal balance between fast, high-volume performance and lossless data capture. Our process can simultaneously propagate a source system’s information changes and structure updates to destination platforms so that the data appears in the correct sequence at the same time. In addition, the cost-efficient method merges incoming data flows into one stream, as opposed to using many streams, which becomes expensive.

Some data replication solutions require that you pay for a dedicated engineer, which substantially increases costs and suggests that the software may be complicated and difficult to use. Good replication software does not require a babysitter. Once running, Stelo reliably operates in the background without needing dedicated engineering support to maintain and manage.

Yes, Stelo has an automatic method to build out data warehouses, so we can do the heavy lifting for you. It works well whether you're doing a migration up to the cloud or are continuing with ongoing replication.

We encourage you to configure Stelo to create the destination tables on the SQL Server. In part this is to ensure the proper mapping of change data captured on the source system and the destination table. Also, if the Customer's high availability (HA) software utilizes *AFTER images only for capturing change data, then Stelo must rely upon a synthetic column (the Relative Record Number or "RRN") to uniquely identify the row in the destination table, and it is unlikely that some tools such as the JDE tool would provide this column. Therefore, it is best to allow Stelo to create the destination, including this column for each table. Alternatively, if the HA software configures *BOTH images in the journals then we can dispense with the RRN column and just utilize any unique index (including a primary key) to identify rows.

Another issue that should be addressed in the planning stage is the use of Unicode data types on the destination SQL Server. We strongly encourage customers to use NCHAR/NVARCHAR data types for SQL Server as this provides the greatest fidelity when mapping data from IBM i EBCDIC to Windows and other non-EBCDIC environments.

Our recommendation is to allow Stelo to create the tables and exploit UNICODE data-types, and then use the tool to create any additional indexes.