After connecting to your data source, set DataModel to more closely match the data representation to the structure of your data.

Connecting to XML

Below are example connection strings to XML files or streams, using the provider's default data modeling configuration (see below):

Modeling XML Data

The DataModel property is the controlling property over how your data is represented into tables and toggles the following basic configurations.

• Document (default): Model a top-level, document view of your XML data. The provider returns nested elements as aggregated XML.

• FlattenedDocuments: Detect nested documents and implicitly join them into a single table.

• Relational: Return individual, related tables from hierarchical data. The tables contain a primary key and a foreign key that links to the parent document.

See Parsing Hierarchical Data

1 - Authenticating using oAuth

AuthScheme: Set this to AzureAD.

See oAuth Authentication

2 - Authenticating using MSI Authentication

If you are running Dataverse on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:

• AuthScheme: Set this to AzureMSI.

The MSI credentials will then be automatically obtained for authentication.

3 - Schema

Dataverse supports schema values of 'System' and 'Entities' and can be set using the Schema property.

Using 'System' for Schema property uses the Web API to query entities/tables.

Using 'Entities' for Schema property uses the EntityDefinitions entity set path and retrieves information about EntityMetadata EntityType entities/tables. This will often result in more user friendly names, though requires extra metadata requests.

Connecting to LDAP

The connector for the LDAP supports connecting to LDAP server objects. To connect, set the required properties.

Required Properties

• Server: The domain name or IP of the LDAP server.

• Port: The port setting defaults to port=389. Specifying the port to a different setting is optional.

• BaseDN: This property is used for limiting results to specific subtrees. Specifying a narrow BaseDN (Base Distinguished Name) may greatly increase performance. For example, a value of cn=users,dc=domain only returns results contained within cn=users and its children.

Optional Properties

Optional properties can be used to further refine control of the returned results.

• FollowReferrals: This property follows referrals when TRUE. The returned response then becomes read only. To modify data returned by a referral server, open a new connection to the server by specifying server and port.

• Scope: This property enables more control over the search depth of the LDAP tree, starting with BaseDN. Limiting the Scope can greatly improve search performance. Set the Scope to one of the following values:

  • WholeSubtree: Limit the scope of the search to the BaseDN and all of its descendants.

  • SingleLevel: Limit the scope of the search to the BaseDN and its direct descendants.

  • BaseObject: Limit the scope of the search to the base object only.

• LDAPVersion: The LDAP version used to connect to and communicate with the server. Set this property to 2.

Authenticating to LDAP

To authenticate requests, set the User and Password properties to valid LDAP credentials. For example: set User to Domain\\BobF or cn=Bob F,ou=Employees,dc=Domain.

The AuthMechanism properties for the provider are as follows:

• SIMPLE: The default plaintext value of the authentication mechanism to login to the server.

• DIGESTMD5: Authenticates to the LDAP server using DIGESTMD5 authentication.

• NEGOTIATE: Negotiates whether to use NTLN or Kerberos when authenticating to the server.

SSL Configuration

By default, the driver uses plaintext when communicating with the server set to port=389. The driver automatically switches to use SSL when talking to the LDAP on port=636. You can force the connection to use the SSL connection property when set to SSL=TRUE.

The Provider for RSS supports connecting to RSS and Atom feeds, as well as feeds with custom extensions. To connect to a feed, set the URI property. The provider also supports accessing secure feeds. A variety of authentication mechanisms are supported. See the connection properties for details.

1 Authenticating to Active Directory

To authenticate requests, set the User and Password properties to valid Active Directory credentials (e.g., set User to "Domain\\BobF" or "cn=Bob F,ou=Employees,dc=Domain").

The provider uses plaintext authentication by default, since the provider attempts to negotiate TLS/SSL with the server. You can specify another authentication method with AuthMechanism.

By default, the connector attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store.

To specify another certificate, set the SSLServerCert property for the available formats to do so.

2 Connecting to Active Directory

Set Server and Port for basic connectivity. Additionally, you can fine-tune the connection with the following:

• FollowReferrals: When set, the provider surfaces data as views from only referral servers. To modify data on a referral server, you must specify this server with Server and Port.

