hostPort: Host and port of the Alation instance.

authType: Following authentication types are supported:

1. Basic Authentication: We'll use the user credentials to generate the access token required to authenticate Alation APIs

• username: Username of the user.
• password: Password of the user.

2. Access Token Authentication: The access token created using the steps mentioned here can directly be entered. We'll use that directly to authenticate the Alation APIs

• accessToken: Generated access token

For Alation backend database Connection:

Alation APIs do not provide us with some of the metadata. This metadata we extract directly from the alation's backend database by query the tables directly. Note that this is a optional config and if it is not provided primary metadata will still be ingested. Below is the metadata fetched from alation database: 1. User and Group Relationships

Choose either postgres or mysql connection depending on the db:

1. Postgres Connection

• username: Specify the User to connect to Postgres. Make sure the user has select privileges on the tables of the alation schema. password: Password to connect to Postgres. hostPort: Enter the fully qualified hostname and port number for your Postgres deployment in the Host and Port field.
• database: Initial Postgres database to connect to. Specify the name of database associated with Alation instance.

1. MySQL Connection

• username: Specify the User to connect to MySQL. Make sure the user has select privileges on the tables of the alation schema. password: Password to connect to MySQL. hostPort: Enter the fully qualified hostname and port number for your MySQL deployment in the Host and Port field.
• databaseSchema: Initial MySQL database to connect to. Specify the name of database schema associated with Alation instance.

projectName: Project Name can be anything. e.g Prod or Demo. It will be used while creating the tokens.

paginationLimit: Pagination limit used for Alation APIs pagination. By default is set to 10.

includeUndeployedDatasources: Specifies if undeployed datasources should be included while ingesting. By default is set to false.

includeHiddenDatasources: Specifies if hidden datasources should be included while ingesting. By default is set to false.

ingestUsersAndGroups: Specifies if users and groups should be included while ingesting. By default is set to true.

ingestKnowledgeArticles: Specifies if knowledge articles should be included while ingesting. By default is set to true.

ingestDatasources: Specifies if databases, schemas and tables should be included while ingesting. By default is set to true.

ingestDomains: Specifies if hidden domains and subdomains should be included while ingesting. By default is set to true.

ingestDashboards: Specifies if hidden BI sources and dashboards should be included while ingesting. By default is set to true.

alationTagClassificationName: Specify the classification name under which the tags from alation will be created in OpenMetadata. By default it is set to alationTags.

connectionArguments: These are additional parameters for Alation. If not specified the ingestion will use the predefined pagination logic. The following arguments are intended to be used in conjunction and are specifically for Alation DataSource APIs:

• skip: This parameter determines the count of records to bypass at the start of the dataset. When set to 0, as in this case, it means that no records will be bypassed. If set to 10, it will bypass the first 10 records.

• limit: This argument specifies the maximum number of records to return. Here, it's set to 10, meaning only the first 10 records will be returned.

To perform incremental ingestion, these arguments should be used together. For instance, if there are a total of 30 datasources in Alation, the ingestion can be configured to execute three times, with each execution ingesting 10 datasources.

• 1st execution: {"skip": 0, "limit": 10}
• 2nd execution: {"skip": 10, "limit": 10}
• 3rd execution: {"skip": 20, "limit": 10}

To send the metadata to OpenMetadata, it needs to be specified as type: metadata-rest.

The main property here is the openMetadataServerConfig, where you can define the host and security provider of your OpenMetadata installation.

Logger Level

You can specify the loggerLevel depending on your needs. If you are trying to troubleshoot an ingestion, running with DEBUG will give you far more traces for identifying issues.

JWT Token

JWT tokens will allow your clients to authenticate against the OpenMetadata server. To enable JWT Tokens, you will get more details here.

You can refer to the JWT Troubleshooting section link for any issues in your JWT configuration.

Store Service Connection

If set to true (default), we will store the sensitive information either encrypted via the Fernet Key in the database or externally, if you have configured any Secrets Manager.

If set to false, the service will be created, but the service connection information will only be used by the Ingestion Framework at runtime, and won't be sent to the OpenMetadata server.

Store Service Connection

If set to true (default), we will store the sensitive information either encrypted via the Fernet Key in the database or externally, if you have configured any Secrets Manager.

If set to false, the service will be created, but the service connection information will only be used by the Ingestion Framework at runtime, and won't be sent to the OpenMetadata server.

SSL Configuration

If you have added SSL to the OpenMetadata server, then you will need to handle the certificates when running the ingestion too. You can either set verifySSL to ignore, or have it as validate, which will require you to set the sslConfig.caCertificate with a local path where your ingestion runs that points to the server certificate file.

Find more information on how to troubleshoot SSL issues here.