Skip to Content
Author's profile photo Trevor Dubinsky

What actually happens when you schedule a report to run “right-now”?

Happy 2011!

One of my goals last year was to be active in my blogging. I wasn’t as prolific as I had hoped but I will attribute that to it being my first real year of blogging. This year I want to keep that goal and I am starting with a bang! First with today’s topic, not typical for me, and I already have a second blog in draft form!

As mentione this is not a typical subject for me as it deals more the architecture of Business Objects Enterprise (BOE) instead of dealing with our .NET SDKs. However many of our developers, for various reasons, use the job server to schedule a report to run immediately, then view the report’s instance. A case came up just this week where the user wanted to know more technical details of what happens when this type of scheduling is done; I wrote it up for them and thought I would share it with you. This is for BOE R2 and R3, and I would assume the same process works with R4.

When you schedule a report to run now from your .NET code (or any web application for that matter) this is what happens:


1. The application/ Application server passes the schedule request to the Central Management Server (CMS).

2. The CMS determines whether or not the user (user logged on in your application) has the appropriate rights to schedule the report.

3. If the user has the appropriate rights to schedule the report, the CMS commits the scheduled object request to the CMS system database.

4. The CMS regularly checks the system database to determine if there are any objects scheduled to run at that time. When the scheduled time arrives the CMS locates an available Crystal Reports Job Server based on the Maximum Jobs Allowed value configured on each Crystal Reports Job Server. More info on this step below.

5. The CMS sends the job information to the Crystal Reports Job Server.

6. The Crystal Reports Job Server determines the location of the Input File Repository Server that houses this report. The Crystal Reports Job Server then requests the report template from the Input FRS.

7. The Input FRS locates the report template and then streams to the Crystal Reports Job Server.

8. The report template is placed in a temporary directory on the Crystal Reports Job Server.

9. The Crystal Reports Job Server launches a child process (JobServerChild.exe) to coordinate running the report.

10. JobServerChild.exe launches ProcReport.dll and passes it all instances received from the Crystal Reports Job Server. ProcReport.dll calls Crpe32.dll.

11. The report is created when the Crpe32.dll completes the following tasks:

• Open the report.

• Connect to the production database.

• Process the report.

• Create and save the report instance.

• Pass the report back to JobServerChild.exe.

12. The Crystal Reports Job Server updates the CMS periodically with the job status. At this time the status shows that the report is processing.

13. JobServerChild.exe uploads the report instance to the Output FRS.

14. The Output FRS notifies the JobServerChild.exe that the report has been saved successfully.

15. JobServerChild.exe notifies the Crystal Reports Job Server that the report creation has completed.

16. The Report Job Server updates the CMS with the job status. The JobServerChild.exe clears itself from memory.

17. The CMS updates the job status in its memory, and then writes the instance information to the BusinessObjects Enterprise System database.


For Step #4 when you schedule the report to run “right-now” the CMS does not just send the report to be run. What it does is write a record to its CMS database with all the job information. The reason for this is to ensure that the new job does not jump the queue in front of jobs that are currently waiting.

The CMS on a regular recurrence queries its database for jobs to be run and does them in order passing the information to the next available job server. If a Job Server is busy the job is left in the CMS database until the CMS polls its database again. By default the CMS queries its database every 60 seconds for jobs. So with the default values you will have a minimum of a 1 second wait, until a maximum of 60 seconds. If the jobserver is busy it will be another 60 seconds before the job is attempted again.

You can override this polling frequency however this is not recommended as it can cause an overload on the system. It is described in . KBase 1286979.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mark Richardson
      Mark Richardson
      Good document.

      This is what happens when you are SCHEDULING to a "Default Enterprise Location".

      What happens when you use an alternate destination...?

      Business Objects Inbox
      E-mail (SMTP)
      FTP Server
      File System (Unmanaged Disk)

      This would be helpful to know also as there are lots of potential "block-points" when you start pointing outside of the BOE infrastructure.

      Author's profile photo Trevor Dubinsky
      Trevor Dubinsky
      Blog Post Author
      Thanks for the feedback and good questions.

      There is actually very little changed between all these destinations. The major difference would be step 13:

      13. JobServerChild.exe uploads the report instance to the Output FRS.

      For unmanaged destinations email, FTP and File System the JobServerChild.exe calls functions inside of the CRPE32.dll with the parameters of how it is supposed to process the report. The JobServerChild then updates the CMS on the result of the job, success or failure with error message. The CMS then updates its database so it is recorded in the history of the report. The big difference is that only the status is updated and not uploaded to the repository.

      With scheduling to an InBox the process is identical, except that the Parent Object for the report is set to the User's InBox instead of to the original report. The report will then inherit the rights and security for the users inbox instead of the parent report.

      I hope this clarifies?

      Author's profile photo Mark Richardson
      Mark Richardson
      ...I think it does upload a copy into the Output FRS (this may be optional).

      If we send an e-mail SMTP as an attachment - there is still a copy in InfoView HISTORY that we can call-up so it must be in the FRS too.

      I would assume it is the same for all of the "Non-BOBJ" destinations - it keeps a BOBJ copy and sends a duplicate to the external location.

      Author's profile photo Trevor Dubinsky
      Trevor Dubinsky
      Blog Post Author
      Thanks for the reply! So the official workflow doesn't show a file being stored in the Output File Repository Server (OFRS), however after some research I found that when you schedule to non-BOBJ or non-managed destination there is a check box to keep a copy in the OFRS. If this is checked then the exported report is also copied to the OFRS.

      Again thanks for the reply, I have learned something new.