|
Return to Newsletter Contents...
Troubleshooting Business Objects XI R2
by:
Joe Roberts, Sr.
BI Consultant, BECP
To truly be good at troubleshooting issues with Business
Objects Enterprise XI you must first understand that is more about process than
it is about knowledge. I do not want to discount the importance of understanding
how Enterprise works but at the end of the day it is more about applying that
knowledge to a process and consistently following that process than anything
else.
I’ve always said “troubleshooting Enterprise is like
finding a short in a car. You must start at the right front headlight and check
every wire until you find the short.” If you happen to find the short directly
behind the right front headlight then great! You got lucky! The next time it may
be behind the left headlight and it took you all day to find it. In either case
you start at the right front headlight.
The most important things you must completely understand to
troubleshoot BOEXI are the process flows. With each action requested within the
system certain combinations of servers are employed to deliver the results. You
must understand what talks to what and when. Each action has its own process
flow. For example viewing a Crystal Report on-demand:
1.
The user’s web browser
initiates the request to view
2.
The web application server
checks with the CMS to verify that the user has the proper rights to view this
report on-demand
3.
The web application server
contacts the Crystal Reports Cache Server and requests the first page of the
report
4.
The Crystal Reports Cache
Server looks for that page of the report in cache, since this is an on-demand
viewing it will not find it
5.
The Crystal Reports Cache
Server contacts a Crystal Reports Page Server and requests page one of the
report
6.
The Crystal Reports Page
Server retrieves the report from the Input File Repository Server
7.
The Crystal Reports Page
Server opens the report in memory. When if finds that the report does not have
data it must retrieve the data from the database.
There are several other steps here that
involve the CRPE32.dll that have be omitted for brevity
8.
The Crystal Reports Page
Server sends the logon information to the database and awaits a response
9.
Once the logon has been
verified it sends the SQL to the database for processing
10.
Once the data is returned
the report “reads” the records and then “prints” the records creating the report
11.
Once page one of the report
has completed the “print” process it is returned to the Crystal Reports Cache
Server as requested
12.
The Crystal Reports Cache
Server stores the report page in cache and forwards the page to the Web
Application Server as requested.
13.
If the user is using the
DHTML or Advanced DHTML viewer it converts the report page (.EPF) to HTML and
sends the HTML page to the user’s browser. Otherwise it streams the .EPF file to
the viewer in the user’s browser window
To summarize the process flow it is:
User Browser -> Web Application Server -> CMS -> Web
Application Server -> Crystal Reports Cache Server -> Crystal Reports Page
Server -> Input File Repository Server -> Crystal Reports Page Server ->
Database -> Crystal Reports Page Server -> Crystal Reports Cache Server -> Web
Application Server -> User Browser.
To troubleshoot any process you must understand first the
action being requested and the process flows employed for completion.
Your first step should be to recreate the issue.
During this process I use a system of
“Known”, “Not Known” to verify that the servers involved in the particular
action are working. This should start out with all of the “Not Known” as you
complete an action that involves that service move from “Not Known” to “Known”.
Below is a mental spreadsheet that I would use.
As you step through the process flows move the service from
“Not Known” to “Known”. For instance, being able Logon to Enterprise will
validate the Web Application Server and CMS are functioning.
Your next step will be to verify of any of the left over
services by using other tools and processes available to you. For instance, if
you cannot view a Crystal Report on-demand, try viewing an instance of a report.
If that is successful it confirms that your Crystal Reports Page Server and
Crystal Reports Cache Server are functioning properly. That now leaves the Input
File Repository Server and Database.
Next try to eliminate the Input FRS by either opening a
report from Enterprise using Crystal Reports or publishing a new report to
Enterprise. If that is successful your “Known – Not Known” list now looks like
this:
We now have only one unknown. That doesn’t tell us exactly
what is wrong but we are now looking in the proper place and we have eliminated
Business Objects Enterprise services as a possibility.
Remember:
1.
Develop a process and be
true to it. Use the same process every time you troubleshoot
2.
Know your process flows for
each action
3.
Develop easy to remember
methods for validating each server’s functionality within the context of this
action. Eliminate one server (service) at a time until you are left with the
only possible culprit
4.
Use the tools provided on
the platform to help you
The biggest mistake I see administrators make when faced
with troubleshooting an issue is to jump to a conclusion based on incomplete or
erroneous assumptions or error messages. Regardless of where your gut tells you
the problem lies, be true to the process and you will find it.
Happy troubleshooting!
Go to Top |
Return to Newsletter Contents
|