• LDAPVersion: Set this to the version of the protocol your server implements; by default, the provider uses version 2.

• UseDefaultDC: Set this to connect to the default Domain Controller and authenticate using the current user credentials.

3 Fine Tuning Data Access

The following properties control the scope of data returned:

• BaseDN will limit the scope of LDAP searches to the height of the distinguished name provided. Note: Specifying a narrow BaseDN may greatly increase performance; for example, a value of "cn=users,dc=domain" will only return results contained within "cn=users" and its children.

• Scope: This property enables more granular control over the data to return from a subtree.

Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Connecting to GraphQL

Set the following to connect:

• URL: Specify the URL of the GraphQL service, for example https://api.example.com/graphql.

• Location: Set this to the file path containing any custom defined schemas for the GraphQL service.

Authenticating to GraphQL

The driver supports the following types of authentication:

• Basic

• OAuth 1.0 & 2.0

• OAuthPKCE

• AWS Cognito Credentials:

  • AwsCognitoSrp

  • AwsCognitoBasic

Basic

Set AuthScheme to Basic. You must specify the User and Password of the GraphQL service.

OAuth

In all OAuth flows, you must set AuthScheme to OAuth and OAuthVersion to 1.0 or 2.0. The following sections assume you have done so.

Desktop Applications

After setting the following connection properties, you are ready to connect:

• OAuthRequestTokenURL: Required for OAuth 1.0. This is the URL where the application makes a request for the request token.

• OAuthAuthorizationURL: Required for OAuth 1.0 and 2.0. This is the URL where the user logs into the service and grants permissions to the application. In OAuth 1.0 if permissions are granted the request token is authorized.

• OAuthAccessTokenURL: Required for OAuth 1.0 and 2.0. This is the URL where the request for the access token is made. In OAuth 1.0 the authorized request token is exchanged for the access token.

• OAuthRefreshTokenURL: Required for OAuth 2.0. In OAuth 2.0 this is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the access token URL.

• OAuthClientId: Set this to the client Id in your application settings. This is also called the consumer key.

• OAuthClientSecret: Set this to the client secret in your application settings. This is also called the consumer secret.

• CallbackURL: Set this to http://localhost:33333. If you specified a redirect URL in your application settings, this must match.

• InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the access token in the connection string.

When you connect, the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:

1. Extracts the access token from the callback URL and authenticates requests.

2. Refreshes the access token when it expires.

3. Saves OAuth values in OAuthSettingsLocation. These values persist across connections.

Web Applications

When connecting via a Web application, or if the provider is not authorized to open a browser window, use the provided stored procedures to get and manage the OAuth token values.

Note: You can extend the stored procedure schemas to set defaults for the OAuth URLs or other connection string properties.

Set Up the OAuth Flow

Provide the OAuth URLs to authenticate in the Web flow.

• OAuthRequestTokenURL: Required for OAuth 1.0. This is the URL where the application makes a request for the request token.

• OAuthAuthorizationURL: Required for OAuth 1.0 and 2.0. This is the URL where the user logs into the service and grants permissions to the application. In OAuth 1.0 if permissions are granted the request token is authorized.

• OAuthAccessTokenURL: Required for OAuth 1.0 and 2.0. This is the URL where the request for the access token is made. In OAuth 1.0 the authorized request token is exchanged for the access token.

• OAuthRefreshTokenURL: Required for OAuth 2.0. In OAuth 2.0 this is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the access token URL.

Get an Access Token

In addition to the OAuth URLs, set the following additional connection properties to obtain the OAuthAccessToken:

• OAuthClientId: Set this to the client Id in your application settings.

• OAuthClientSecret: Set this to the client secret in your application settings.

You can then call stored procedures to complete the OAuth exchange:

1. Call the GetOAuthAuthorizationURL stored procedure. Set the AuthMode input to WEB and set the CallbackURL input to the Redirect URI you specified in your application settings. The stored procedure returns the URL to the OAuth endpoint.

2. Log in and authorize the application. You are redirected back to the callback URL.

