Skip to content

data-processing-extensions-overview.md

Latest commit

 

History

History
75 lines (50 loc) · 6.79 KB

data-processing-extensions-overview.md

File metadata and controls

75 lines (50 loc) · 6.79 KB
title Data processing extensions overview
description See which data processing extensions are included with Reporting Services, and learn how to add custom data processing to your report server.
ms.date 09/25/2024
ms.service reporting-services
ms.subservice extensions
ms.topic reference
helpviewer_keywords
data processing extensions [Reporting Services], about extensions
ms.custom
updatefrequency5
sfi-image-nochange

Data processing extensions overview

Data processing extensions in [!INCLUDEssRSnoversion] enable you to connect to a data source and retrieve data. They also serve as a bridge between a data source and a dataset. [!INCLUDEssRSnoversion] data processing extensions are modeled after a subset of the [!INCLUDEmsCoName] [!INCLUDEdnprdnshort] data provider interfaces.

The following table lists the data processing extensions included with [!INCLUDEssRSnoversion].

Data processing extension Description
Data processing extension for [!INCLUDEssNoVersion] Uses the .NET Framework Data Provider for SQL Server to connect to and retrieve data from the [!INCLUDEssDEnoversion].
Data processing extension for OLE DB Uses the .NET Framework Data Provider for OLE DB. With this extension, the report server can query any data source that has an OLE DB provider.
Data processing extension for Oracle Uses the .NET Framework Data Provider for Oracle. With this extension, the report server can access Oracle data sources through Oracle client connectivity software.
Data processing extension for ODBC Uses the .NET Framework Data Provider for ODBC. With this extension, the report server can access data in any database for which there's an ODBC driver.

You can use the [!INCLUDEssRS] data processing API to add custom data processing to your report server.

Note

[!INCLUDEssRSnoversion] has built-in support for data providers in the [!INCLUDEdnprdnshort]. If you have already implemented a full data provider, you do not need to implement a [!INCLUDEssRSnoversion] data processing extension. However, you should consider extending your data provider to include functionality specific to [!INCLUDEssRSnoversion] 2005, which includes secure connection credentials and server-side aggregates.

Each of the data processing extensions included with [!INCLUDEssRSnoversion] uses a common set of interfaces. These common interfaces ensure that each extension implements comparable functionality.

You can develop data processing extensions for your own data sources, or you can use the interfaces to add another layer of data processing to common database infrastructures. You can deploy your custom data processing extensions to enable seamless integration of data into the existing report servers in your organization. You can also use them as part of a custom reporting suite that you provide to your consumers.

:::image type="content" source="../../../reporting-services/extensions/data-processing/media/bk-dataprocess-extensions.gif" alt-text="Screenshot of the Reporting Services data processing extension architecture.":::
Reporting Services data processing extension architecture

The advantages to implementing a custom [!INCLUDEssRSnoversion] data processing extension include:

  • A simplified data access architecture, often with better maintainability and improved performance.

  • The ability to directly expose extension-specific functionality to consumers.

  • A specific interface for your consumers to access your data source within [!INCLUDEssRSnoversion].

Data extension process flow

Before developing your custom data extension, you should understand how the report server uses data extensions to process data. You should also understand the constructors and methods that are called by the report server.

:::image type="content" source="../../../reporting-services/extensions/data-processing/media/bk-ext-01.gif" alt-text="Screenshot of the step-by-step process flow of a data extension that is called by the report server.":::

The illustration shows the following sequence of events:

  1. The report server creates a connection object and passes in the connection string and credentials associated with the report.

  2. The command text of the report is used to create a command object. In the process, the data processing extension might include code that parses the command text and creates any parameters for the command.

  3. Once the command object and any parameters are processed, a data reader is generated that returns a result set and enables the report server to associate the report data with the report layout.

Developer requirements

Developing a [!INCLUDEssRSnoversion] data processing extension requires you to have:

  • A deployment computer with Report Designer or a report server installed.

  • A development computer with [!INCLUDEmsCoName] [!INCLUDEvsprvs2005] or greater, or the [!INCLUDEmsCoName] [!INCLUDEdnprdnshort] Software Development Kit (SDK) installed.

  • An in-depth understanding of [!INCLUDEssRSnoversion] features and capabilities.

  • An in-depth understanding of [!INCLUDEmsCoName] [!INCLUDEvstecado] architecture, [!INCLUDEdnprdnshort] data providers, ADO.NET DataSet objects, and the common [!INCLUDEvstecado] interfaces.

  • Development experience in a [!INCLUDEdnprdnshort] language such as [!INCLUDEmsCoName] Visual C# or [!INCLUDEmsCoName] [!INCLUDEvisual-basic] .NET.

Related content