Crystal Reports.NET is a brand-new product that is only available with the Visual Studio .NET suite. It shares some common features with the retail version of Crystal Reports and was built on the Crystal Reports 8.x technology, but components of Crystal Reports.NET have been re-written using C# and are designed to take full advantage of the .NET Framework.
Unlike the standalone versions of Crystal Reports, Crystal Reports.NET is part of the Visual Studio .NET Integrated Development Environment (IDE). Using the integrated Report Designer, you can create or modify reports from within the Visual Studio .NET IDE. (If you have used the Report Design Component from previous versions of Crystal Reports, the concept will be familiar.)
Keen to make amends to developers who have felt slighted in the past, Crystal Reports.NET follows the Visual Studio .NET mantra of "any language, any time" and is not too picky about the language you use to write reporting applications. For all .NET languages the report designer remains the same, and the code used to control viewing reports and report engine calls will only vary slightly between languages, due to different syntax rules and conventions. For example, if you were binding a report to a Web Forms Viewer in VB.NET, the syntax would look something like this:
crystalReportViewer1.ReportSource = my_Report1
While, the same code can be ported to C#, with only one rather minor syntax change:
crystalReportViewer1.ReportSource = my_Report1;
Clearly, it is going to be a lot easier to switch between languages when required - this also means that the ease of use that Visual Basic developers enjoyed with previous versions of Crystal Reports can be used across all of the .NET languages.
Another difference is that the way that we integrate reports into both Windows and web applications has changed. In the past, Crystal Reports developers had a number of different integration methods they could choose from for Windows applications, such as an ActiveX control, Automation Server, or direct calls to the Crystal Reports Print Engine. For web applications, Crystal Reports shipped its own web component server and report viewers, allowing developers to integrate reporting into their applications.
While the report integration solution provided for Windows development seemed to make most developers happy, the web integration provided with Crystal Reports left something to be desired. There were inherent problems with configuration, scalability, and reliability, meaning that the Crystal Reports web development platform could not be used to create scalable enterprise applications.
With the introduction of Visual Studio .NET, is it now possible to bring both Windows and web development into the same framework. The Crystal Report Engine is now a COM+ object wrapped around an updated version of the Crystal Reports Print Engine you may have worked with in the past. The Report Engine can be used to customize features at run time and also takes care of report processing.
When working with Crystal Reports for Visual Studio .NET, you have a choice of either leaving the report on the local machine (and using that machine's resources to process and display the report results using the Windows Forms Viewer), publishing it to a web server (and using the Web Forms viewer) or publishing it as a Report Web Service - which can be consumed and viewed by either the Windows or Web Forms Viewer.
Each of these integration methods will be covered in its own chapter, starting with Chapter 3: Report Integration for Windows-Based Applications.
Integrating a report into a Windows application is as simple as dragging the Crystal Report Viewer from the toolbar onto a Windows Forms Viewer and binding the viewer to a report file. (You could also create a report using the integrated designer.) The Crystal Report Viewer shown opposite provides a feature-rich client for viewing reports and at design or run time you can customize the appearance and options of the viewer, pass parameters, set properties, and so on.
For web development, there is also a Web Forms Viewer that communicates with the Report Engine (either on the local machine or on a remote server) to display a report page in DHTML format. This allows you to quickly integrate reporting into your web applications - there are no runtime files required and the report processing can be performed on the server.
In addition to these enhancements, Crystal Decisions has also released Crystal Enterprise - a scalable, platform-independent report distribution, scheduling, and processing engine that can be used in conjunction with Crystal Reports and Crystal Reports.NET to provide the back-end "muscle" to create applications that can support hundreds of users for both real-time and scheduled reports with a clustered, multi-server architecture that can span Windows, Linux, and Unix platforms.
Reports that have been published to the Crystal Enterprise framework can be accessed directly from within Visual Studio .NET, as shown overleaf, and integrated into your application.
In addition to providing a scalable, multi-tier back end for reporting applications, Crystal Enterprise also has its own security layer (which can use Windows NT authentication, LDAP, etc.), internal structures (folders, objects, rights), and a scheduling engine and distribution capabilities that can be used to build complex reporting applications without have to reinvent a solutions architecture just for reporting.
For example, if you needed to create an application that generates a report every week in PDF format and sends it as an e-mail attachment to 10 different users, you could create that functionality within your own application or you could use the inherent scheduling and distribution capabilities within Crystal Enterprise to make a handful of API calls to do this for you.
Another key area where Crystal Enterprise earns its money is with the clustering technology and multiple-server architecture - imagine in our example from above, there are now 10 reports that go to a hundred different people each day with a copy of the report and a link back to where they can view and search the live report.
The clustering within Crystal Enterprise ensures that these jobs get run regardless of what servers are up or down, and the distributed architecture means that you can add multiple servers to share the processing workload, including servers tasked to specifically run scheduled reports and process on-demand requests.
While the cost of Crystal Enterprise may be off-putting to some developers, its integration with Crystal Reports.NET and distributed architecture (which is beyond the scope of this book) will ensure that you have the scalability you need when your reporting application that serves 10 suddenly needs to serve 10 thousand.
When we look at Crystal Reports.NET, one of the immediate differences between this version and previous incarnations of the product is the ability to create multi-tier reporting applications. In the past, most Windows applications used a two-tier approach with Crystal Reports, where reports ran on the local machine where the application was installed.
With the introduction of "Crystal Server" for version 4.0 of Crystal Reports, a first attempt was made at developing a client-server version of Crystal Reports; but it wasn't until 1994 when Seagate Software acquired Crystal Reports, and the corporate scheduling product "Ashwin" (which could be used to schedule programs processes, etc.) was introduced that multi-tier report applications became a reality.
The combination of the two products was first introduced in 1995 as "Crystal Info", and later changed name to "Seagate Info". Through the Seagate Info SDK, an additional processing tier was introduced to developers, with a server-based architecture that allowed reports to be run on a separate server and returned to the client.
While the Seagate Info SDK seemed like a good idea, developers were slow to adopt the technology and looked for other ways to create multi-tiered applications. With the introduction of Crystal Reports.NET, developers have found the wealth of tools the product provides, including Web Services, Enterprise integration, and so on, and are now adopting it. Reporting applications using Crystal Reports.NET will generally fall into one of the following categories:
Crystal Reports integrated with applications created in previous versions of Visual Basic were usually deployed as single-tier applications. In a single-tier application, a developer would use one of the various integration methods to integrate Crystal Reports within their application and would then distribute the report file and all of the Crystal Reports .dll and runtime files required to make the application work. When a report was run, it ran locally as a thick-client application, using the resources of the machine where the application was installed.
With Crystal Reports.NET, you can still create single-tier applications and distribute the runtime files required to run and view a report. Some of the limitations found in applications created with previous versions of Visual Studio tools will still apply, including the need to re-distribute the report file if any changes are required. A much better solution is to consider applications with two or more tiers.
Most web-applications created with Crystal Reports.NET are considered two-tier applications. In the first tier, shown overleaf, a web application makes a request for a report and the report is processed on the web server that hosts the application.
This architecture provides definite advantages over a single-tier app, including off-loading of the report processing and viewing to a server, and a "publish once" mentality for publishing a single copy of a report to a web server that can be accessed by multiple users. However, with this type of two-tier architecture, your application will be limited by the number of users that can physically connect to a single web server, and report processing will add a definite increase to this server's work load if used heavily for viewing reports.
Moving to an even better solution with an even thinner client...
A true three-tier reporting application, like the one shown below, can be (but doesn't have to be) created using XML Report Web Services (covered in Chapter 5), which are new for Visual Studio .NET. A Report Web Service is a Crystal Report that has been exposed as a Web Service to be used (or consumed) by an application. Applications can connect to a Report Web Service and the underlying report can be viewed either using the Web or Windows Report Viewer, providing all of the functionality (view, drill-down, export) found when integrating reports into a single or two-tier application, but with the report running on a server behind the scenes, resulting in the lightest client resources required for actually viewing a report.
In addition to being able to expose reports as Web Services for internal users, you can also publish Report Web Services to users external to your organization, providing a method for external users to access data held within your own data sources.
When working with applications that are to be deployed to large numbers of users, you will probably want to consider moving to a multi-tier architecture (which is just a generalization of the 3-tier concept), where components can be added as the application user base grows.
Crystal Enterprise is a web-based, stand-alone solution for secure report delivery and distribution that can be integrated with Crystal Reports.NET. From within the Visual Studio .NET environment, you have access to the reports stored in the Crystal Enterprise framework and a rich object model that exposes all of the Crystal Enterprise features and functionality (scheduling, security, e-mail distribution) for use in your own application.
Important
For more information on Crystal Enterprise, check out http://www.crystaldecisions.com/products/crystalenterprise
The Crystal Reports Designer, shown overleaf, can be used to create a report from scratch or you can use a number of experts (similar to wizards) to help you get started. The interface is similar to the retail versions of Crystal Reports, and shares enough similarity that existing report developers should have no problems making the transition to the .NET version. With that said, there are some specific options and features that are unique to this version.
To start, Crystal Reports.NET has extended support for a number of data sources, including ADO.NET, OLE DB (ADO), ODBC (RDO), Access/Excel files (DAO), Crystal Field Definition Files (from previous versions of Crystal Reports), and XML. When working with these data sources, Crystal Reports.NET can utilize either a "Pull" or "Push" mode of data retrieval.
To create a report that "pulls" the required data, you can create a report from a data source just as you normally would and let Crystal Reports handle writing the SQL statement, submitting the statement to the database, retrieving the records, formatting and displaying the records, and so on. This is the most common mode of integrating reports into applications and does not require any additional coding.
In "push" mode, a report can be created from a data source and used within your application, but it is the application itself that is handling the hard work of connecting to the database, populating an ADO.NET (or other) recordset and then "pushing" that recordset to the report. From that point, Crystal Reports will format and display the records it has received.
This method of integration requires more manual coding, but provides more control over the DataSet and report processing. Using the "push" mode to retrieve the data for your report means that you can use optimized SQL and stored procedures via ADO.NET to share database connections with other transactions that occur within your application, and so on.
When using the Crystal Reports.NET Designer, you'll notice that there are a number of features that are available in the retail versions of Crystal Reports, which are not supported here. A list of these features has been included below for your reference:
Geographic mapping is not supported in Crystal Reports for Visual Studio .NET. Map objects in Crystal Reports are provided through third-party technology provided by MapInfo and this has not yet been ported over to the .NET Report Designer. If you want to use existing reports that have maps with Crystal Reports for Visual Studio .NET, you can still do so - the map objects themselves will appear blank.
OLAP data sources and the grids that display OLAP information within a report are also not supported. If you are using an existing report that displays an OLAP grid, this area will be shown as a blank.
Crystal Dictionaries, Crystal Queries and Seagate Info Views are not supported. If you need to use an existing report that is based on any of these file formats, you would need to re-create the report directly from the database or data source itself.
Note
Up until now we have only looked at previous versions of Crystal Reports. In August 2002, Crystal Decisions released Crystal Reports 9.0, which shares the same file format as Crystal Reports in .NET. It includes a stand-alone report designer (which does not require Visual Studio), as well as an updated report designer for use within the Visual Studio .NET environment, so you could have someone else create reports for your application without having to train them on how to use Visual Studio .NET.
Also included are new components for use with .NET - including increased data access, productivity features, and a mobile viewer with associated tools that works with the .NET Mobile Internet Toolkit. For more information on Crystal Reports 9, visit http://www.crystaldecisions.com/products/crystalreports/.