3. Call the GetOAuthAccessToken stored procedure. Set the AuthMode input to WEB.

   In OAuth 1.0, set the Verifier input to the "oauth_verifier" parameter. Extract the verifier code from the callback URL. Additionally, set the AuthToken and AuthSecret to the values returned by GetOAuthAccessToken.

   In OAuth 2.0, set the Verifier input to the "code" parameter in the query string of the callback URL.

Connect to Data and Refresh the Token

The OAuthAccessToken returned by GetOAuthAccessToken has a limited lifetime. To automatically refresh the token, set the following on the first data connection.

OAuth Endpoints

• OAuthRequestTokenURL

• OAuthAuthorizationURL

• OAuthAccessTokenURL

• OAuthRefreshTokenURL

OAuth Tokens and Keys

• OAuthClientId

• OAuthClientSecret

• OAuthRefreshToken

• OAuthAccessToken

Alternatively, use the RefreshOAuthAccessToken stored procedure to manually refresh the token.

Initiate OAuth

• InitiateOAuth: Set this to REFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.

• OAuthSettingsLocation: Set this to the location where the provider saves the OAuth values. These values persist across connections.

On subsequent data connections, set the following:

• InitiateOAuth

• OAuthSettingsLocation

• OAuthRequestTokenURL

• OAuthAuthorizationURL

• OAuthAccessTokenURL

• OAuthRefreshTokenURL

Headless Machines

To create GraphQL data sources on headless servers or other machines on which the provider cannot open a browser, you need to authenticate from another machine. Authentication is a two-step process.

1. Choose one of two options:

   • Option 1: Obtain the OAuthVerifier value as described in "Obtain and Exchange a Verifier Code" below.

   • Option 2: Install the provider on a machine with an internet browser and transfer the OAuth authentication values after you authenticate through the usual browser-based flow, as described in "Transfer OAuth Settings" below.

2. Then configure the provider to automatically refresh the access token on the headless machine.

Option 1: Obtain and Exchange a Verifier Code

Set the following properties on the headless machine:

• InitiateOAuth: Set this to OFF.

• OAuthClientId: Set this to the application Id in your application settings.

• OAuthClientSecret: Set this to the application secret in your application settings.

You can then follow the steps below to authenticate from another machine and obtain the OAuthVerifier connection property.

1. Call the GetOAuthAuthorizationURL stored procedure with the CallbackURL input parameter set to the exact Redirect URI you specified in your application settings.

2. Save the value of the returned AuthToken and AuthKey if OAuthVersion is set to 1.0. They are used in the next step.

3. Open the returned URL in a browser. Log in and grant permissions to the provider. You are then redirected to the callback URL, which contains the verifier code.

4. Save the value of the verifier code. Later, you must set this in the OAuthVerifier connection property.

On the headless machine, set the following connection properties to obtain the OAuth authentication values:

• OAuthRequestTokenURL: Required for OAuth 1.0. In OAuth 1.0 this is the URL where the application makes a request for the request token.

• OAuthAuthorizationURL: Required for OAuth 1.0 and 2.0. This is the URL where the user logs into the service and grants permissions to the application. In OAuth 1.0 if permissions are granted the request token is authorized.

• OAuthAccessTokenURL: Required for OAuth 1.0 and 2.0. This is the URL where the request for the access token is made. In OAuth 1.0 the authorized request token is exchanged for the access token.

• OAuthRefreshTokenURL: Required for OAuth 2.0. In OAuth 2.0 this is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the access token URL.

• OAuthClientId: Set this to the client Id in your application settings.

• OAuthClientSecret: Set this to the client secret in your application settings.

• CallbackURL: Set this to http://localhost:33333. If you specified a redirect URL in your application settings, this must match.

• InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the access token in the connection string.

Connect to Data

After the OAuth settings file is generated, set the following properties to connect to data:

• OAuthSettingsLocation: Set this to the location containing the encrypted OAuth authentication values. Make sure this location gives read and write permissions to the provider to enable the automatic refreshing of the access token.

• InitiateOAuth: Set this to REFRESH.

Option 2: Transfer OAuth Settings

Follow the steps below to install the provider on another machine, authenticate, and then transfer the resulting OAuth values.

On a second machine, install the provider and connect with the following properties set:

• OAuthSettingsLocation: Set this to a writable location.

