Friday, September 25, 2009

Embedded Reporting with Chart Controls

I've previously written about embedded reporting in general and looked at Telerik Reporting in more detail. But one subject wasn't touched on these posts, that is, creating operative reports without a reporting engine. Reporting engines provide a lot of features, sure, but you don't always need these features. If the requirement is to embed charts directly to your web application's views, a heavy reporting engine is just getting in your way. Think for example the Google Finance Flash chart pictured below, which for all practical purposes represents the gold standard of interactive time-series plotting:



Would you like if that plot was rendered with an SSRS-style engine, with 'generating report' animation spinning between reloads. Neither would I. Using common report elements like chart controls directly in your web app makes operative reports more responsive and the overall experience more 'webby'. But you won't get a Google Finance chart experience with the current 3rd party chart controls. The high end seems to be more like the Google Analytics -style plot with data point highlighting, which is nice too.

There are two approaches to web reporting: client-side RIA controls and server-side web controls. The distinction between the two is increasingly difficult to define technically, and I won't go into it now. Let's just say that the developer experience is different enough when using a jQuery plugin compared to a ASP.NET AJAX control that you are inclined to contrast and compare the pros and cons of both.

The charts that I've been using as a an exercise are taken from a Campaing Monitor email tracking report, which itself is a shameless visual copy of Google Analytics reports. Kudos for both! There are two charts in this report: a time-series plot with data point highlighting and a pie chart with a legend.













Now, let's try different tools to imitate this report


jQuery Chart Plugins
Javascript source code is available to all users, which makes open source a natural model for javascript-based tools. But it also means that feature-rich and well-supported tools don't just drop out of the sky, they will evolve gradually. The state of the art today is that free jQuery plugins don't either have the features or the quality to substitute a commercial chart control suite. But they are useful enough for many purposes and are simple and fun to play with. They probably also represent the future of embedded reporting. Sooner or later, one such plugin is going have enough lift to really take off. This is simply because jQuery plugins are platform-independent and consequently have appeal to an enormous plugin user and plugin developer bases. But if you are interested in commecial-quality javascript charts today, you should take a look at Emprise Javascript Charts

Technology
The jQuery plugins I tried generally utilize the HTML5 canvas element. IE does not support canvas yet, but Google's ExplorerCanvas does a decent job of emulating its functionality.

Javascript basically has two alternative methods of data access. The most straightforward method is to print data directly to the response, usually as a JSON-formatted value to a javascript variable, or as an HTML table accessible via DOM. jQuery Visualize plugin has taken the HTML table approach while others rely on JSON. But scraping data out of tables is a handy trick you can use with all javascript charting tools. The other method is to remotely load data with XHR or using cross-domain JSON.

Whatever means the client uses in reading the data, it is ultimately generated in a server somewhere. From the server-side view, printing data directly to a response can be easier than serving it through an url, especially if the data is not meant to be public. For example, I get DotNetNuke portal's page-level security for free if I print data.

Developer experience
Aside from technical capabilities, I'm especially interested in the general developer experience. The key question is: Is it simple and reliable enough for your boss? Can you recommend this tool to someone who does not have much time but who is tightly involved with customers and would like to use this first-hand information do reports without delegating them to others?

For jQuery plugins in general, I would say that if your boss has done client-side web development and knows how to use firebug, then jQuery plugins are safe. It is best to set up the environment beforehand, checking that jQuery version and plugin references are correct, and seeing that data access is working. Server-side work involves querying the data and converting it to proper format. As mentioned before, this is not necessarily AJAX, if you just write to the response page. One thing to remember with time values is that javascript requires you to convert .NET ticks to Unix/Javascript ones. Not necessarily something your boss would like learn the hard way.

The best thing in developing with jQuery plugins is the rapid development cycle. 'Installing' and testing multiple plugins in a single page is fast and fun. It took about half a day to evaluate all the plugins in this review. I have grown up to expect increased levels of frustration when dealing with new ASP.NET controls, and finding less frustration in javascript development was a nice surprise. Charting is a good fit for javascript because codebase for a single chart shouldn't grow too big and hairy.

Oh, and one more thing before going to the plugins. If you are interested in Javascript charting, go check Steve Reynolds's reviews:


