In this section, we will dive into the BAM server components to help you to understand what happens behind the scenes in the following scenarios:
Opening a report for the first time
Processing Active Data
This is the scenario when a user attempts to open a report for the first time.
 |
This diagram depicts the message flow, which can be interpreted as follows:
1. The client sends an HTTP request containing report definition ID and a list of parameters to the Report Server. An example request is something like:
http://<bam_server_hostname>:<port>/OracleBAM/reportserver/default.jsp?Event=viewReport&ReportDef=58&Buttons=False&ReportParameters=()
In this URL, <bam_server_hostname> is the BAM server hostname, ReportDef is a parameter that specifies the report ID, and ReportParameters is an HTTP request parameter that specifies report parameters.
2. The Report Server processes the request, then invokes the Report Cache method to open a ViewSet.
3. Since this is the first time a ViewSet is opened, the Report Cache invokes Active Data Cache APIs to create a ViewSet.
4. The Active Data Cache instantiates the ViewSet, and registers it as a listener to the associated Data Object Notification Queue.
5. The Active Data Cache builds and executes SQL queries, and returns the initial result set (Snapshot) to the Report Cache.
6. The Report Cache saves the opened Viewset and associated Snapshot in the cache, and then passes the ViewSet and Snapshot to the Report Server.
7. The Report Server transforms the Snapshot to DHTML, using View specific XSL, and sends it to the client along with JavaScript for rendering.
8. After the initial View is rendered successfully in the web browser, the View generates a
getChangeList()request, and sends it through HTTP POST to Report Server ActiveDataServlet.
Note
Why does the client send a separate HTTP request to BAM Report Server after a View is rendered for the first time?
BAM report leverages a push-based mechanism to receive Active Data in real time. After a report is first rendered in a web browser, it has to find out a way to register the View to the Report Server, which maintains persistent connections between the client and BAM Server. Sending the getChangeList() request to ActiveDataServlet creates the persistent connection through which the Active Data changes are pushed.
Up to now, we have mentioned many times that BAM server uses the push-based mechanism to process Active Data. In this section, we will use a diagram to illustrate how Active Data are processed by BAM server components:
 |
As shown in this diagram, Active Data processing message flows are as follows:
1. The Active Data Cache receives a data change Event (Insert, Update, Upsert, and Delete) that happens to one of its managed Data Objects.
2. The Active Data Cache persists the change to the repository, and raises an Event to notify the changes to ViewSet, which is listening on particular Events in the notification queue.
3. The Active Data Cache calculates how the change is affecting the specific continuous query that it is running for the user, and in the end, it will generate a ChangeList, and push it through the Messaging Framework for asynchronous delivery.
4. The Report Cache gets notified when the ChangeList arrives, consumes the XML payload through the Messaging Framework, and saves it into its internal cache.
5. The Report Cache pushes the ChangeList to the Report Cache Channel, which is an internal or JMS topic.
6. The Report Server receives the ChangeList from the Report Cache Channel.
7. The Report Server sends the ChangeList to the client through the persistent connection established by
ActiveDataServletthat you saw before.8. Client side JavaScript receives the
ChangeList, and then updates the Views opened in the browser to reflect the changes in real time.