Do I have to change all of my reports to get them to work on the server?
No. But you do have to provide thread-safe containers for the database connection components needed by your reports. That may sound scary, but it’s really no big deal. The documentation for the Server Edition will include directions for creating thread-safe containers for all of the popular database/connectivity product combinations. These containers can be Delphi data modules or invisible forms and should be configured with the appropriate Volume components or direct registration calls. Through the registration process you associate containers with reports so that the reports can successfully connect to a database when loaded. Report related event-handler code must also be thread-safe. However, unless you are referencing global objects or resources that exist outside the context of the container form or datamodule, then the code is probably thread-safe as is.
How hard is it to get the server up and running?
It is very easy. The Server component encapsulates all of the functionality required to communicate with clients and execute reports on their behalf. Your primary task will be registering your reports with the server’s report catalog. If the reports are deployed as components on Delphi forms or in data modules, this requires a simple registration call to the report catalog. If the reports are deployed as report templates, as report archives, or as report templates in the end-user database structure it is even simpler. You can connect one of the Volume components to the file directory structure or the database tables and it will dynamically generate catalog items for all of the reports residing in the structure. Using this latter scheme you can add and remove reports without bringing the server down.
How many users can practically be served at once?
It depends. A report based on a simple query, which retrieves few records and generates few pages can be run by many users at once. A report which utilizes multiple complex queries, pulls millions of records and generates tens of thousands of pages may be all the server can handle at any one time. The best way to determine the answer to this question is to create a report server with your reports and see how it goes. You have lots of options regarding live report vs. archive report, full generation vs. incremental generation and caching configuration options on both the report server and the web tier. There is also multiple CPU and multiple server configurations to consider.
How fast is the server?
Just as fast as ReportBuilder, but certainly no faster. Remember that
directory structures (folder trees), search criteria, and page objects must be
sent across the wire to the client. This takes additional time. Yes, the messages are compressed. Yes, multi-threading means that the messages will be processed in a timely fashion. But there are many, many factors which control the performance any given user may experience. The best bet is to test the server using your reports and your client application.
How do I stop a ‘runaway report’ on the server?
The Volume.PublishingOptions can be used to specify the maximum number of pages and maximum number of seconds for report execution. These values can be used as the defaults for all reports in the volume. The Volume.OnGetPublishingOptions event can be used to dynamically set the publishing options for individual reports.
Proper use of the Volume.PublishingOptions should prevent runaway reports. However, in the event of a runaway report, you will need to stop the service or (if you are running the server in stand-alone mode) shut down the server application. A future version of the Server Edition may contain an administrative application where you can stop individual sessions – but for now we are focused on solidifying a fast, stable and scalable core.
What happens if the server crashes?
When configured correctly, the server will simply clean up after itself and automatically restart. This is why you should deploy your server application using the Windows Service scheme. Under this scheme if the server crashes, the Windows Service can automatically restart the application. The server application is running in its’ own process space – which means that other applications on the same machine should not be affected if the server crashes. For reasons of both performance and stability, you should also run your web tier as an Isolated Process. This keeps other ISAPI DLLs on your web server from crashing your web tier and vice versa. Of course, when a crash does occur, the exception will be logged – so you should be able to isolate the report causing the problem.
Does the server do any kind of logging?
Yes. Both the report server application and the web tier will automatically log any exceptions (unless logging is turned off.) The web tier also has a ‘verbose’ mode where it logs every request, every response, every run of the garbage collector and every exception. By default this verbose mode is turned off, because logging adversely affects performance. The log format can be set to ASCII text or XML.
What web browsers are supported?
Can I hot-swap reports running on the server?
Yes and no. You can replace a report template or archive in a registered directory, provided that the template or archive is not currently being loaded. You cannot seek out and kill an active session involving the replaced report and then restart the session to its last point of progress. Of course, changing reports which are compiled directly into the server application requires that the server be stopped and replaced with the new executable containing the new reports. This is why the TemplateVolume, the ArchiveVolume and the ExplorerVolume components are probably better than direct registration of report components – these volumes specify locations and allow you to change the reports available at those locations without bringing down the server.
Can I administer the server remotely?
Yes. Using PCAnywhere or the remote capabilities of Windows 2000/XP, you can run the RB Services Manager. The RB Services Manager is available from the Start Menu, under ReportBuilder | Services Manager. It is a system tray based application which allows you to start/stop the report server or change the location of the server app (if you need to move the app to a different directory.) The RB Services Manager is available only when the server is deployed as a Windows Service.
How is printing handled from the web browser?
HTML does not print well – it just wasn’t designed for it. And while web browsers have made some progress in this area, the sophisticated content possible with ReportBuilder is often too much for them. The best answer at this point appears to be PDF. PDF is designed for printing, and the Acrobat Reader plug-in is just about ubiquitous. So if you want to support high-quality printing from the web browser, consider acquiring a PDF device from either www.waler.com or www.pragnaan.com. The Server Edition contains adapter classes which makes it possible to deploy either of these products in the web tier with the inclusion of a single unit name in the uses clause of the web module.
Does the server support https?
Yes. Not only can you secure the web tier so that it is only accessible via https, you can configure RB thin-client components so that they talk to the web tier instead of the report server, making thin-client communications secure.
Does the server provide encryption?
The first version of the server does not include encryption. One solution is to use HTTPS to communicate between clients and the WebTier. Then deploy the Server and the WebTier on the same machine or perhaps run the Server application on a separate machine behind your firewall.
Can I provide a login and user name before users get access to the reports?
Yes. The Server Edition includes support for adding session level and report level parameters. Examples are included that show how to implement a custom login form and restrict access to reports based upon login information.
Can Server run on Linux?
No. While the report engine inside the server application is functioning without a user-interface, many dependencies on the Windows Operating System (and the associated API) still exist. We consider a Linux server to be a mammoth undertaking and are not committing to such a project at this time.
Can I use the Server Edition to build ISAPI, ASP, and Apache applications?
The Server Edition leverages Delphi’s ability to build several types of web applications. The WebTier component can be included in a Delphi WebBroker application, WebSnap application, or Active Server Object. The Server Edition includes examples of using each of these technologies to build web applications.
Can I use the Server Edition with WebBroker, WebSnap, or IntraWeb?
Is the Server Edition royalty-free?
No. The Server Edition provides deployment licenses which allow you to run a server application on a single CPU. If you decide to run the application on a machine with multiple CPUs then you will need to purchase one deployment license for each CPU. The Server Edition includes one server development license and one server deployment license. Each deployment license is ‘unlimited-user’, you can run as many users against any given server as you like.
Do I need to buy both the Server Edition and the Enterprise Edition?
No. The Server Edition includes the Enterprise Edition, so you’ll have all of the tools you need to both create reports and deploy them to the web.
How much does it cost?
The Server Edition is US $999 - and that includes everything in the Enterprise Edition, the Server Edition components, one server development license, and one server deployment license. The Enterprise Edition already costs $749 – so you are basically getting all of the Server Edition technology for $250. Considering that additional deployment licenses are only $249, and that each license allows you to run unlimited users against the server, it’s probably the most cost effective solution out there.