• InitiateOAuth: Set this to GETANDREFRESH.

• OAuthClientId: Set this to the Client Id in your application settings.

• OAuthClientSecret: Set this to the Client Secret in your application settings.

• CallbackURL: Set this to the Callback URL in your application settings.

Test the connection to authenticate. The resulting authentication values are written, encrypted, to the location specified by OAuthSettingsLocation. After you have successfully tested the connection, copy the OAuth settings file to your headless machine. On the headless machine, set the following connection properties to connect to data:

• InitiateOAuth: Set this to REFRESH.

• OAuthSettingsLocation: Set this to the location of your OAuth settings file. Make sure this location gives read and write permissions to the provider to enable the automatic refreshing of the access token.

OAuthPKCE

NOTE:OAuth Proof Key for Code Exchange (PKCE) is an extension to the OAuth 2.0 Authorization Code flow.

Desktop Applications

After setting the following, you are ready to connect:

• AuthScheme: Set this to OAuthPKCE.

• InitiateOAuth: Set this to GETANDREFRESH to avoid making the OAuth exchange manually and manually setting the access token in the connection string.

• OAuthClientId: Set this to the client Id generated when creating your OAuth application on the GraphQL service.

• OAuthAuthorizationURL: Set this to the authorization URL for the GraphQL service. This is the URL where the user logs into the service and grants permissions to the OAuth application, for example https://api.example.com/authorize.

• OAuthAccessTokenURL: Set this to the access token URL for the GraphQL service. This is the URL where the request for the access token is made, for example https://api.example.com/token.

• OAuthRefreshTokenURL: Set this to the refresh token URL for the GraphQL service. This is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the OAuthAccessTokenURL.

When you connect, the provider opens the OAuth authorization endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:

1. Extracts the authorization code from the callback URL.

2. Exchanges the authorization code for an access and refresh token.

3. Refreshes the access token when it expires.

4. Saves OAuth values in OAuthSettingsLocation. These values persist across connections.

Web Applications

When connecting via a Web application, or if the provider is not authorized to open a browser window, use the provided stored procedures to get and manage the OAuth token values.

Set Up the OAuth Flow

Provide the OAuth URLs to authenticate in the Web flow:

• OAuthAuthorizationURL: This is the URL where the user logs into the service and grants permissions to the OAuth application.

• OAuthAccessTokenURL:This is the URL where the request for the access token is made.

• OAuthRefreshTokenURL: This is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the access token URL.

Get an Access Token

In addition to the OAuth URLs, set OAuthClientId to the client Id in your application settings to obtain the OAuthAccessToken.

You can then call stored procedures to complete the OAuth exchange:

2. Log in and authorize the application. You are redirected back to the callback URL.

3. Set the AuthMode input to WEB.

   Set the Verifier input to the value of the "code" parameter in the query string of the callback URL.

Connect to Data and Refresh the Token

OAuth Endpoints

• OAuthAuthorizationURL

• OAuthAccessTokenURL

• OAuthRefreshTokenURL

OAuth Tokens and Keys

• OAuthClientId

• OAuthRefreshToken

• OAuthAccessToken

Initiate OAuth

• InitiateOAuth: Set this to REFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.

• OAuthSettingsLocation: Set this to the location where the provider saves the OAuth values. These values persist across connections.

On subsequent data connections, set the following:

• InitiateOAuth

• OAuthSettingsLocation

• OAuthAuthorizationURL

• OAuthAccessTokenURL

• OAuthRefreshTokenURL

AWS Cognito Credentials

If you want to use the provider with a user registered in a User Pool in AWS Cognito, set the following properties to authenticate:

• AuthScheme: Set this to AwsCognitoSrp (recommended). You can also use AwsCognitoBasic.

• AWSCognitoRegion: Set this to the region of the User Pool.

• AWSUserPoolId: Set this to the User Pool Id.

• AWSUserPoolClientAppId: Set this to the User Pool Client App Id.

• AWSUserPoolClientAppSecret: Set this to the User Pool Client Secret.

• AWSIdentityPoolId: Set this to the Identity Pool Id of the Identity Pool that is linked with the User Pool.

