报告视图流程解析-优快云博客

1.	The web client sends the view on demand request in a URL typically via the web server to the Web Application Server.
2.	The Web Application Server interprets the requested page and the values sent in the URL request and determines that it is a request to view the first page of the selected report object.
3.	The Web Application Server sends a request to the CMS to ensure that the user has rights to view the object. The CMS checks the system database to verify the user rights.
4.	The CMS sends a response to the Web Application Server to confirm the user has sufficient rights to view the object.
5.	The Web Application Server sends a request to the Crystal Reports Cache Server requesting the first page of the report object.
6.	The Crystal Reports Cache Server checks to see if the page already exists. Unless the report meets the requirements for on demand report sharing (within a set time of another On Demand request, same rights, DB login, parameters), the Crystal Reports Cache Server sends a request for the Crystal Reports Page Server to generate the page. The set time is defaulted to zero.
7.	The Crystal Reports Page Server requests the report object from the Input File Repository Server. The Input File Repository Server streams a copy of the object to the Crystal Reports Page Server. The Crystal Reports Page Server opens the report in its memory and checks to see if the report contains data.
8.	Since a report object does not have data, the Crystal Reports Page Server connects to the database to query for data. The Database returns data to the Crystal Reports Page Server. The Page Server processes the report and then generates the first page of the report. The Crystal Reports Page Server holds the report in temp files in memory until it reaches a 60 minute idle time. The temp files are then deleted from memory.
9.	The Crystal Reports Page Server sends the .EPF page to the Crystal Reports Cache Server. The Crystal Reports Cache Server stores a copy of the .EPF page in its cache directory.
10.	The Crystal Reports Cache Server sends the .EPF page to the Web Application Server. (If the DHTML viewer is used, the Web Application Server converts the .EPF to DHTML.)
11.	The Web Application Server sends the .EPF page to the web server. The web server sends the .EPF page to the user's machine where it is rendered in the viewer in the web client.

1.	The web client sends the view instance request in a URL typically via the web server to the Web Application Server.
2.	The Web Application Server interprets the requested page and the values sent in the URL request and determines that it is a request to view the first page of the selected report instance. The Web Application Server sends a request to the CMS to ensure that the user has rights to view the instance.
3.	The CMS checks the system database to verify the user rights.
4.	The CMS sends a response to the Web Application Server to confirm the user has sufficient rights to view the instance.
5.	The Web Application Server sends a request to the Crystal Reports Cache Server requesting the first page of the report instance.
6.	The Crystal Reports Cache Server checks to see if the page already exists. Unless the report meets the requirements for On Demand report sharing (within a set time of another On Demand request, same rights, DB login, parameters), the Crystal Reports Cache Server sends a request for the Crystal Reports Page Server to generate the page. The set time is defaulted to zero.
7.	The Crystal Reports Page Server requests the report instance from the Output File Repository Server. The Output File Repository Server streams a copy of the instance to the Crystal Reports Page Server. The Crystal Reports Page Server opens the report in its memory and checks to see if the report contains data. Since an instance has data, the Crystal Reports Page Server does not have to access a production database to retrieve records. The Crystal Reports Page Server expands all the records in the memory and keeps them for configurable amount of time in anticipation of new viewing requests, and it creates just one viewable requested page.
8.	The Crystal Reports Page Server sends the .EPF page to the Cache Server. The Crystal Reports Cache Server stores a copy of the .epf page in its cache directory.
9.	The Crystal Reports Cache Server sends the .EPF page to the Web Application Server.
10.	The Web Application Server sends the .epf page to the web server. The web server sends the .EPF page to the user’s machine where it is rendered in the ActiveX viewer in the web client.

1.	The web client sends a view report/document on demand request in a URL typically via the web server to the Web Application Server.
2.	The Web Application Server interprets the requested page and the values sent in the URL request and determines that it is a request to view a Web Intelligence report.
3.	The Web Application Server sends a request to the CMS to ensure that the user has rights to view the object. The CMS checks the system database to verify the user rights.
4.	The CMS sends a response to the Web Application Server to confirm the user has sufficient rights to view the object.
5.	The Web Application Server sends a request to the Web Intelligence Report Server requesting the report.
6.	The Web Intelligence Report Server requests the report and universe file from the Input File Repository Server. The Input File Repository Server streams a copy of the report to the Web Intelligence Report Server. The Web Intelligence Report Engine opens the report in its memory and examines whether the property of Refresh on open of the Web Intelligence document is set. If it is, the QT.dll generates the SQL from the universe that the report is based on.
7.	The Connection Server connects to the database to run the query. The query data is passed through QT.dll to the Report Engine where the report is processed.
8.	The Web Intelligence Report Server sends the finished report to the Web Application Server.
9.	The Web Application Server sends the requested report page to the web server. The web server sends the finished report to the user’s machine where it is rendered to the web client.

1.	The CMS checks its pending schedule list every 60 seconds. When the CMS finds a report/document that is ready to be scheduled, the CMS evaluates whether there is an available Web Intelligence Job Server. The CMS sends the schedule request along with the report location and other processing information to the Web Intelligence Job Server. If the Web Intelligence Job Server is available, the CMS changes the schedule status from pending to running.
2.	The Web Intelligence Job Server forwards the request to the Web Intelligence Report Server.
3.	The Web Intelligence Report Server requests the report from the Input File Repository Server. The Input File Repository Server streams a copy of the report to the Web Intelligence Report Server. The Web Intelligence Report Engine opens the report in its memory. The QT.dll generates the SQL from the universe that the report is based on.
4.	The Connection Server connects to the database to run the query. The query data is passed through QT.dll to the Report Engine where the report is processed.
5.	The Web Intelligence Report Server sends the finished report to the Output File Repository Server.
6.	The Web Intelligence Report Server notifies the Web Intelligence Job Server that the creation of the instance was a success.
7.	The Web Intelligence Job Server updates the instance status to the CMS.
8.	The CMS updates the instance record in the system database to change the instance status to Success.