Reporting
Posted: Mon Mar 29, 2010 8:06 pm
As those at the 2010 JSP conference would be aware, we are putting our efforts into supporting Microsoft's Reporting Services.
As a clarification, we are actually embracing the RDL (Report Definition Language) as the base for our reporting.
RDL is not a format, it is a standard. It is a standard introduced by Microsoft with the goal of : "promoting the interoperability of commercial reporting products by defining a common schema that allows the interchange of report definitions."
There are currently a handful of products / technologies supporting this format.
As someone who has been in this industry for quite a while (17 years), this looks like a Very Good Thing (TM) to me. It does not beholden any one to Microsoft's reporting services. It can be used without it completely. It's just a standard for defining the structure of a report.
A very powerful feature of this is that it is XML based. This means your own (or somebody's) XML namespaces can be included in the XML definition of a report.
For those not familiar with XML or namespaces in XML, what this means is the base XML spec can be extended with any namespace that is appropriate. The most obvious example is Visual Studio.
Hold onto your hats, because we're about to get technical!
Open an RDL file (built using the Microsoft Report Builder) and examine it's contents using an XML editor. You'll see the namespace "http://schemas.microsoft.com/sqlserver/reporting/2009/01/reportdefinition" or something similar. This is the namespace for the design of structure of the report. This is designer agnostic.
If you build a report using something like visual studio 2005 / 2008 / 2010 then you'll see an additional namespace - "xmlns:rd="http://schemas.microsoft.com/SQLServer/reporting/reportdesigner"
Any tags in the report using the namespace "rd" are isolated to the VS 20xx designer.
Likewise, company "xyz" can have a report with their own namespace, and it contain tags relevant only to their designer / report renderer.
The power here is all reports based on the RDL spec not only have a common standard base, but you can add your own application / domain specific namespace relevant to your needs.
An example (following from my previous hint) is the Visual Studio designer. It adds a namespace to reports it creates. Reports created with this tool (visual studio) and parsed only with the namespace "http://schemas.microsoft.com/sqlserver/reporting/2009/01/reportdefinition" see only RDL specific information. Visual Studio, however, looks ALSO for tags within the "xmlns:rd="http://schemas.microsoft.com/SQLServer/reporting/reportdesigner"namespace. Thus allowing visual studio to extend the functionality and provide things like previews because it wires up the data sources in the report automatically to project datasources.
If this isn't immediately clear - I apologise - but it it a complex topic. Anyone who has played with RDL and a document extending this schema will know exactly what I'm rambling about.
Anyway, back to the important stuff.
We've recognised the significant importance of having an industry standard schema that is extensible. We are going to embrace this.
As part of our research, we've come across a third party tool called Data Dynamics Reporting which extends the RDL schema and provides what we've always used in the past : A user interface control that parses the report and provides a user interface to collect parameters.
It actually does a lot more than that, but the parsing of a report is something I just spent 3 days on just to get superficial parameter reporting working. By using this library /control I can complete the reporting "pillar" of version 7 in just a few more days rather than weeks or months (because it would be literally weeks or more likely months INITIALLY, to get this working - and then there is the constant changes to support!).
An added benefit is we can ship the report designer within the product. That is, users can build or edit reports without having to purchase product like Crystal. A further bonus is that it means we are isolated from changes to 3rd party products like Crystal - ie: our product ships with a designer that works - there is no issue of not being able to obtain the designer x years down the track and having the site being forced to upgrade, or Jiwa being forced to release a new version with a new reporting engine just because the old one is not being sold and is not supported by the current Jiwa release.
In summary, we are currently looking at :
1. Using Data Dynamics Reports for our reporting needs
2. This is based on Microsoft's RDL specification
3. The product will ship with a built-in report designer and editor
If there are any devils advocates out there, now is the time to state your case!
As a clarification, we are actually embracing the RDL (Report Definition Language) as the base for our reporting.
RDL is not a format, it is a standard. It is a standard introduced by Microsoft with the goal of : "promoting the interoperability of commercial reporting products by defining a common schema that allows the interchange of report definitions."
There are currently a handful of products / technologies supporting this format.
As someone who has been in this industry for quite a while (17 years), this looks like a Very Good Thing (TM) to me. It does not beholden any one to Microsoft's reporting services. It can be used without it completely. It's just a standard for defining the structure of a report.
A very powerful feature of this is that it is XML based. This means your own (or somebody's) XML namespaces can be included in the XML definition of a report.
For those not familiar with XML or namespaces in XML, what this means is the base XML spec can be extended with any namespace that is appropriate. The most obvious example is Visual Studio.
Hold onto your hats, because we're about to get technical!
Open an RDL file (built using the Microsoft Report Builder) and examine it's contents using an XML editor. You'll see the namespace "http://schemas.microsoft.com/sqlserver/reporting/2009/01/reportdefinition" or something similar. This is the namespace for the design of structure of the report. This is designer agnostic.
If you build a report using something like visual studio 2005 / 2008 / 2010 then you'll see an additional namespace - "xmlns:rd="http://schemas.microsoft.com/SQLServer/reporting/reportdesigner"
Any tags in the report using the namespace "rd" are isolated to the VS 20xx designer.
Likewise, company "xyz" can have a report with their own namespace, and it contain tags relevant only to their designer / report renderer.
The power here is all reports based on the RDL spec not only have a common standard base, but you can add your own application / domain specific namespace relevant to your needs.
An example (following from my previous hint) is the Visual Studio designer. It adds a namespace to reports it creates. Reports created with this tool (visual studio) and parsed only with the namespace "http://schemas.microsoft.com/sqlserver/reporting/2009/01/reportdefinition" see only RDL specific information. Visual Studio, however, looks ALSO for tags within the "xmlns:rd="http://schemas.microsoft.com/SQLServer/reporting/reportdesigner"namespace. Thus allowing visual studio to extend the functionality and provide things like previews because it wires up the data sources in the report automatically to project datasources.
If this isn't immediately clear - I apologise - but it it a complex topic. Anyone who has played with RDL and a document extending this schema will know exactly what I'm rambling about.
Anyway, back to the important stuff.
We've recognised the significant importance of having an industry standard schema that is extensible. We are going to embrace this.
As part of our research, we've come across a third party tool called Data Dynamics Reporting which extends the RDL schema and provides what we've always used in the past : A user interface control that parses the report and provides a user interface to collect parameters.
It actually does a lot more than that, but the parsing of a report is something I just spent 3 days on just to get superficial parameter reporting working. By using this library /control I can complete the reporting "pillar" of version 7 in just a few more days rather than weeks or months (because it would be literally weeks or more likely months INITIALLY, to get this working - and then there is the constant changes to support!).
An added benefit is we can ship the report designer within the product. That is, users can build or edit reports without having to purchase product like Crystal. A further bonus is that it means we are isolated from changes to 3rd party products like Crystal - ie: our product ships with a designer that works - there is no issue of not being able to obtain the designer x years down the track and having the site being forced to upgrade, or Jiwa being forced to release a new version with a new reporting engine just because the old one is not being sold and is not supported by the current Jiwa release.
In summary, we are currently looking at :
1. Using Data Dynamics Reports for our reporting needs
2. This is based on Microsoft's RDL specification
3. The product will ship with a built-in report designer and editor
If there are any devils advocates out there, now is the time to state your case!