• User: Set this to the username of the user registered in the User Pool.

• Password: Set this to the password of the user registered in the User Pool.

To connect with the provider's data modeling defaults, set the URI of the XML resource and authenticate. This section provides connection and authentication guides for the available XML data sources. See Connecting to XML Data Sources to control the data representation.

Authenticating to the Data Source

Here is an overview of the authentication properties corresponding to each data source:

Connecting to Local Files

Set the URI to an XML file. Below is an example connection string:

Connecting to HTTP XML Streams

Set the URI to the HTTP or HTTPS URL of the XML resource you want to access as a table. Set AuthScheme to use the following authentication types. The provider also supports OAuth authentication; see Using OAuth for more information.

• HTTP:To use HTTP Basic or Digest, set the User and Password and set the corresponding AuthScheme. Set CustomHeaders if you need access to the request headers. Set CustomUrlParams to modify the URL query string.

• Windows (NTLM): Set the Windows User and Password to connect and set AuthScheme to "NTLM".

• Kerberos and Kerberos Delegation: To authenticate with Kerberos, set the User and Password and set AuthScheme to NEGOTIATE. To use Kerberos Delegation, set AuthScheme to KERBEROSDELEGATION.

For example:

Connecting to Amazon S3

Set the URI to an XML document in a bucket. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set to an Amazon Web Services Access Key (a user name).

• AWSSecretKey: Set to an Amazon Web Services Secret Key.

For example:

Optionally, specify AWSRegion.

Connecting to Wasabi

Set the URI to the bucket and folder. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set this to an Wasabi Access Key (a username)

• AWSSecretKey: Set this to an Wasabi Secret Key.

For example:

Optionally, specify AWSRegion in addition.

Connect to Azure Blob Storage

Set the URI to the name of your container and the name of the blob. Additionally, set the following properties to authenticate:

• AzureAccount: Set this to the account associated with the Azure blob.

• AzureAccessKey: Set the to the access key associated with the Azure blob.

For example:

Connecting to Google Drive

Set the URI to the path to an XML file and authenticate using the OAuth standard. See Connecting to Google Drive for an authentication guide. You can connect with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the following connection string:

Connecting to Box

Set the URI to the path to an XML file and authenticate using the OAuth standard. See Connecting to Box for an authentication guide. You can authenticate with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the following connection string:

Connecting to Dropbox

Set the URI to the path to an XML file and authenticate using the OAuth standard. You can authenticate with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the following connection string:

Connecting to SharePoint Online

Set the URI to a document library containing XML files. To authenticate, set User and Password and SharepointUrl.

Connecting to FTP

Set the URI to the address of the server followed by the path to an XML file. To authenticate, set User and Password.

Securing XML Connections

By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.

Below is the raw data used throughout this chapter. The data includes entries for people, the cars they own, and various maintenance services performed on those cars:

Establishing a Connection

Connecting to XML/JSON Data Sources

The Provider for REST allows connecting to local and remote XML/JSON resources. Set the URI property to the XML/JSON resource location, in addition to any other properties necessary to connect to your data source.

Connecting to Local Files

Set the URI to a folder containing XML/JSON files.

Below is an example connection string:

Connecting to HTTP XML/JSON Streams

Set the URI to the HTTP or HTTPS URL of the XML/JSON resource you want to access as a table. Set AuthScheme to use the following authentication types. The provider also supports OAuth authentication;

• HTTP:To use HTTP Basic or Digest, set the User and Password and set the corresponding AuthScheme. Set CustomHeaders if you need access to the request headers. Set CustomUrlParams to modify the URL query string.

• Windows (NTLM): Set the Windows User and Password to connect and set AuthScheme to "NTLM".

• Kerberos and Kerberos Delegation: To authenticate with Kerberos, set the User and Password and set AuthScheme to NEGOTIATE. To use Kerberos Delegation, set AuthScheme to KERBEROSDELEGATION.

For example:

Connecting to Amazon S3

Set the URI to an XML/JSON document in a bucket. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set this to an Amazon Web Services Access Key (a username).

• AWSSecretKey: Set this to an Amazon Web Services Secret Key.

For example:

Optionally, specify AWSRegion in addition.

