Manage Data Sources

Use the following information to help you manage your data sources.

Test Connectivity to a Database

For any data source, you can test connectivity to the database that is represented by this data source. The data source does not have to be registered in GoodData for connectivity testing.

Registered Data Source

To test connectivity for a registered data source, submit a POST request to API endpoint /api/v1/actions/dataSources/{dataSourceId}/test.

curl $HOST_URL/api/v1/actions/dataSources/<dataSourceId>/test \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{}' \
  -X POST | jq .

Invoke-RestMethod -Method Post -Uri "$HOST_URL/api/v1/actions/dataSources/<dataSourceId>/test" `
  -ContentType 'application/json' `
  -H @{ 
    'Accept' = 'application/json' 
    'Authorization' = "Bearer $API_TOKEN" 
  } | ConvertTo-Json

If a PostgreSQL database indeed runs behind the <dataSourceId> data source, the server returns the following response:

{
  "successful": true
}

Unregistered Data Source

To test connectivity for an unregistered data source, submit a POST request to /api/v1/actions/dataSource/test. Using PostgreSQL database as an example:

curl $HOST_URL/api/v1/actions/dataSource/test \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{
      "url": "jdbc:postgresql://<some_hostname>:<some_port>/<dbname>",
      "schema": "<schema_name>",
      "type": "POSTGRESQL",
      "username": "<username>",
      "password": "<password>"
  }' \
  -X POST | jq .

Invoke-RestMethod -Method Post -Uri "$HOST_URL/api/v1/actions/dataSource/test" `
  -ContentType 'application/json' `
  -H @{ 
    'Accept' = 'application/json' 
    'Authorization' = "Bearer $API_TOKEN" 
  } `
  -Body '{
      "url": "jdbc:postgresql://<some_hostname>:<some_port>/<dbname>",
      "schema": "<schema_name>",
      "type": "POSTGRESQL",
      "username": "<username>",
      "password": "<password>"
  }' | ConvertTo-Json

If a PostgreSQL database indeed runs under the specified url and the credentials are valid, the server returns the following response:

{
  "successful": true
}

Data Source Passwords

The passwords for data source users can be stored using the declarative API interface, but they cannot be retrieved using the declarative API interface.

• Before you submit a PUT request to the data sources declarative API interface, verify that you have the relevant passwords to your data sources to avoid any connection issues. You can include the passwords in your PUT request, or alternatively, you can use the entity API interface to update a specific password if you do not want to include it in the PUT request to the declarative API interface.
• When you use the declarative API interface for data sources, then you must either specify the username and password for the data source in the PUT request or specify nothing at all.

Create A Backup Of All Data Sources

The following example retrieves the entire declarative layout of your data sources and stores the output in a JSON file named data-sources-layout.json. The passwords are not retrieved as it is not possible to retrieve passwords through the API. Refer to data source passwords for more information.

curl -H "Authorization: Bearer $API_TOKEN" \
  $HOST_URL/api/v1/layout/dataSources > data-sources-layout.json

Restore All Data Sources

The following example replaces the current data source declarative layout with that of a previously retrieved declarative layout. If the previously retrieved declarative layout has not been updated to include the data source passwords, the data source passwords must be inserted afterwards.

curl -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -X PUT \
  $HOST_URL/api/v1/layout/dataSources -d @data-sources-layout.json

Data Source Declarative Layout Document

The following example shows a truncated physical model for the data sources declarative layout. The password is replaced with a dummy value.

{
  "dataSources": [
    {
      "id": "pg_local_docker-demo",
      "name": "pg_local_docker-demo",
      "pdm": {
        "tables": [
          {
            "columns": [
              {
                "dataType": "STRING",
                "isPrimaryKey": false,
                "name": "category"
              },
              {
                "dataType": "INT",
                "isPrimaryKey": true,
                "name": "product_id"
              },
              {
                "dataType": "STRING",
                "isPrimaryKey": false,
                "name": "product_name"
              }
            ],
            "id": "products",
            "path": [
              "products"
            ],
            "type": "VIEW"
          }
        ]
      },
      "schema": "demo",
      "type": "POSTGRESQL",
      "url": "jdbc:postgresql://postgres:5432/tiger",
      "username": "postgres",
      "password": "<password>"
    } 
  ]
}

You can also issue a PUT request to the data sources declarative API endpoint with an empty physical model.

{
  "dataSources": [
    {
      "id": "pg_local_docker-demo",
      "name": "pg_local_docker-demo",
      "pdm": {
        "tables": []
      },
      "schema": "demo",
      "type": "POSTGRESQL",
      "url": "jdbc:postgresql://postgres:5432/tiger",
      "username": "postgres",
      "password": "<password>"
    }
  ]
}