Connector Creation Guide
Last updated
1.3
Last updated
Creating Dashboards for Reporting involves the following steps:
Understanding what database tables are required to be indexed to OpenSearch for the dashboard.
Creating a pipeline for the data flow to OpenSearch. This pipeline involves:
Creating one Debezium Connector containing the database table.
Creating one OpenSearch Connector for the database table.
Creating a dashboard on OpenSearch
Follow the guides on this page to learn more about each step in the process above.
This document contains instructions for the developers (or dashboard creators) on creating the required connectors and dashboards to visualize reports on OpenSearch.
Follow the to install/update the connector configuration.
Create a GitHub repository (or create a new directory in an existing repository) which is going to store the configuration for the connectors and the dashboards for OpenSearch.
Create a directory in the repository with these three folders debezium-connectors , opensearch-connectors and opensearch-dashboards .
For example .
Identify the tables from the database whose data will be required for the reports.
One debezium connector is sufficient for indexing all the required tables of one database. So create one connector for each database (rather than one for each table).
Create a json file in the debezium-connectors . Each json file corresponds to one debezium connector. With the following contents:
Add the list of all tables required from this database into the table.include.list field (in no particular order) (Accepts regex). For example
This list needs to include relationship tables of the current table. For example: if you want to index g2p_program_membership but would also like to retrieve the name of the program in which the beneficiary belongs, then you have to add g2p_program as well.
Each json file in the opensearch-connectors folder will be considered a connector. Create one connector file for each table with the following content:
Replace name with the appropriate table names.
Replace topics field with the name of table.
After the base file is configured, you can now add transformations to your connector at the end of the file (denoted by ... in the above example). Each transformation (SMT) will apply some change to the data or a particular field from the table, before pushing the entry to OpenSearch.
Add the following transformations to your connector based on the data available in the table.
For every Datetime field / Date field in the table add the following transform.
At the end of all the transformations, add a TimestampSelector transform, which creates a new @timestamp_gen field whose value can be selected as any of the available Datetime fields in the table. This will be useful while creating a Dashboard on OpenSearch, where we can use this new @timestamp_gen field as the IndexPattern timestamp.
If you want to pull data from another table (which is already indexed into OpenSearch) into this table that the connector is pointing to, use the DynamicNewField transform. For example; g2p_program_membership contains the beneficiary list. But the demographic info of the beneficiary is present in res_partner table. Say you want to pull gender, and address of the beneficiary, and name of the program that the beneficiary is part of, then create two transforms like this:
If you want to add data/fields from one connector to another index on OpenSearch, use the DynamicNewFieldInsertBack transform. For example; NATIONAL IDs of registrants are saved in g2p_reg_id table. But if that field data is needed on res_partner index (main registrant data table) the following can be done on the g2p_reg_id connector. (The following adds reg_id_NATIONAL_ID field into res_partner index from g2p_reg_id connector into the document with ID from partner_id field) :
The connector by default indexes all the fields from the DB into OpenSearch. If you want to exclude fields from getting indexed, they must be explicitly deleted using a transform like given below. For example PII fields like name, phone number, address, etc. As a general rule, fields that are not required for dashboards must be excluded explicitly.
column.exclude.list property can also be used to remove specific columns from being indexed (Not preferred method). The disadvantage is that this excludes the fields from Kafka topics itself. If there are multiple OpenSearch Connectors, referring to the same topic, each with different data requirements, then this is not possible to control at the SINK connector side.
If you wish to change the name of the Index into which data is supposed to be inserted, use RenameTopic transform. The default index name before rename will be that of the topic name given in the topics config field. Example :
After configuring all the transforms, add the names of all transforms, in the order in which they have to be applied, in the transforms field.
With this configuration, you will have two OpenSearch connectors. One that tracks the latest data of a table. And one that tracks all the changes. Correspondingly you have two indexes on OpenSearch (one with _history and one with regular data).
Example debezium connector
Reference.
If you wish to apply a on the record, use ApplyJq transform. The current record will be replaced with the result after applying Jq. Example:
Example OpenSearch Connector
For more info on basic connector configuration, refer to .
For detailed transform configuration, refer to doc.
For a list of all available SMTs and their configs, refer to .
If you also wish to record all the changes that are made to the records of a table, create a new OpenSearch connector for the same topic as given in and change the following properties.
Refer to .