Note: It is also possible to connect to S3-compatible services by specifying its base Url. For example, if the Url conn prp is set to http://s3.%region%.myservice.com and Region is region-1, then we will generate request URLs like https://s3.region-1.myservice.com/bucket/... (or like https://bucket.s3.region-1.myservice.com/..., if the UseVirtualHosting property is true).

Connecting to Oracle Cloud Object Storage

Set the URI to an XML/JSON document in a bucket. Additionally, set the following properties to authenticate:

• AccessKey: Set this to an Oracle cloud Access Key.

• SecretKey: Set this to an Oracle cloud Secret Key.

• OracleNamespace: Set this to an Oracle cloud namespace.

For example:

Optionally, specify Region in addition.

Connecting to Wasabi

Set the URI to an XML/JSON document in a bucket. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set this to a Wasabi Access Key (a username)

• AWSSecretKey: Set this to a Wasabi Secret Key.

Optionally, specify AWSRegion in addition.

For example:

Connect to Azure Blob Storage

Set the URI to the name of your container and the name of the blob. Additionally, set the following properties to authenticate:

• AzureAccount: Set this to the account associated with the Azure blob.

• AzureAccessKey: Set this to the access key associated with the Azure blob.

For example:

Connect to Azure Data Lake Store Gen 2

Set the URI to the name of the file system, the name of the folder which contacts your REST files, and the name of an XML/JSON file. Additionally, set the following properties to authenticate:

• AzureAccount: Set this to the account associated with the Azure data lake store.

• AzureAccessKey: Set this to the access key associated with the Azure data lake store.

For example:

Connecting to Box

Set the URI to the path to a XML/JSON file. To authenticate to Box, use the OAuth authentication standard. See Connecting to Box (Collaboration section) for an authentication guide.

For example:

Connecting to Dropbox

Set the URI to the path to a XML/JSON file. To authenticate to Dropbox, use the OAuth authentication standard. See Connecting to Dropbox for an authentication guide. You can authenticate with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the connection string below:

Connecting to SharePoint Online SOAP

Set the URI to a document library containing XML/JSON files. To authenticate, set User and Password and SharepointUrl.

For example:

Connecting to SharePoint Online REST

Set the URI to a document library containing XML/JSON files. SharepointUrl is optional. If not provided, the driver will work with the root drive. To authenticate, use the OAuth authentication standard.

For example:

Connecting to FTP

Set the URI to the address of the server followed by the path to the XML/JSON file. To authenticate, set User and Password.

For example:

Connecting to Google Cloud Storage

Set the URI to the path to the name of the file system, the name of the folder which contains your REST files, and the name of an XML/JSON file. To authenticate to Google APIs, provide a ProjectId.

For example:

Securing REST Connections

By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.

Connecting to JSON Data Sources

Below is an overview of the authentication properties corresponding to each data source:

Connecting to Local Files

Set the URI to a JSON file.

Below is an example connection string:

Connecting to HTTP JSON Streams

Set the URI to the HTTP or HTTPS URL of the JSON resource you want to access as a table. Set AuthScheme to use the following authentication types. The provider also supports OAuth authentication;

• HTTP

  To use HTTP Basic or Digest, set the User and Password. Set CustomHeaders if you need access to the request headers. Set CustomUrlParams to modify the URL query string.

• Windows (NTLM)

  Set the Windows User and Password to connect and set AuthScheme to "NTLM".

• Kerberos and Kerberos Delegation

  To authenticate with Kerberos, set the User and Password and set AuthScheme to NEGOTIATE. To use Kerberos Delegation, set AuthScheme to KERBEROSDELEGATION.

For example:

Connecting to Amazon S3

Set the URI to a JSON document in a bucket. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set this to an Amazon Web Services Access Key (a username).

• AWSSecretKey: Set this to an Amazon Web Services Secret Key.

For example:

Optionally, specify AWSRegion.

Connecting to Wasabi

Set the URI to the bucket and folder. Additionally, set the following properties to authenticate:

• AWSAccessKey: Set this to an Wasabi Access Key (a username)

• AWSSecretKey: Set this to an Wasabi Secret Key.

For example:

Optionally, specify AWSRegion in addition.