flot
Flot produces nice looking lines, filled ares and columns, but no pie charts so far. The samples are great, showcasing such features as zooming with overview and colored weekends in time-series plots. Interacting with data and point highlighting with tooltips are supported too. Values for undefined parameters like axis ranges are well-thought.


In my opinion, flot is the best jQuery plugin for the chart types it supports. Solid web development skills are required to use flot, and you shouldn't be afraid to learn from real-world examples.

jqPlot
jqPlot looks very polished for an open source project and has nice features like data point highlighting. But the good first impression fades somewhat when you try it with other browsers than Firefox.

Here's a jqPlot pie chart in FF 3.5, showing email tracking data. The labels are in Finnish and mean "Opened" and "Not opened".


In Chrome, the same chart looks like this:

As you can see, the colors are inverted. If you mistakenly input data as text without parseInt(), FF is ok but Chrome will render the shares wrong:

IE8 with excanvas works like FF, but again, if you input text instead of numbers, the percentage shares start to look interesting, even more so than in Chrome:


Even with these inconsistencies, jqPlot pie charts would be my choice for a jQuery Google Analytics replica.

jgCharts
jgCharts uses the Google Chart API but does not support all features from it. You can't color a pie chart with jgCharts, for example. Yet, most of the shortcomings originate from the Google Chart API. First, jgCharts do not impress visually compared to flot or jqPlot, which is not surprising since the charts are intended to be loaded as ordinary HTML image elements. This means that the API is the only way to customize the charts as CSS and javascript are out of the question. Animations and interactions like drill-down urls are naturally missing too.



Others
jQuery Sparklines didn't impress visually and I couldn't do even basic customizations to a pie chart. There is a reason for that. A sparkline is a type of information graphic characterized by its small size and data density. This is probably the optimal use for Google Chart API too.

Visualize demo charts look nice, but the feature set is quite poor. Interactive features and animations are not supported, and there are only a handful of parameters. All data is scraped from a HTML table, which means that you'll have to explicitly hide the tables you don't want to show. With other controls, the problem is exactly the opposite: you need to do extra work to show data also in a HTML table. But every jQuery plugin can easily scrape data manually from a table once it is there, which is much more flexible than creating tables in the exact format that a plugin needs. For example, in the previous jqPlot and jgCharts pie charts data was scraped from an ASP.NET datagrid. Visualize couldn't use that table directly. In the picture below there is a HTML table in the upper left corner and a corresponding visualize chart with default settings, as seen in Firefox and Chrome:

With IE8, the outcome was not so good, but at least those black spots in percentage shares were gone:



Flash
Flash is the technology of choice for professional web charts, as witnessed by Google Finance and Analytics. Silverlight certainly has potential too, but because of the relatively small install base I decided to drop Silverlight Toolkit from this review.

Technology
The worst part of Flash is the Flash development itself. ActionScript is not exactly known as the language of choice in software development. Developing Flash also requires Adobe Flash Professional or Flex. But if you don't intend to develop Flash chart controls yourself, none of this really matters. Right now and in the near future, Flash chart controls are the most sophisticated ones around, both in their visual outlook and in the features they support. But you should expect Javascript libraries to close the gap pretty soon, at least from an end user's point of view.

Data access methods in Flash are a superset of the methods available for Javascript. You can use Javascript to feed Flash objects and the Flash charting tools provide good Javascript APIs. In addition, you can use the Flash object's parameters for data access. The urls defined in the Flash object are subject to different rules than the urls inside Javascript. Authorized cross-domain data loading is available and is controlled with policy files. Second, some but not all Flash charts support printing data directly to a swf parameter.

Developer experience
If you can avoid Javascript, Flash charting is extremely simple. Well, it is just HTML objects then. Any developer should be able to use these kind of charts. If you cannot avoid Javascript, the experience is similar to jQuery development.


FusionCharts Free
FusionCharts Free (FCF) is a free older version of the popular FusionCharts, the market leader in Flash charting. First time I took notice of FusionCharts when they started to show up in popular web applications, especially RescueTime uses them heavily. Creating the example email tracking charts was no problem in FCF:


