Troubleshooting

As with any form of troubleshooting, the main goals are first to be able to replicate the problem and second to be able to isolate the issue. Sometimes this sounds easier than it really is. However, keeping this philosophy in mind when troubleshooting will be very helpful. This troubleshooting section discusses solid troubleshooting techniques with regard to BusinessObjects Enterprise rather than specific troubleshooting issues.

BusinessObjects Enterprise systems in a production environment can be quite complex. System components might be duplicated and spread across various servers, and these servers also can span firewalls and DMZs. Throw into the mix a custom-developed BusinessObjects Enterprise Web application and it becomes obvious that the domain of the problem can initially appear quite large. By removing this "noise" from a BusinessObjects Enterprise implementation, most issues can be distilled into one key issue. Many companies have separate development, QA, or test environments. If the problem also exhibits itself in these environments it makes troubleshooting much easier than having to tinker with a production system.

Often the most crucial information regarding problem replication seems too trivial to be verified or checked. Additionally, factors that are taken for granted, or assumed, can raise their heads as essential to solving the problem. So documenting, if possible, all the factors contributing to the environment improve greatly the chances for success. This includes documenting the operating system, patch levels, virus checking systems, disk quota control systems, backup programs, any logs or error reports, and the like.

After documenting and reproducing the problem, preferably in a test environment, you move on to problem isolation where the goal is to simplify the issue. For example, if issues arise when viewing a report instance through a Web application, try to remove the Web application from the equation by verifying that the report instance can be viewed in InfoView or through the Central Management Console (CMC). Another tip in simplifying a problem is to remove duplicate services from BusinessObjects Enterprise. For example, ensure that during troubleshooting only one CMS, WCA, Cache, Page, and Job Server service are running. Isolation of the problem usually consists of reproducing it given one set of circumstances and not experiencing it in another. For instance in this scenario, seeing a problem when viewing a report with the Web application but not with InfoView indicates an issue with the Web application.

When you troubleshoot BusinessObjects Enterprise, having Crystal Reports Designer installed onto the servers where the Page and Job Servers reside provides tremendous value. Often, when a scheduled report fails in BusinessObjects Enterprise, the properties of the instance display the infamous statement: Cannot open SQL Server. This is a very generic statement that can mean a multitude of error conditions.

With Crystal Reports installed on the Page and Job Servers, the report can be run interactively in Crystal Reports so a more meaningful error message can be viewed. If a report doesn't run correctly in Crystal Reports on the physical Job Server, there is certainly no chance of successfully scheduling the report in BusinessObjects Enterprise. Should a report not run in BusinessObjects Enterprise, you should run the report on the BusinessObjects Enterprise server machine within Crystal Reports as your first step. If the report runs, you can look elsewhere for issues.