Connect to Azure Blob Storage

Set the URI to the name of your container and the name of the blob. Additionally, set the following properties to authenticate:

• AzureAccount: Set this to the account associated with the Azure blob.

• AzureAccessKey: Set the to the access key associated with the Azure blob.

For example:

Connecting to Google Drive

Set the URI to the path to a JSON file. To authenticate to Google APIs, use the OAuth authentication standard. You can connect with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the connection string below:

Connecting to Box

Set the URI to the path to a JSON file. To authenticate to Box, use the OAuth authentication standard. You can authenticate with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the connection string below:

Connecting to Dropbox

Set the URI to the path to a JSON file. To authenticate to Dropbox, use the OAuth authentication standard. You can authenticate with a user account or a service account. In the user account flow, you do not need to set any connection properties for your user credentials, as shown in the connection string below:

Connecting to SharePoint Online

Set the URI to a document library containing JSON files. To authenticate, set User and Password and SharepointUrl.

Connecting to FTP

Set the URI to the address of the server followed by the path to a JSON file. To authenticate, set User and Password.

Securing JSON Connections

By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.

The provider offers three basic configurations to model nested data in XML as tables.

Flattened Documents Model

For users who simply need access to the entirety of their XML data, flattening the data into a single table is the best option. The provider will use streaming and only parses the XML data once per query in this mode.

Joining Object Arrays into a Single Table

With DataModel set to "FlattenedDocuments", the provider returns a separate table for each object array, but implicitly JOINed to the parent table. Any nested sibling XPath values (child paths at the same height) will be treated as a SQL CROSS JOIN.

Example

Below is a sample query and the results, based on the sample document in and parsing based on the XPaths /root/people, /root/people/vehicles, and /root/people/vehicles/maintenance. This implicitly JOINs the people element with the vehicles element and implicitly JOINs the vehicles element with the maintenance element.

Connection String

Use the following connection string to query the in this example.

Query

The following query drills into the nested elements in each people element. Since the XPath property included the vehicles node as an XML path, you can query an element of a vehicle explicitly.

Results

With horizontal and vertical flattening based on the described paths, each vehicle element is implicitly JOINed to its parent people element and each maintenance element is implicitly JOINed to its parent vehicle element.

Relational Model:

The provider for XML can be configured to create a relational model of the data in the XML file or source, treating each XPath as an individual table containing a primary key and a foreign key that links to the parent document. This is particularly useful if you need to work with your XML data in existing BI, reporting, and ETL tools that expect a relational data model.

Joining Nested Arrays as Tables

With DataModel set to "Relational", any JOINs are controlled by the query. Any time you perform a JOIN query, the XML file or source will be queried once for each table included in the query.

Example

Connecting String

Set the DataModel connection property to "Relational" and set the XPath connection property to "/root/people;/root/people/vehicles;/root/people/vehicles/maintenance;" to perform the following query and see the example result set.

Query

The following query explicitly JOINs the people, vehicles, and maintenance tables.

Results

In the example query, each maintenance element is JOINed to its parent vehicle element, which is JOINed to its parent people element to produce a table with 8 rows (2 maintenance entries for each of 2 vehicles each for 2 people).

Top-Level Document Model

Using a top-level document view of the data provides ready access to top-level elements. The provider returns nested elements in aggregate, as single columns.

One aspect to consider is performance. You forego the time and resources to process and parse nested elements -- the provider parses the returned data once, using streaming to read the data. Another consideration is your need to access any data stored in nested parent elements, and the ability of your tool or application to process XML.

Modeling a Top-Level Document View

With DataModel set to "Document" (the default), the provider scans only a single element, the top-level element by default. The top-level elements are available as columns due to default object flattening. Nested elements are returned as aggregated XML.

You can set XPath to specify an element other than the top-level one.

Example

Connection String

Set the DataModel connection property to "Document" to perform the following query and see the example result set. The provider will scan only the XPath value below:

Query

The following query pulls the top-level elements and the subelements of the vehicles element into the results.

Results

With a document view of the data, the personal element is flattened into 4 columns and the source and vehicles elements are returned as individual columns, resulting in a table with 6 columns.