Prepare your sources

Before connecting a source, create the user Teramot will sign in with and give it the minimum permissions. The scripts below are examples to adapt: replace the database, schema, user and password with your own. The fields each connector asks for are in Databases and warehouses and Applications and cloud sources.

General recommendations

A dedicated user for Teramot. It makes its queries easy to audit and its access easy to revoke without affecting other systems.
Read-only. Teramot only runs read queries on the source: it does not create tables, temporary or otherwise, and it does not modify data.
Only what you will load. Grant permissions only on the schemas or tables you plan to load. If a table has sensitive columns you do not need, create a view without them and grant permission on the view.
A read replica for critical databases. If the production database is sensitive to load, connect a read replica.
Incremental refresh needs a unique key and a modification column in each table. Views have no declared key and always load in full. See Incremental refresh.

CREATE USER teramot WITH PASSWORD '<password>';
GRANT CONNECT ON DATABASE <database> TO teramot;
GRANT USAGE ON SCHEMA <schema> TO teramot;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO teramot;
-- So that new tables are also visible:
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO teramot;

Tables, views and materialized views can be loaded.

CREATE USER teramot PASSWORD '<password>';
GRANT USAGE ON SCHEMA <schema> TO teramot;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO teramot;
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO teramot;

The connection uses TLS by default. Tables, views and materialized views can be loaded.

CREATE USER 'teramot'@'%' IDENTIFIED BY '<password>';
GRANT SELECT, SHOW VIEW ON <database>.* TO 'teramot'@'%';

The tables and views of the database are listed. With IP Whitelisting, you can replace '%' with each of the IP addresses the Connectivity step shows.

-- In master (SQL Server) or in the database (contained user in Azure SQL):
CREATE LOGIN teramot WITH PASSWORD = '<password>';

-- In the source database:
CREATE USER teramot FOR LOGIN teramot;
GRANT SELECT ON SCHEMA::<schema> TO teramot;
GRANT VIEW DEFINITION ON SCHEMA::<schema> TO teramot;

VIEW DEFINITION lets Teramot read primary keys and indexes, which incremental refresh uses. If you require encryption, Teramot checks that the session is encrypted and also needs VIEW SERVER STATE (in Azure SQL, VIEW DATABASE STATE).

CREATE USER teramot IDENTIFIED BY "<password>";
GRANT CREATE SESSION TO teramot;
-- One statement per table to load:
GRANT SELECT ON <owner>.<table> TO teramot;

In Oracle the tables belong to their owner, not to the user Teramot signs in with: enter that owner in Table owner, in upper case. Left empty, only the tables of the user Teramot signs in with are listed, and that user normally has none.

Neither SELECT_CATALOG_ROLE nor access to the DBA_* views is needed: Teramot reads the catalog through the ALL_* views, which show exactly the tables you granted.

The direct connection to Oracle does not use TLS. For a database outside a private network, prefer a private connection or an SSH tunnel.

Create a service principal for Teramot, generate its access token, and grant it:

GRANT USE CATALOG ON CATALOG <catalog> TO `<service-principal>`;
GRANT USE SCHEMA, SELECT ON SCHEMA <catalog>.<schema> TO `<service-principal>`;

It also needs the CAN USE permission on the SQL warehouse.

CREATE ROLE teramot;
GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE teramot;
GRANT USAGE ON DATABASE <database> TO ROLE teramot;
GRANT USAGE ON SCHEMA <database>.<schema> TO ROLE teramot;
GRANT SELECT ON ALL TABLES IN SCHEMA <database>.<schema> TO ROLE teramot;
GRANT SELECT ON ALL VIEWS IN SCHEMA <database>.<schema> TO ROLE teramot;
GRANT SELECT ON FUTURE TABLES IN SCHEMA <database>.<schema> TO ROLE teramot;

CREATE USER teramot PASSWORD = '<password>' DEFAULT_ROLE = teramot DEFAULT_WAREHOUSE = <warehouse>;
GRANT ROLE teramot TO USER teramot;

The service account, or the Google account you authorize with, needs these roles:

Role	Where	Purpose
`roles/bigquery.dataViewer`	The dataset	Read the tables and their schema
`roles/bigquery.jobUser`	The project	Run the read queries
`roles/bigquery.readSessionUser`	The project	Optional: faster reads

Teramot does not write to your datasets.

Teramot reads tables over RFC, with the standard function module RFC_READ_TABLE. The communication user (type System or Communication) needs:

S_RFC, to run the RFC_PING, RFC_READ_TABLE and EM_GET_NUMBER_OF_ENTRIES modules.
S_TABU_NAM (or S_TABU_DIS) with display activity, on the tables to load and on the dictionary tables DD02L, DD03L, TFDIR and FUPARAREF.

If that module is missing, not authorized for the user, or too narrow for a wide table, set your own, such as ZRFC_READ_TABLE, in Reader function module under Advanced ingest.

Over a private connection, allow the application server’s RFC port, 3300 plus its system number, through the tunnel.

Salesforce, HubSpot, Odoo, Monday.com, Airtable, Google Sheets and OneDrive need no preparation: you sign in or paste a token in the form.

Private connections