My team tried to use SSRS for a project and we ran into way too many limitations.
It does not seem designed to handle application specific reporting scenarios.
We opted to go with Active Reports .Net and find it to be an excellent product.
We built a reporting framework usng CSLA BOs as the datasource for unbound reports. The framework fetches the Header data and the Detail data and then maps the properties to the controls.
We built 50 reports in a couple of weeks using this framework. Designing the layout of the report was the hardest part.
The only catch is that the data has to be pre-sorted and grouped - the report tool does not do it for you. So your queries have to be just a little bit smarter.
Joe
Microsoft has a skeleton code project to jump start off
with in SQL 2005 Samples called: "FsiDataExtension" (http://msdn2.microsoft.com/en-us/library/ms160918.aspx).
You can get the sample using the SQL 2005 installer, or off of Microsoft's
website. Here is another good example:
http://www.devx.com/dbzone/Article/31336/0/page/1
There are a few little tips we found out.
Server Side:
Copy DLLs to c:\Program Files\Microsoft SQL
Server\MSSQL.3\Reporting Services\ReportServer\bin. This Includes CSLA.
In the ReportServer directory, in rssrvpolicy.config, you need to have a "code group" for both the your strong key and for CSLA's, which would be different than yours. We used secutil to generate "publickeyblobs" for both (secutil -hex -s dllname).
E.g:
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="Kodiak_Strong_Name"
Description="Key for Your DLLs.">
<IMembershipCondition
class="StrongNameMembershipCondition"
version="1"
PublicKeyBlob="0q238490821093480293845908230945802938450923840582390485really-long"
/>
</CodeGroup>
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="CSLA_Strong_Name"
Description="Key for CSLA DLL.">
<IMembershipCondition
class="StrongNameMembershipCondition"
version="1" PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100AFE494440F03A57E64464D6D407F83E51F2C8A412F8E9144BDAF02DF16234C2074149908E37A67E060E61E23456E985515C1FAE98050E802CE6859E9929587C5BB66AC32D21DBCF823D3E055CD9483AF45BDC12DC4A47168CF04FC384F485F3EA588B72A1FD60BEC53AD6DF5B1A26FE4F9BBBCE560AAF27014F65D099A1994BE"
/>
</CodeGroup>
In the same ReportServer directory, web.config contains the appsettings and connectionsettings for the two-tier CLSA connection to the database.
In the ReportServer directory, the rsreportserver.config file contains a line in the Data section for your new data source.
E.g:
<Extension Name="KODIAK"
Type="Kodiak.Infrastructure.ReportConnector.CgConnection,Infrastructure.ReportConnector"/>
Client Side:
(for the Business Intelligent Report Designer (integrates
into Visual Studio 2005)... Can be installed off of the SQL 2005 Disk):
Copy DLLs to Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies. You will also need CSLA, and Microsoft.ReportingServices.Infrastructure (you can get that off of your reporting server).
In the same directory, RSReportDesigner.config, you need lines for the your new data source in the Data and Designer sections. Note that the lines are different -- the data section refers to your project namespaces and assemblies, whereas the Designer section references Microsoft stuff.
<Extension Name="CSLADATA"
Type="XYZ.ReportConnector.Connection, XYZ.ReportConnector"/>
<Extension Name=" CSLADATA "
Type="Microsoft.ReportingServices.QueryDesigners.VDTQueryDesigner,Microsoft.ReportingServices.QueryDesigners"/>
In the same directory, you need the CodeGroup for your strong key, with its PublicKeyBlob.
In this directory's parent (the IDE directory itself), devenv.exe.config needs the application settings -- appsettings for CSLA authentication and connectionstring for two-tier db access. Or three tier.
You don't need to publish your reports!!! You can just send them from the client and the Reporting server will temporarily store them. This allows for a more dynamic reporting solution where you could change your RDL files on the fly. See this article. http://msdn2.microsoft.com/en-us/library/ms167274.aspx
For your Custom Data Extension you will need to call your login method for your CSLA Business Objects (passing username and password, perhaps as a parameter... You should setup SSL on Reporting Services). This method call is in the connection class "void IDbConnection.Open()". You call your logout here: "void IDbConnection.Close()".
You would get a CSLA Buisness Object List in this method "internal DataReader(string cmdText)" within the DataReader Class. Also you would read each record here: bool IDataReader.Read(). You need to get the name of the field here "string IDataReader.GetName". Here is where you get the datatype "System.Type IDataReader.GetFieldType(int fieldIndex)"... Returning "System.Type.GetType("System.<whatever the datatype is>")"; "object IDataReader.GetValue(int fieldIndex)" is where the report gets its actual values.
The rest of the classes in the Microsoft example can be left alone.
Of course whenever you try to do anything with SQL Reporting Services you will end up sending inordinate amounts of time banging your head. Don't say we didn't warn you! There are very few things you can to debug and you will just have to guess. But once you get everything in place the benefits do outweigh the pains of setup.GlennMiller,
Thank you for the information. We have completed a full course for SSRS few weeks ago, and I was wondering how I could reuse our CSLA .NET BO with SSRS Reports. The course instructor was unable to answer this question for me. My basic question was how to bind SSRS Report to a DataSet or BO Datasource ?
I have developed a BO based on CSLA .NET, and it connects to SQL Server, MS Access & Adabas to retrieve Staff Information in a list format.
I was wondering how I could reuse this logic to develop reports using SQL Server Reports.
I will try the approach you referred to.
If you have any useful updated, I would appreciate letting me know.
Tarek.
ajj3085,
Thank you for the info.
There is one small issue which is confusing me a little bit.
I found another nice article:
http://msdn.microsoft.com/en-us/library/ms251692(VS.80).aspx
By checking this article, it does not tell you to do any kind of inheritance from SSRS Interfaces. It looks like it is much simpler than I expected, since the article referenced in this thread ask you to implement several Interfaces which looks a bit complex.
Do you have any comment on this ?
Thank you.
Tarek.
I did some more research, and now I have better understanding.
It looks like .rdlc are client side reports, and much easier to work with. I was actually referring to .rdl Server Based SSRS Reports, which I think it is the proper way to go. During my experience, client-side have always been problematic. So, I will not spend time on it.
With .rdl, it looks like if you want to implement a middle tier using a BO to retrieve your data, which is the professional way of doing the work (to avoid rewriting and redoing the work, and to utilize the work you have done before) in order to do that, you have to pay some dues, ie, you have to implement some minimum number of Interfaces of the SSRS Data Extensions.
Well, I need to spend some time in that. I will do some effort, and try to post back the results.
Tarek.
Copyright (c) Marimer LLC