FCF has all the polish of a commercial product:
  • example charts that look good
  • compelling feature set, but these features are yet very easy to use
  • high-quality documentation and support forums.
  • support for multiple server-side technologies
FCF's .NET interface is extremely simple. You replace a literal with a Flash object:


litFC.Text = FusionCharts.RenderChartHTML("/FusionCharts/FCF_Line.swf", strUrl, strXML, chartID, width, height, False);


XML data and settings are provided via an url, or are embedded direcly to a HTML Flash object. Great thing is that .NET interface does not try to act as a wrapper to XML, you generate the xml yourself and pass it as a strXml parameter to the above FusionCharts.RenderChartHTML function. FCF reads xml settings liberally and does not mind if you use settings from different chart types in one setting xml.

Each FCF chart type has a separate swf file, which is a minor complication because you need to know multiple pathnames in using the API. I wrote a helper enumeration to get correct filenames using IntelliSense.

The only problem with FCF is that it is a legacy product. The actively developed product is Fusion Charts 3, and the differences between the two are substantial. Good thing is that you have an upgrade path, but don't expect any new features in the free version.

FCF is the easiest charting tool to work with, and even nontechnical people should be able to draft chart requirements with it.


Open Flash Chart
Open Flash Chart (OFC) is a popular open-source alternative to FusionCharts. OFC sample charts look good, they are definitely the best looking ones from the charts I've tested here. But this does not help too much if you won't get your charts to look good. And unfortunately OFC is not too easy to work with.


OFC documentation is PHP-centric. For other environments, there are support forums but not much more. To use .NET you can compile the shipped .NET library or use an alternative one.

Unlike FCF, OFC has only flash binary, open-flash-chart.swf. Chart type is defined in the JSON-formatted data file. Compared to jQuery plugins, this JSON it is quite complicated to create manually. Good thing is that there are server-side libraries to create OFC charts that handle the conversion to JSON. But you still need to use javascript to pass the data to the chart. This is not as simple as passing XML data directly to the flash object parameters, as in FCF. You need Firebug to debug things, tolerate Firebug/Firefox crashes etc.

The default .NET API acts as a JSON wrapper class and is not nearly as simple as in FCF. The bad thing is that this abstraction leaks, you can't control every setting in JSON with the .NET API, or at least you have to spend a lot of time finding out how to achieve this.

One particular annoyance was that OFC dates use PHP mktime() ticks, that are otherwise the same as Unix/Javascript ticks but are counted in seconds instead of milliseconds.

My first impression was that OFC is hard. I wouldn't let my boss use it.

ASP.NET
It should be noted that the RIA controls I tested are free or open source but the ASP.NET chart controls are commercial products, usually shipped inside a larger toolkit. The controls are well productized and strive for high user productivity while offering the maximum feature set. This is not easy to achieve, and therefore it is important to support the user when the inevitable troubles arise. Money does not buy you a solution to every business charting case, but it does buy you many well-supported scenarios.

Technology
ASP.NET charts are technically using the same client-side web platform as the jQuery charts. In practice, there are probably quite a few constraints in developing a generic .NET chart control that do not exist in pure Javascript development. I wouldn't expect ASP.NET charts to visually match the best Javascript ones. But at least it would be nice to have some interactive features and animations, which are mostly missing now.

Rich data access is the strongest point of ASP.NET controls. You can use native ADO.NET data structures directly instead of serializing to JSON or XML. Another .NET advantage is that the chart controls are usually built as generic all-in-one charting solution for both ASP.NET and WinForms. The same chart control is also used in the vendor's reporting solution which can be useful.

Developer experience
Visual Studio IDE and the .NET tooling support in general are great, sure, but the focus here is on the usability of chart controls. Commercial server-side chart controls typically have lots of features and the learning curve can be steep. In the best case you have decent Visual Studio design-time support, which is intended to work like WYSIWYG for UI programming. In practice this means property grids to make settings and some visual output on how these settings affect the chart. But if you can't get design-time support to work, you'll only see the IntelliSense code comments and external documentation while coding, and the final outcome is visible only in the browser.

