Embedded Connectors FAQ

This FAQ is designed to help software providers understand how CData connectors work, how they integrate into different environments, and how they handle authentication, metadata, and queries.

About CData connectors

• What are CData connectors, and how do they work?
  • CData connectors are individually packaged software libraries that provide connectivity to over 230+ data sources. They standardize data access across diverse systems, including SaaS applications (Salesforce, NetSuite), NoSQL databases (MongoDB, Cassandra), cloud data warehouses (Snowflake, BigQuery), and flat file formats (CSV, JSON), making them appear as relational databases through industry-standard interfaces like JDBC, ODBC, and ADO.NET.
• What problem do CData connectors solve?
  • Most enterprise data resides in APIs, SaaS platforms, and custom systems that don't support SQL queries. CData connectors translate these data sources into a relational model, so software providers can interact with them using SQL-92 queries, even if the underlying source doesn't support SQL.

Integration & Configuration

• How do software providers embed CData connectors into their applications?
  • Connectors are provided as JAR (JDBC), DLL (ODBC, ADO.NET), and Python modules.
  • Driver libraries are then deployed by the software provider with their application or service, and all connections are made directly from the deployed library to the data source, with no intermediary CData services between the connection.
  • Configuration is handled through connection properties, which dynamically adjust based on the data source. Discovery of connection properties is handled through the interface chosen by the software provider (JDBC/ODBC/ADO.NET).
    • An additional JSON markup of the connection properties is also available for discovery, so software providers can build more dynamic and intuitive connection dialogs.
• Do CData connectors support multiple versions of a data source?
  • Yes, CData connectors can support multiple API versions.
  • Many CData connectors make use of multiple versions of an API without the user or software provider needing to provide inputs. This is done to ensure that calls are optimized based on what the user is trying to accomplish (e.g., a query API and a bulk upload/download API), automatically picking which API to use based on the query context.
  • When API versioning needs to be controlled by the user, CData typically takes one of two approaches:
    • Schema-based versioning: For APIs with hard-set endpoints and frequently changing metadata (e.g., Google Ads, Shopify), CData organizes different API versions into separate schemas. This allows customers to select the version they need and transition to a new schema when ready—all within the same driver.
    • Connection property versioning: For APIs where the data structure changes across versions, but the driver's interaction with the API remains consistent (e.g., Salesforce), a connection property is used to specify the API version. This gives customers control over the version they connect to without requiring a different schema.
• How does CData ensure a consistent experience across different data sources?
  • CData connectors provide a uniform interface across JDBC, ADO.NET, and ODBC, ensuring a consistent experience for developers and applications and giving software providers a consistent way to build connections, discover metadata, and execute queries.
  • While authentication methods vary based on what each data source supports (e.g., Basic, OAuth, SSO Providers, Kerberos), CData strives for consistency in connection property naming across connectors.
  • All CData connectors support a shared “CData” dialect of SQL, which adheres to the SQL92 specification.

Authentication & Security

• What authentication methods do CData connectors support?
  • CData supports a variety of authentication methods, supporting most authentication mechanisms supported by the underlying data source, including:
    • Basic authentication (user/password, API token, etc.)
    • OAuth (with extensible token management)
    • SSO providers (e.g., Okta, Azure AD)
    • Kerberos
• How does authentication setup work?
  • Authentication parameters are part of the connection properties.
  • Interactive user flows (OAuth) are also supported in desktop environments, launching the user browser and capturing the token callback.
• Do the connectors handle refreshing tokens?
  • Yes. OAuth token management is built into the connectors, allowing the driver to persist and refresh tokens as required.
  • For applications using OAuth authorization code flow, CData also provides standard mechanisms for managing token storage outside the driver. This is particularly relevant for OEM applications that require deeper control over authentication. (Integration guides are made available for software providers.)

Metadata & Querying

• How do CData connectors expose metadata?
  • CData connectors map source metadata to a relational schema, allowing applications to query catalogs, schemas, tables, keys, and stored procedures (when supported by the source).
  • Metadata retrieval follows standard interface methods (e.g., metadata is retrieved by querying DatabaseMetaData in JDBC or Connection.GetSchema in ADO.NET).
  • Additional, proprietary CData metadata endpoints (built-in system tables) are also available and can offer additional metadata information beyond what is surfaced in the standard JDBC/ODBC/ADO.NET interfaces.
• Do CData connectors make use of caching?
  • In many cases, metadata is temporarily cached to optimize performance. However, for sources with fast metadata retrieval (such as relational databases), caching may not be necessary.
  • While some data may be cached within the execution of a single query, by default all query execution is live, real-time data.
• How do CData connectors handle queries?
  • A common “CData” dialect of SQL (SQL-92) queries is translated into API calls, wire-protocols, or other appropriate executions to fetch data from the service.
  • The driver's SQL engine intelligently evaluates each query to determine which parts can be pushed to the source system and which need to be processed client-side. It optimizes performance by offloading as much work as possible to the source while handling the rest efficiently within the driver.
  • Queries are streamed, reducing memory overhead and improving performance.
• Do CData connectors support write operations?
  • Yes, all CData connectors support SELECT operations. Additionally, many connectors support:
    • DML (Data Manipulation Language): INSERT, UPDATE, DELETE, and, for specific sources, UPSERT.
    • DDL (Data Definition Language): A subset of connectors also supports CREATE, RENAME, TRUNCATE, ALTER, and DROP operations, depending on source capabilities.
    • Batching for optimized performance in sources like Salesforce.

Performance & Optimization

• How do CData connectors optimize query performance?
  • CData connectors optimize performance by pushing down as much of the query as possible to the source system and handling the rest client-side when necessary. To further enhance efficiency, the connectors:
    • Leverage hybrid processing: Queries are evaluated to determine which parts can be executed by the source system, minimizing client-side processing.
    • Stream data efficiently: Data is streamed where possible to maximize speed and minimize memory usage based on query needs.
    • Utilize parallel paging: For REST APIs and other sources, connectors can fetch multiple pages simultaneously using parallel threads, significantly improving performance.
• What if a software provider needs a custom data integration?
  • CData connectors are closed source, meaning software providers cannot modify them directly. However, CData's software customers drive much of the product roadmap and providers can request enhancements tailored to their unique integration needs. Feature requests are common, and a sizable portion of CData's engineering effort is dedicated to maintaining and enhancing connectors based on customer feedback.

Testing & Proof of Concept (PoC)

• How can software providers test CData connectors?
  • Trial versions of the entire CData portfolio are available on the CData website. Additional PoC deployment licensing is also available, so software providers can test all functionality and deployed environments.
  • A dedicated technical account manager and access to CData engineering resources is provided as part of the PoC process.