FAQs and Resources

Our standard pricing can always be adapted to special customer requirements.

The paid license includes an annual maintenance fee that covers patches for bugs and vulnerabilities.

Customers are notified when a new version is released and can download it from the INIT repository, independent of the Confluent hub. This allows us to deliver patches much faster.

The ETA for bug fixes is usually a couple of days.

The annual maintenance fee includes all patches provided to fix bugs, security issues, transitive library updates, etc.

It does not include, for example, potentially major enhancements to the functionality of the software. These enhancements may be made available through minor and major release updates. This is comparable to major release upgrades of other software systems. We reserve the right to charge an upgrade fee for these.

An evaluation version of the connectors, limited to 30 days of use, can be downloaded from the INIT repository. This allows a prospective customer to test the connectors at an early stage.

Simply contact connector-contact@init-software.de to get access to the latest version of a connector, including pre-releases and patches.

For an overview of the INIT connector portfolio, visit our Kafka Connectivity - INIT product page. It also contains links to more detailed documentation.

Yes. The connector is implemented against the Kafka Connect API and therefore fully integrated into Kafka Connect with all its functional possibilities.

By design, the Kafka Connect API does not provide PUSH for connectors. See KIP-26 - Adding the Kafka Connect framework for data import/export

Currently, Confluent does not support running partner connectors in the managed cloud. Customers must maintain a separate on-premises Kafka for their unmanaged connectors, making the infrastructure more complex, error-prone, and difficult to maintain.

No. The connector exclusively uses the standard ODP-API v2.

The context is expected to be SLT~ and the odp name/alias should be equal to the source table name. The SLT queue alias is defined in the SLT configuration itself, see Technical Requirements for ODP SLT and SLT | ODP based Real-time Replication for more detailed information.
One can also use report RODPS_REPL_TEST and the F4 value-help for the context input field or use our CLI tool shipped with the connector package.

In the SCN you can find a detailed article about how to enable CDS views for data extraction via ODP. You can find standard CDS views enabled for data extraction in the SAP API Business Hub.

The data type conversion errors you get are due to invalid dates stored in SAP®. In these situations we generally suggest to fix incorrect values in the source system, because the connector is unable to guess what kind of values besides the standards should be treated e.g., as a non-existing date. Other invalid dates (like e.g. ‘333 -00-00’) can also be stored in SAP®, as the underlying database type for this is nvarchar, but cannot be interpreted as a valid date in the connector. The issue here with ODP is that it allows incorrect values to be stored in ODQ and is missing an easy way to fix incorrect values already stored in the ODQ for external consumption. There is a user-exit you can use before the data gets extracted from the ODQ, but this is inadequate if you need to react to incorrect values in a flexible way e.g., on productive systems where you would need to go the way through SAP® transport management.
Therefore, we implemented error tolerance strategies to overcome this missing functionality in SAP®, which enable you to skip or initialize invalid values in a flexible way. We suggest to use this functionality restrictively and only for data sets that have been identified as incorrect in advance. Then you would be able to e.g., skip the corresponding dataset, fix the values in the source and trigger a new delivery of the dataset from the source system. Another option is to convert date, time and numeric characters to plain strings using sap.odp.numeric.mapping=string. However, we recommend this procedure be carefully reconsidered, since maintaining adequate data types is of high importance.

The problem is that SAP's Decimals type is represented in Kafka Connect by Java BigDecimal, with a byte representation. The logical data type Decimal in Avro is also represented as a primitive type of bytes. The ODP Connector can be configured to transform decimal values from bytes to either long or double, depending on the scale. It should be noted that the converted field values may no longer be exact due to data type conversion.

You can use the SAP report _RODPS_REPLTEST to test data extraction from BW ODP sources on SAP side, before using the ODP Source connector in Kafka Connect.
For more information: SAP Support Wiki

You can use the SAP transaction ODQMON to monitor ODP extractions. For more information: SAP Support Wiki

# Optional: error tolerance behavior in case of value conversion errors (none, skiprow, initializefield or deadletterqueue) 
sap.odp#00.errors.tolerance=skiprow 

# Optional: regular expression for selecting datasets to which the error strategy (!= none) is to be applied 
sap.odp#00.errors.tolerance.row-regexp=.* 

# Optional: fields to which the error strategy (!= none) is to be applied (empty means all) 
sap.odp#00.errors.tolerance.fields=CALDAY

The ODP source connector logs messages containing unique identifiers of the dataset and field containing invalid values, which can be used for the row-regexp and field list settings to specify the exact datasets and values your selected error strategy will be applied to. Additionally, the connector provides meta information about the data extraction in the Kafka message headers by default. You can configure additional headers using the setting sap.odp.headers.enable=1. To map SAP ABAP types of Date, Time, and Numeric Text to String, you can use the setting sap.odp.numeric.mapping=string.