Generally, getting an example chart up and running takes more effort in ASP.NET than with jQuery plugins or Flash charts, because you have to set up a IIS web application and prepare an aspx page, a code behind file and a web.config. Development and testing cycle is slowed down by the time it takes to compile the solution and reload the ASP.NET site. Reloading is particularly slow if you have lots of dlls in the /bin folder. But again, this same reload happens when using a Flash chart .NET API, or when doing server-side .NET data access with any front-end charting tool.

I don't like the ASP.NET heavy lifting needed to draw a few charts. But if your boss is an ASP.NET developer, and you provide the environment and a few samples, things should be ok.


XtraCharts
XtraCharts is a part of the DevXpress toolkit. Deployment requires 16mb of DLLs to be loaded in every application restart, only for charting. That's heavy and takes a few seconds in your dev machine.

Demos are nice, I liked the spline plot, but as you can see, the chart is a .png image, which prevents any cool animations or mouseover interactions inside the chart. Outside the chart image you can have tooltips as in the "Weather in London" chart.

For some reason, I couldn't get the Visual Studio designer support work in a DotNetNuke module project. The designer showed an error:




Probably some setting is wrong as I was developing in a Visual Basic project. Working manually with the code-behind file is fine with me, but the bad thing was that I already faced a problem after a few iterations of the pie chart. Below is the chart with labels but no legend:

Setting the legend visible caused the chart to disappear:

Issues like this arise in every complex control, but debugging them makes you appreciate the fast develop/test cycle of the client-side tools.


Telerik Charting
I have used Telerik RadChart previously with Telerik Reporting, and my perception was kind of lukewarm then. But I should have more perspective now.

First the good news. Designer support for Telerik Charting works pretty well, even though the property grid is hard to use when fine-tuning the chart. WYSIWYG works even in the data level: you can put data items in the aspx, and they show directly in the designer, as pictured below!

Having data in aspx also means that you need not to do anything in the code-behind to get a working report. But frankly, I don't find any use for data-in-aspx other than simple demos.

Compared to XtraCharts, some useful chart types are missing, or they don't look as good. For example, a line plot demo has labels but not visible data points. XtraChart demos are more complete, easier to navigate and better-looking than their Telerik counterparts, but the difference is not big. Both tools produce static image-based charts that support only image map interactivity, zooming support in Telerik line charts being an exception. It should be noted that Telerik also offers Silverlight charts that are on par with Flash with respect to pizzazz.

And then the bad news. I couldn't get the Telerik charts working at all in the browser. All that I got was an error message:
BC30560: 'ChartSeriesType' is ambiguous in the namespace 'Telerik.Charting'

Normally, I would debug for an undefined time to get some results. But this time I have to call it off. No more ASP.NET debugging today.

Final words
Programming is a profession of solving real-world problems with tools that are built to look great in demos. But you shouldn't blame the tool if you can't ever achieve the same results in the same time on your own, no matter how much you spend time debugging with the tool. This is the reality. But sometimes you do get positively surprised by a development tool that just works as promised. FusionCharts Free is such a product. The people who designed and implemented it five-to-ten years ago have done a hell of a job. Thank you!

I chose Fusion Charts Free for our company, and it is probable that we upgrade to the latest commercial version in the future. FCF has the looks, simplicity and support required for a business where charting is a nice-to-have but not a critical feature. A great thing is that FCF with inline dataXML data and no mandatory javascript is a fool-proof charting environment that is safe for your boss too.

Open Flash Charts was the runner-up, entirely because of its looks, but it is too complicated for occasional use. If I was doing serious charting I would compare OFC more carefully with the commercial version of Fusion Charts.

jQuery plugins are promising, but so far they are fit for only lightweight charting tasks, mostly because they lack features. Javascript is still not for everyone, but for javascript-savvy programmers the developer experience is extremely productive, until you hit any edge cases.

It makes sense to use .NET chart controls if you can piggyback some of the work you have done with the other controls in Telerik or DevXpress toolkits. Or if you are doing WinForms charts too. But as standalone web charting tool, RIA charts are better.

-mika-

Friday, September 11, 2009

Microsoft Antivirus, Antitrust and the Public Good

Microsoft Security Essentials has been officially released.

