How to Get All ReportCaster Components to Recognize a Configuration Change

By Susan Trommer

Whether you’re using ReportCaster 4.3.x or 5.2.1, getting the ReportCaster components to recognize a configuration change is important. Before covering how to make this happen, it is important to understand ReportCaster’s components and how they interact.

ReportCaster is composed of a database repository, Java™ application, Web application, and a component on the WebFOCUS Reporting Server. When ReportCaster is configured with Managed Reporting, integration in the area of MR User Administration creates and maintains users within both the MR and ReportCaster repositories.

The ReportCaster repository is a set of database tables, which can be SQL-based (Oracle, SQL Server, DB2) or FOCUS database tables governed by the FOCUS Database Server (FDS). ReportCaster stores schedule, distribution, log and report content (new Report Library option in Release 5.2) in these repository tables. Note that the Report Library requires a SQL-based repository because of the use of a BLOB field to store report content.

The Java Application is named the ReportCaster Distribution Server. You may hear it referred to as the ReportCaster Server or just Distribution Server. Upon startup the Distribution Server reads the ReportCaster configuration file (bkrsched.cfg in 4.3.x and dserver.xmls in 5.2.1) to obtain information for the ReportCaster environment, including the following:

	Default user attributes
	Code page setting
	Repository connection information
	WebFOCUS Reporting Servers (data servers) that jobs can be scheduled against
	Security settings
	Whether Managed Reporting, Report Library or Two-Way Email is part of the configuration
	Communication settings

The Distribution Server is the component that polls the repository tables for schedules to run and obtains the report output back from the source (WebFOCUS Reporting Server, URL, or the content of a file). In Release 5.2.1 it also distributes the output to the specified destination (e-mail, printer, FTP, library, managed reporting, fax via third-party e-mail integrator).

The Web application resides on a Web or application server. In 4.3.x this tier is composed of the ReportCaster Servlets that are defined on the CLASSPATH of the application server. On the Web tier you will find the ReportCaster applet user interfaces, HTML and JSP pages for the ReportCaster console, and the ReportCaster sample API application.

In 5.2.1 ReportCaster is a Web application. Within the ReportCaster Web application there are servlets, the ReportCaster Administrator and the Developer user interface, which uses Java Web Start and dynamically downloads to the user’s desktop only once until a later version is deployed. The application also contains JSP pages for the ReportCaster DHTML User Interface and ReportCaster Console, and the ReportCaster Java Bean API. For both 4.3.x and 5.2.1 these components make up the interactive layer that the user interfaces are built on and communicate with.

The ReportCaster Servlets communicate directly with the Distribution Server to obtain configuration information and store it in memory until the 4.3.x servlets or 5.2.1 Web application is recycled/reloaded. They read and write to the ReportCaster repository information for scheduling, distribution and log reports. In addition, in Release 5.2.1 the ReportCaster Server Configuration tool reads and writes (via a servlet call to the Distribution Server) configuration information to the ReportCaster server configuration file on the Distribution Server. In 4.3.x there is no GUI tool for maintaining the ReportCaster server configuration. The file bkrsched.cfg that resides in the /cfg directory under the Distribution Server installation is manually edited.

The final component of the ReportCaster solution is the WebFOCUS Reporting Server. In release 4.3.x the server not only creates the report output as a result of a TABLE request, but also distributes the output to the specified destination (e-mail, printer, FTP, library, managed reporting or fax via third-party e-mail integrator). In release 5.2.1, it only creates the report output (result of TABLE or GRAPH request) and sends the report output in memory back to the Distribution Server. In addition, both 4.3.x and 5.2.1 have three ReportCaster subroutines for running a scheduled job, bulk-loading a distribution list and maintaining a distribution list. These subroutines communicate with the ReportCaster Servlets to perform these functions.

User Administration is integrated between Managed Reporting and ReportCaster when ReportCaster is configured with Managed Reporting. This means that when a Managed Reporting group or user is created with ReportCaster capabilities (ReportCaster Administrator, Scheduling or Library) using the MR User Administration tool (whether using Developer Studio or the browser-based MR User Administrator Applet Environment), MR User Administrator communicates to ReportCaster using the ReportCaster Bean API to create the same group or user in the ReportCaster repository user tables. So the MR groups and users are also ReportCaster groups and users, thus integrating WebFOCUS product components and eliminating redundancy and maintenance. In a future release of WebFOCUS, the maintenance of two repositories (MR and ReportCaster) will be eliminated by the replacement of a single repository for all WebFOCUS components.

Now that you have an understanding of the ReportCaster components and how they interact, let’s recap the areas that are reading and storing in memory ReportCaster configuration information. When the Distribution Server is started, it reads the configuration file (bkrsched.cfg in 4.3.x and dserver.xmls in 5.2.1). When the first communication occurs with the servlets (one that is in the ReportCaster Web application or one that is created on the fly through a JSP that dynamically compiles into a servlet), a call is made to the ReportCaster Distribution Server to obtain the information in the same configuration file that the Distribution Server reads. This way, the ReportCaster configuration is stored from only one file.

Therefore, when changing the ReportCaster configuration, manually in 4.3.x or via the configuration tool in 5.2.1, the Distribution Server must be restarted and the ReportCaster Web application in 5.2.1 or ReportCaster servlets in 4.3.x must be reloaded. In addition, in 5.2.1 when ReportCaster is configured with Managed Reporting, the WebFOCUS Web application must be reloaded.

To assist you in identifying and isolating problems related to restarting/reloading the Distribution Server or WebFOCUS and ReportCaster Web/application server components, here are some of the most common problems’ symptoms and solutions I’ve assisted in resolving.

Symptom: While trying to create a MR group or user with ReportCaster capabilities, you get an error mesage about being unable to communicate to the ReportCaster repository.
Solution: Make sure the Distribution Server has been started.

Symptom: You added a Data Server to the ReportCaster configuration, but the scheduling user interface does not list it.
Solution: Check to see if you restarted/reloaded the ReportCaster Servlets (4.3.x) or ReportCaster and WebFOCUS Web applications (5.2.1). It is common to forget to do this and only restart the Distribution Server. The ReportCaster servlets need to obtain the current configuration information from the Distribution Server to list the data server you added.

Symptom: You made extensive changes to the 5.2.1 ReportCaster configuration and saved them but then decided not to keep them, so you removed/deleted your dserver.xmls file. But when you restarted the Distribution Server and ReportCaster and WebFOCUS servlets/Web application, your configuration did not include a lot of the settings you had before you made your changes.
Solution: The 5.2.1 ReportCaster configuration tool only maintains the dserver.xmls file. The dserver.ini file created at installation time is not updated. You can either manually update the dserver.ini file for a base configuration consistent with your dserver.xmls file or back up your dserver.xmls file before making modifications to your ReportCaster configuration.

Symptom: You turned on servlet traces but the trace file is not getting created.
Solution: Make sure the trace file name is a fully qualified path and filename and that the path you specify is accessible and writeable on the Web/application server platform. Also make sure you restart/reload the ReportCaster Servlets (4.3.x) or ReportCaster and WebFOCUS Web applications (5.2.1) to obtain the updated configuration information and confirmation that you turned on the servlet trace.

I hope this article has given you a better understanding of how the ReportCaster components interact, what you need to do to make sure your system recognizes modifications made to a ReportCaster configuration and avoid problems related to ReportCaster configuration changes not being recognized.