Redigera

Dela via


Specify Connections for Custom Data Processing Extensions

You can create or use third-party custom data processing extensions on a report server to enhance the data processing capability of supported data sources, or to support additional types of data sources that are not available in a default Reporting Services installation. Connections are handled differently depending on the implementation. The following implementations are available for data processing extensions:

  • Custom .NET Framework data providers (if you are accessing data from DB2.NET, Oracle, ODP.NET, or Teradata data sources, you might be using a custom .NET data provider)

  • Custom data processing extensions that support IDbConnection

  • Custom data processing extensions that support IDbConnectionExtension

Note

Check with your third-party provider to find out how your custom data processing extension is implemented.

Impersonation and Custom Data Processing Extensions

If your custom data processing extension connects to data sources using impersonation, you must use the Open method on either the IDbConnection or IDbConnectionExtension interfaces to make the request. Alternately, you can store the user identity object (System.Security.Principal.WindowsIdentity) and then reuse it in the other data processing extension APIs.

In previous releases of Reporting Services, all custom data processing extensions were called under user impersonation. In this release, only the Open method will be called while impersonating the user. If you have an existing data processing extension that requires integrated security, you must modify your code to use the Open method or store the user identity object.

Connections for Custom .NET Framework Data Providers

When configuring a report to use a specific data source, you set properties that determine the data source type, connection string, and credentials that are used to access the data source. The following table describes the credential types that are supported for .NET Framework data providers. For more information about setting report data source properties, see Specify Credential and Connection Information for Report Data Sources.

Credentials Connections
Integrated security If your data provider supports it, you can use Windows integrated security. The request is sent using the credentials of the current user.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).
Windows Authentication If your data provider supports it, you can use a Windows domain user account. The report server impersonates the user account before the data processing extension is called.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).
Database credentials Database authentication is not supported for connections made through a custom .NET data provider. The report server will fail the connection in all cases.
No credentials You can use the no credentials option with custom .NET data providers. If the unattended execution account is specified, the connection string determines the credentials that are used. The report server impersonates the unattended execution account to make the connection.

If the unattended execution account is not defined, the report server will fail the connection. For more information about defining the account, see Configure the Unattended Execution Account (Report Server Configuration Manager).

Connections for IDbConnection

If you are using a custom data processing extension that only supports IDbConnection, you must specify the connection in the following way:

  1. Configure the unattended execution account. Configuring this account is required for connections made using IDbConnection. The report server impersonates the account when making the connection.

  2. Configure the data source properties on the report to use No credentials.

  3. Put the credentials used to connect to the data source in the connection string.

When using IDbConnection, the following credential types are not supported: integrated security, Windows user accounts, and database credentials. If a data source connection uses these options, the connection will fail on the report server.

Connections for IDbConnectionExtension

If you are using a custom data processing extension and supports, IDbConnectionExtension, you can specify the connection in the following ways:

Credentials Connections
Integrated security If your data provider supports it, you can use Windows integrated security with custom data processing extensions that use IDbConnectionExtension.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).
Windows Authentication If your data provider supports it, you can use a Windows domain user account for custom data processing extensions that use IDbConnectionExtension.

The report server impersonates the user account before the data processing extension is called. When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).
Database credentials You can use database authentication to configure connections for custom data processing extensions that use IDbConnectionExtension.
No credentials If the unattended execution account is specified, the connection string determines the credentials that are used.

If the unattended execution account is not defined, the report server will fail the connection.