This is good news for all Windows users and especially for the tech people who have gotten used to wrestling with 3rd party security solutions. If a friend calls me and says there is something wrong with his/her laptop, the first thing I presume is that security tools are causing trouble. The usual fix has been to uninstall some old brand-name security solution and replace it with Windows Firewall, Windows Defender and the free and fast Avira Antivir. From now on, I'd use Microsoft Security Essentials instead.

I haven't used an antivirus in my main laptop since I upgraded to 64bit Vista. But I do use antivirus in machines that I don't attend to, like my home server PC and the servers at work. The reason for not using real-time security software is performance. I need it. I'm willing to put effort in hardware upgrades like an SSD drive with clean-installeded Windows 7 to improve developer tool performance, but I'm not going to waste this investment by installing a new resource hog. Instead, I protect the machine with hygiene, by not installing anything unnecessary and keeping the updates fresh. If something goes wrong and an attacker gets through a vulnerability, I have a minimal setup backed up and recoverable fast. So far, I haven't needed it, because natural clean-ups like getting a new machine or installing a clean OS are frequent enough to keep the machine healthy. But I do run an off-line security scanners like Malicious Software Removal tool and ClamWin once a month or so.

For basic users and risk-taking power users, real-time antivirus is good. But even then you don't want to deal with the security software industry. It is just too hard to evaluate the net value of their offerings. You cannot be rational with security software unless you have a reliable cost estimate on being unprotected, and know the costs and benefits of a particular security tool. But this kind of analysis is hard, as the results depend on the value of your time and data in addition to the technical quality of a security tool.

The reason why Microsoft has not included antivirus in Windows already in the late nineties must have something to do with the antitrust regulators. Now, with the popularity of free antivirus rising, Microsoft is more safe to launch this offering. It will probably never be a part of Windows, which is bad for the overall security climate. On the other hand, this will probably be in the best interest of the consumer by keeping some free or commercial alternatives available. Historically, competition has been about the only thing that drives software quality improvements. As a warning example, it is good to keep in mind the internet dark age, 2001-2004, when IE6 didn't have a serious competitor.

Wrapping things up, unless Security Essentials turns out to be a real turkey, I'd recommend the following policies:
  • For large enterprises, it makes sense to use centrally managed antivirus. But give developers an option to uninstall it in their machines, please!
  • For nontechnical home users and small business users, who don't need most of the performance most of the time, real-time antivirus like Security Essentials is good. But you need to do backups, always.
  • For unattended machines, antivirus is a must but you can have a scheduled virus scanner instead of real-time scanning. Free antivirus for Windows Servers is rare, I have used ClamWin for these. Managing ClamWin is tricky if machines can't connect to the update site, like when outbound http requests are blocked by a firewall.
  • For performance-intensive workstations, minimize the amount of unnecessary software, including security software. You are ultimately responsible for the security, not some black-box application.

-mika-

Sunday, September 6, 2009

Experiences with Telerik Reporting

This is not going to be a too nice and well-rounded review so I'd better start with some background.

I work in a software company that is specialized in event management software. An 'event' here means the same as a 'happening', something that people are going to attend to. I should write about this more later, but briefly, event management software is like Facebook's event invititation feature for organizations. If you think it a while, there are a lot of organizations that do events for a living. Every educational institution is one. Second, inside every large organization there is a HR, marketing and/or public relations department whose one job is to manage events. And then there is the whole mass event industry.

With such diverse clientele it is expectable that the same software features are used to manage completely different data, and sometimes similar data is managed with different software features. Business processes* and the language used to describe them vary a lot. And because reporting is all about written expression, it is not surprising that one report does not fit all users. As I already explained in the last post, different labels on the same categories are often enough to justify a custom-tailored report.

In practice, we usually get an Excel report someone had previously produced manually, before they started to use our software, and from now on, they want this same report to be generated automatically. At the same time, my boss wants a high-level reporting/charting tool. Something that outputs nice charts from a function that takes all the necessary parameters. These reports should be suitable to all customers, with some small customizations passed as parameters.

From these requirements a basic solution is to have few reasonably generic default reports and a bunch of custom reports for ad-hoc situations. The interface to open a report from the application should be stable. You don't want to modify the report calling interface for each new report, because this would be maintenance nightmare. This is because applications and reports are usually developed separately, and you can't trust that the application has always access to the the latest report definitions.

