Some people would argue that preparing business reports is not an innovative area to be in. But in my experience reporting is the area where an individual developer can make a big difference, with relatively small effort. At best, report development is extremely productive, due to two reasons. First, reports are a low hanging fruit. Existing reports are in bad shape in virtually every organization that has no access to a professional database/DW/BI team. Second, it is surprisingly fast to develop for a good reporting system like the SQL Server Reporting Services (SSRS).
But if you are an application developer, SSRS report server is not your choice for operative reporting. It would add another system to administer, another dependency, something that would ultimately be a liability if your business is not to provide infrastucture services. You want to embed reports to your application and minimize any administrative burden. But there are bad news. From the tooling perspective, embedded reporting sucks big time. If you are used to authoring SSRS-style server side reports, then creating, debugging and deploying embedded reports is pain. Your productivity will be abysmal compared to SSRS. You go through this pain in order to get rid of the server dependency and to pass parameters conveniently from the application to the report. In the end, you should have your reports nicely packaged in a deployable dll and your end users shouldn't have to input parameters more than once. These are about the only reasons you should ever consider embedded reporting. Don't do it if you can avoid it!
I have played around with Telerik Reporting in two projects, both times creating a handful of embedded reports for particular customer needs. I also have used DevExpress XtraReports, but not enough to say anything about it yet. So far, I haven't had a chance to develop reports with the long-time market leader Crystal Reports or another well-known solution ActiveReports. With SSRS I have developed report server reports since 2006 but I've never used the Report Viewer control in embedded, or local, mode.
Welcome to the Reporting Country
Reporting is all about compromizing development speed, flexibility and looks. Rapid development is supported by GUIs, 4GL tools (code generators) and DSLs (domain specific languages). A version of Visual Studio shipped with SQL Server, Business Intelligence Development Studio (BIDS), is a prime example of this approach. Reports created with BIDS GUI are actually stored in a special purpose Report Definition Language (RDL), a textual XML format. BIDS has wizards for common tasks like creating crosstabs and charts, and of course for wiring the reports and parameterized queries together.
Now, relying completely on abstract tools is counterproductive if something goes wrong. Abstrations tend to leak on the edges, and you are almost certain to hit a wall sooner or later even with the most mundane business reports. An edge case is any requirement that is not demonstrated in the product documentation or demos, and is potentially difficult to implement. Sometimes you really need to bang your head in frustration, google like mad and read a ton of forums to move a small step forward.
This being said, high-level tools really shine in reporting if they are well designed and don't cause too many surprises. But you shouldn't be blinded and let your customers expect that any report can be finished "in a few hours".
Bottom up is the only way
There is a temptation to design your embedded reports top-down, from the general layout to the details. This may be fine at the design stage, but do not make the mistake of starting to develop from the main report and adding subreports and charts as details to the main report. If it does not work you'll have too many pieces to debug effectively. Instead divide and conquer your reports by using subreports and creating a new report file for each new report item. You can later move these to the main report, if using subreports isn't good enough.
It is surprisingly painless to move report elements and create duplicates of reports as templates once you get the first report working. This will violate the DRY principle, but I'll explain next why it is acceptable and inavoidable in reporting.
Hard-coding is good
Embedded reports are shipped within an application. Most application programmers would like these reports to be generic, so that every customer could use the same reports. Unfortunately, such generic reports are not very useful. Business applications are configured with settings and customized with code changes to fit the customer's business. Reporting is almost always dependent on these customer-specific settings. Say, a customer has a classification scheme that is stored somewhere in the application, preferably so that other customers can easily have their own scheme. These classifications are then shown in data entry forms as options in dropdownlists, listboxes etc. Now, from a the information system's point of view, all these separate categories are the similar, but from a business point of view the same categories make all the difference.
Custom categories are always used as report parameters.
You may try to avoid hard-coding these attribute values in your reports, usually with extra complexity. A common example is pivoting, i.e. turning your attribute values to column headers for calculating aggregates. Usually you need pivoted data to source crosstabs and charts like stacked bars. However, T-SQL PIVOT statement uses a fixed column list, and you need to use dynamic SQL to dynamically pivot your attribute values as columns, which adds complexity. But many times generalization is a disservice to the users who may have to pick 'self-evident' values as parameters in your generic report. Well-defined reports with minimal number of mandatory user parameters are usually the most popular ones.
Then there is the problem of having the whole report depend on particular category values. Let's say a classification represents the role of a person in a project. The roles could be named like 'manager', 'salesman', 'specialist' and 'administrative', but the exact classification is fundamentally a customer's decision. What if your customer wants to report different facts for each role? Hours for the specialist, money for the salesman and number of projects for the administrator. If the only difference between roles is semantic, something that is encoded only in the role's label itself, you cannot really do a generic report.
It is also very hard to get your reports look good if you don't design with specific set of attribute values in mind. Actually, the most generic reports would probably look a lot like an OLAP browser. If you already have one, why bother wasting your time developing a similar tool that is going to be worse anyway?
Posts
0 comments:
Post a Comment