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.