As I started to work out reports, our first choice of reporting tool was Telerik Reporting, just because we had a licence. Compared to SSRS 2005, Telerik Reporting is almost on par with features, at least starting from version Q1 2009. Other option I had was to use Microsoft ReportViewer in local mode, and later on I have started to test DevExpress XtraReports. Comments on these will follow later but the rest of this post is specific to Telerik Reporting, version Q2 2009.

Telerik Reporting Basics
In order to use any reporting tool effectively, you need to have a basic undertanding of the report lifecycle. Report definitions are designed, definitions and data are processed, and finally the resulting report is rendered. You will be confused If you don't realize when your code runs in the report lifecycle. For example, creating a report object means creating an instance of a report definition. All parameters passed to a constructor affect only this definition instance, not the runtime processing.

Familiarity with the lifecycle is needed most often when wiring user parameters to queries:
  • default values of user parameters are stored in the definition. If the report is processed immediately after it is opened, these default values will become selected values
  • selected values of user parameters are only known at the runtime processing
Runtime processing behavior is event driven, with events like NeedDataSource to read user parameters, run a query and bind the results to a report element.

Telerik reports definitions are classes inheriting the Report base class. Reports are opened by creating a new report object and assigning it to the report viewer.
Report report = new MyReport()
this.ReportViewer1.Report = report
Because each report definition is a class, you need to use reflection to avoid messing with the interface between application and reporting. The interface I chose was to pass the report class name in the querystring to a report laucher page. This way reports can be opened from the application by redirecting to an url:

/reportlauncher.aspx?type=typename

Simple report parameters could also be added to the url this way.

Parameters
Much of the generalization effort in reporting involves loading available user parameter values dynamically. Available values, usually business categories, would be shown in dropdownlists in the user parameter area. Their effect is to slice the report by parameter value. Telerik reporting supports both single and multivalue parameters, which is good. To populate parameter lists from a datasource, you use the AvailableValues property of the report definition. I had some trouble in getting my datasource right, I couldn't use a dictionary, but arrays and datatables worked fine. Arrays don't have column names like datatables, but the interface requires you to use "Item" as a ValueMember name. This was helpfully instructed in an error message.

Report parameters don't support localization which is a serious shortcoming with no workaround. This is a problem especially with datetime parameters because users are accustomed to certain date formats. Here in Finland the format dd.MM.yyyy is expected but the only supported format in Telerik Reporting is MM/dd/yyyy.

Complex Charts

If you thought that Excel charts are hard to use, think again. Excel team has probably put multiple man-years of work to optimize the usability of charting. On the other hand, if you try to put every setting of a chart into a Visual Studio property grid, you'll get what Telerik charting looks like. This is not a complaint, it is a fact.

Picture on the right is a chart property grid with only a few items expanded. Navigating the grid and finding interdependencies between settings gets hard pretty fast, and it is a trial and error process.

Designing a chart layoyt so that it looks good and clear with as many datasets as possible is a whole topic in itself, a data visualization problem. Thit being said I found that labels and legends are hard to position sensibly. I had a lot of trouble with ugly overlapping labels. Sometimes it is easier to use ordinary textboxes instead of chart labels. One problem I solved this way was positioning the X-axis header and item labels in a bar chart so that they don't overlap each other.



The Evil Wizard

Don't Use Wizard Code You Don't Understand (The Pragmatic Programmer, Tip 50)

Telerik report wizard instructs using the Microsoft DataSet Generator for your queries. Forget it. MSDataSetGenerator is an evil wizard. Once you have generated the code with it, good luck doing any significant changes!

One thing that bugged me was that the wizard-generated adapter has two methods, Fill and GetData with similar signatures. At first, I didn't find any good use for GetData. You would think that once you fill a dataset you can use a reference to it directly. But it turned out that the reference works only for the first time you fill a dataset, but on on subsequent runs.

The problem was that the default user parameter values didn't return any data and I got the dreaded message There is no or empty series, which means that your dataset is empty. I tried to change user parameters and reload the report with no effect. Only after changing Fill to GetData did the dataset refresh.

