Reasons For Timeout Errors When Running Scheduled Reports

Timeout errors aren't obvious when you encounter them.

There are at least 3 settings in XI that will cause your Web Intelligence reports to time out.

1. A universe level setting

2. Report Server Setting

3. CCM level startup parameter for the job server

While trying to get scheduled reports running for a client, we encountered some issues due to a report running too long.

Thank heavens that BO provides a nice user friendly error message that says:

"report ran too long."

NOT.

As usual a little detective work was needed test theories.

Informatica Job Processing

In our environment, Informatica runs nightly jobs that in turn kick off business objects processing using file based (triggered) events. Informatica processing is broken down into groups. Each time a group finishes Informatica kicks off a shell script that uses ssh to create the trigger file on the business objects server.

One of the groups was failing.

In our case, we had reports that ran in object packages. The package would fail because of one of the reports in the package failing.

The first time we received an error it appeared to be an Oracle error:

ORA-01013 user requested cancel of current operation

Our resident Oracle expert/dba informed us that this was

Cause: The user interrupted an Oracle operation by entering CTRL-C, Control-C, or another canceling operation. This forces the current operation to end. This is an informational message only.

So from Oracle's perspective, Business Objects was just telling Oracle: "I quit."

After doing some digging we found 3 areas to tweak to increase run time.

1. Universe modifications. There is a setting that can be made in Universe Designer that will limit execution time for a database connection.

The universe access restrictions allows execution time limits be set so that the universe designer can limit access to database resources.

Here is the setting:

 

universe-access-restriction-1.gif

It is noteworthy to mention that certain things accessed through Designer are written back to the Business Objects server apart from exporting the universe.

Access restrictions are an exampleof this.

I did to increase the execution time from 10 minutes to 30 minutes. The changes were immediately written to the CMS (without my exporting the universe). There are certain pieces in designer which have varying degrees of association/connection with the universe.

2. Report Server Setting. There is a setting that can be made through the CMC to extend the timeout of the report server.

Here is where to access the setting:

web-intelligence-report-server-settings-1.gif

This restriction applies server wide. While the universe access restriction can be controled at the group or user level, this report server setting is set for all jobs that run on the server.

Much less granular control.


3. CCM level setting.
There was a problem in XI release 1 having to do with the default CORBA timeout being set unreasonably low for many BO installations.

Only 10 minutes.

The full BO discussion can be read here:

http://technicalsupport.businessobjects.com/KanisaSupportSite/search.do?cmd=displayKC&docType=kc&externalId=c2018041&sliceId=&dialogID=7664327&stateId=1

The fix would involve specifying a longer timeout on the call made to the affected job server… so in our case that would be the Web Intelligence job server.

Since we were running Linux, this would have involved editing one of the unix shell scripts that starts our BO environment and restarting.

I've heard mixed reports as to whether this was fixed with XI release 2.

Taking care of 1 (universe setting) and 2 (report server setting via the Central Management Console) fixed our issue. We didn't need to mess with 3.

Spread the word

del.icio.us Digg Furl Reddit

Permalink • Print • Comment

Trackback uri

http://www.boguru.com/business-objects-scheduled-reports-timeout/trackback/

WordPress database error: [Table './boguru/wp_comments' is marked as crashed and last (automatic?) repair failed]
SELECT * FROM wp_comments WHERE comment_post_ID = '8' AND comment_approved = '1' ORDER BY comment_date

Leave a Comment




WordPress database error: [Table './boguru/wp_ras_image' is marked as crashed and last (automatic?) repair failed]
INSERT INTO wp_ras_image (id, createtime, word) VALUES (697354, 1711713984, 'cfp7nqp')

*
To prove you're a person (not a spam script), type the security text shown in the picture. Click here to regenerate some new text.
Click to hear an audio file of the anti-spam word