Menu
[fibosearch]
Abstract
Red Hat Integration is a comprehensive set of integration and event processing technologies for creating, extending, and deploying container-based integration services across hybrid and multicloud environments. Red Hat Integration provides an agile, distributed, and API-centric solution that organizations can use to connect and share data between applications and systems required in a digital world.
Red Hat Integration includes the following capabilities:
Additional resources
This section provides a summary of the key new features in Red Hat Integration 2020-Q3 and provides links to more details on new features available in different components.
These release notes include details on components updated in Red Hat Integration 2020-Q3 only. For details on the latest versions of other components, such as Camel K, Camel Kakfa Connector, and Data Virtualization, see Red Hat Integration Release Notes for 2020-Q2.
Installation in restricted networks with no Internet access with:
For more details on what’s new in Red Hat Integration 2020-Q3 components:
This section describes the features that are removed in Red Hat Integration 2020-Q3 and provides links to more detailed information.
The Data Virtualization Technology Preview component of Red Hat Integration based on the Teiid project is removed in this release. The following capabilities are removed:
Additional resources
Red Hat Integration 2020-Q3 includes a General Availability release of Debezium on OpenShift based on the Debezium open source project. Debezium is a distributed change data capture platform that tracks database operations and streams data change events. Debezium is built on Apache Kafka and is deployed and integrated with AMQ Streams.
Debezium captures row-level changes to database tables and passes corresponding change event records to AMQ Streams. Applications can read these change event streams and access the change events in the order in which they occurred.
Debezium provides connectors based on Kafka Connect for the following common databases:
When trying out the database connectors, the following database versions are supported for this release:
| Database | Versions |
|---|---|
| MySQL | 5.7, 8.0 |
| PostgreSQL * | 10, 11, 12 |
| MongoDB | 3.6, 4.0, 4.2 ** |
| SQL Server | 2017, 2019 |
| Db2 | 11.5.0.0 |
*For PostgreSQL deployments, you use the pgoutput logical decoding output plug-in, which is the default for PostgreSQL versions 10 and later.
**When using the Debezium connector for MongoDB, there is a limitation if you are using MongoDB 4.2. The limitation is that you cannot use the connector’s transaction metadata feature. This limitation is expected to be removed in a future release.
Additional resources
You can install Debezium with AMQ Streams on OpenShift or RHEL:
Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope.
This release provides the following new Debezium features:
This release provides the following Technology Preview features:
Red Hat Integration – Service Registry 1.0.1 is provided as a micro release in Red Hat Integration 2020-Q3. Service Registry is a datastore for standard event schemas and API designs that is based on the Apicurio Registry open source community project.
You can use Service Registry to manage and share the structure of your data using a REST interface. For example, client applications can dynamically push or pull the latest updates to or from Service Registry without needing to redeploy. You can also use Service Registry to create optional rules to govern how registry content evolves over time. For example, this includes rules for content type validation or backwards and forwards compatibility of schema or API versions.
You can install Service Registry with the following storage options:
Table 5.1. Service Registry storage options
| Storage option | Release |
|---|---|
| Kafka Streams-based storage in AMQ Streams 1.5 | General Availability |
| Cache-based storage in embedded Infinispan 10 | Technology Preview only |
| Java Persistence API-based storage in PostgreSQL 12 database | Technology Preview only |
Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend implementing any Technology Preview features in production environments.
This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope.
The Service Registry 1.0.1 micro release updates the Operator metadata that is used to install Service Registry 1.0 from the OpenShift OperatorHub user interface. The Service Registry product images have not changed and remain at version 1.0.
The new Operator metadata includes a new Operator bundle format for release packaging, which is designed for use with OpenShift Container Platform 4.5 or 4.6. For more details, see the Bundle Format in the OpenShift documentation.
You can upgrade to Service Registry 1.0.1 if you are using OpenShift 4.5. However, you must upgrade to Service Registry 1.0.1 before upgrading to OpenShift 4.6. The new Operator bundle format is required for use with OpenShift 4.6.
Service Registry provides the following new features in the 1.0 General Availabilty release:
Perform artifact actions:
The following known issues apply to Service Registry 1.0:
Operator-32 – Operator should support SCRAM authorization without TLS, not only SCRAM+TLS
The Service Registry Operator should support Salted Challenge Response Authentication Mechanism (SCRAM) authorization without Transport Layer Security (TLS), not only SCRAM+TLS.
Operator-41 – Example CRD should not be empty::
Example ApicurioRegistry custom resource definition should not be empty.
Operator-42 – Auto-generation of OpenShift route may use wrong base host value
The auto-generation of the Service Registry OpenShift route may use a wrong base host value if there are multiple routerCanonicalHostname values.
Operator-45 – Operator may not delete all resources
The Service Registry Operator may not delete all resources when deleting ApicurioRegistry custom resource definition.
Red Hat Integration provides Operators to enable you to automate the deployment of Red Hat Integration components on OpenShift. This section provides links to detailed information on how to use Operators for components in this release.
PCC-IT International, Division of Power Capital Management, Inc. © 2024 All rights reserved.