On top of this all, the dataset wizard/Query Builder does not even work well if you have standard SQL parameters in your query. I don't think you should use it for anything else than playing around.

N-pages and other layout problems
Why is there N pages of duplicates in the report? The reason is that you have defined a datasource for the entire report, with multiple result rows, and the detail section is processed for each result row separately. Take the report datasource away.

Another thing is that you must be careful with the page width. If your report is too wide, blank pages will be rendered. I remember similar issues with SSRS and was expecting this behavior. Page headers are especially tricky, for some reason having a page header generates easily an empty second page in an otherwise one-page report.

Usually blank areas and extra pages have something to do with positioning, but there is at least one exception. If textboxes are invisible and no design mode text shows in the preview, it is probably a localization issue. Revert language to default and remove extra .resx files if you can't get anything else to work.

The latest layout problem that I had was that the report designer canvas didn't show textbox elements that clearly were in the designer file and were visible in the web preview. These elements were outliers that were far separated from others. I had to remove them from the designer file.

Debugging?
Debugging reports is tricky. You cannot debug report code in Visual Studio preview mode. You need to attach the debugger to a windows application or a web application. Now, try your best to make these applications similar, so that they use the same report constructors and all. This is more difficult than it sounds. I have a generic windows test application copied from Telerik samples, but with most of my web applications I need to pass more parameters to the report. So the test app use different constructors than the production app. More than once I've had the trouble that debugging in the windows app is different from debugging in the webapp.

Samples and Forums to the Rescue
God bless, Telerik has provided working examples that look nice, use most of the features and have source files available that actually work. The last thing is important, since if you can't get the examples work in Visual Studio, there is not much point in taking example from them.

Another essential lifeline is to visit the forums. I have definitely needed the forums in every new report task, and usually they have provided an aswer.

Deploying and upgrading
Reports are developed as class library projects in Visual Studio. They will compile to a dll that can be deployed to the application's bin folder. For example, I have copied my report dll directly to DotNetNuke site's /bin.

Upgrading report projects from one Telerik version to other in Visual Studio has never caused any trouble. Reports compile as before. But upgrading requires also that you redeploy both the reports and the Telerik dlls. You must remember to change the Telerik.ReportViewer version number in the application's configuration file, otherwise your reports won't run. This will cause surprises if you have multiple sites and web.config files to maintain.

In Visual Studio, the only small problem I've had was that Telerik ReportViewer didn't show up in the ASP.NET Toolbox in the first installation.


Final Words, Déjà Vu
So, I finished the reports and clients have been happy so far, which is good. But the biggest problem with Telerik Reporting is that I had to do the exact same hoops described here about four months ago. And promptly forgot them afterwards. Wish I had written this blog entry back then. I probably used the same amount of time debugging the same issues now as I did then. This is a real killer, even if its largely my fault for not taking good notes. The knowlegde required to get your reports both work and look good is just very specific. But once you get the first report right, it is straightforward to add similar reports.

Now, my boss wanted a report suite that is easy for him to extend. And he is a CEO/salesman/developer who does not have time to do research. I don't think he has the patience needed to use Telerik Reporting.

Finally, I'd want to point out that I don't dismiss reporting as a job, quite the contrary. But I'm getting more confident that reporting is too important to leave to operational application developers. First, normalized database schemas are not optimal for reporting. Dimensional data models would do a lot to make reporting fun and productive. Second, data quality is not a priority in most CRUD app projects. Schemas are bad, not all tables are even 1NF, policies with null values vary. And third, there are the problems with embedded reporting I have discussed here and in the previous post.

I would recommend separating reporting from applications at all levels:
  • In the IT department, source reports from a data warehouse, not from operational databases.
  • As an application developer, make report addresses configurable in your operational application, so that users can choose a report server without having to input parameters twice. Supply default reports for your application as SSRS templates, at least in addition to the embedded reports.

-mika-


* Business process is a term that used to imply how people in different organizational 'tribes' end up doing things in their own way. An evolution-based rationalization would be to say that the origins of business processes are quite random, something like out-of-the-hat management decisions. During the implementation the most harmful initiatives are weeded out, managers publicly (but hopefully not privately) forget their mistakes, and the surviving arrangements are what is left as a business process.