Understanding the BI Publisher Scheduler
The updated architecture of the 11g BI Publisher Scheduler uses the Java Messaging Service (JMS) queue technology.
This architecture enables you to add multiple BI Publisher servers to a cluster and then dedicate each server to a particular function: report generation, document generation, or specific delivery channels.
Architecture
The architecture of the BI Publisher Scheduler uses JMS queues and topics to provide a highly scalable, highly performing and robust report scheduling and delivery system.
The figure below displays the scheduler architecture.
The following list describes the tasks performed by the scheduler when a job is submitted:
-
Submit Job
-
Stores job information and triggers in Quartz tables
-
-
Job Processor
-
When quartz trigger is fired, puts job information in Scheduler job queue
-
-
Bursting Engine / Batch Job Process
-
Bursting Engine Listener
-
Takes the scheduled job information from the queue
-
Extracts data from data source
-
Splits data according to bursting split by definition
-
Stores data temporarily in temp folder
-
Puts report metadata into Report Queue
-
-
Batch Job Process
-
Takes the scheduled job information from the queue
-
Extracts data from data source
-
Stores data temporarily in temp folder
-
Puts report metadata into Report Queue
-
-
-
FO Report Processor
-
Listens to Report Q
-
Generates report based on metadata
-
Stores report in shared TEMP directory
-
Puts report delivery information in Delivery Queue
-
-
Delivery (E-mail, File, FTP) Processors
-
Listen to Delivery queue
-
Call delivery API to deliver to different channels
-
-
BI Publisher (BIP) System Topic
The BIP System Topic publishes the runtime status and health of the scheduling engine. The topic publishes the status of all instances, the thread status of messages in the JMS queues, the status of all scheduler configurations such as database configuration, JNDI configuration of JMS queues and so on.
About Clustering
BI Publisher clustering support enables you to add server instances on demand to handle processing and delivery load.
The figure below illustrates clustering in an Oracle WebLogic Server. Note that the report repository and the scheduler database are shared across the multiple instances; also, the JMS queues for scheduling and JMS topic for publishing diagnostic information are shared across the server by registering JMS queues and topics through JNDI services.
Each managed server instance points to the same report repository. In each managed server instance all the processes (Job Processor, Report Processor, E-mail Processor, FTP Processor, Fax Processor, File Processor, Print Processor, and Web Dav Processor) are configured. Therefore the moment a server instance pointing to the same repository is deployed, it is added to the cluster and all the processors in this instance are ready to run.
You can select the process to enable on any server instance, thereby using the resources optimally. Moreover, if there is a demand to process heavier jobs you can add more instances for report processing. Similarly, if e-mail delivery is the most preferred delivery channel, then more instances can be added to scale up e-mail delivery.
For more information about clustering and high availability, see High Availability Guide.
How Failover Works
BI Publisher provides a robust failover mechanism so that no report fails to deliver due to server unavailability.
Achieve this by balancing each process of the Scheduler using two or more nodes in a cluster thereby ensuring that a failure of any node must be backed up by the second node without any loss of data. For example, by enabling the Job Processor in two nodes, if one node fails, then the second node can process the jobs.
Note:
If a node goes down, the other nodes continue to service the queue. However, if a report job is in one of the following stages of execution: data retrieval, data formatting, or report delivery, the job is marked as failed, and must be manually resubmitted.