ReportCaster Processing

In this section:

Reference:

The following image shows the ReportCaster components and the processing that takes place when ReportCaster accesses an SQL repository to create, execute, and distribute a scheduled job.

The Distribution Server is a Java application that governs the process of submitting and distributing a scheduled job. You can install the Distribution Server on the same platform as the Reporting Server and the components (which reside on the web or application server), or it can be installed on a different platform.

The Reporting Server processes a scheduled request, retrieves the data, and returns the report to the Distribution Server, which distributes the output. ReportCaster supports multiple Reporting Servers (specified in the ReportCaster Configuration tool), and one Repository (specified in the Client Configuration in the Administration Console).

When you create a ReportCaster schedule, one of the properties of the schedule set by ReportCaster is the next run time (NEXTRUNTIME) for that schedule. The Distribution Server checks for schedules in the Repository that have a next run time less than or equal to the current time. Once the scheduled job runs, the NEXTRUNTIME is updated to the next instance that the schedule is set to run.


Top of page

x
Reference: ReportCaster Processing of a Scheduled Job

The following steps describe what happens when the Distribution Server identifies a schedule to run.

  1. The Distribution Server prioritizes the scheduled job with other schedules in the Distribution Server queue. When creating a schedule, there is a Priority parameter where you can specify a priority value from 1 to 5, where 1 is the highest priority and 5 is the lowest priority. The default priority value is 3. The Distribution Server queue sorts scheduled jobs by priority and then by time. If during a schedule cycle one or more jobs remain in the queue when the next schedule cycle begins, these jobs are reprioritized to include new jobs entering the queue.
  2. When a session (thread) to the Reporting Server is available, the Distribution Server dynamically retrieves schedule, parameter, and alert information from the WebFOCUS Repository. The number of concurrent threads available for job dispatching is controlled by the Maximum Thread parameter setting in the ReportCaster Console Configuration tool. Each Reporting Server that is configured in ReportCaster has its own thread allocation. In addition, threads can be allocated for jobs that do not use a Reporting Server. The maximum number of threads is the total of these separate thread settings. Additionally, reports (WF Server Procedures, Standard Reports, and My Reports) are packaged for submission to the IBFS system for security and WF Client configuration processing. The IBFS system submits the scheduled job to the Reporting Server.
  3. The scheduled job of a user can be one of the following:
    • WF Server procedure. A -INCLUDE retrieves the procedure (FEX). The procedure must be accessible from the server path of the Reporting Server.
    • Managed Reporting. Calls the Client to obtain the procedure (FEX) from the Repository.
    • URL. ReportCaster can schedule a URL from any web server and distribute the content to specified recipients.
    • File. ReportCaster can schedule the distribution of files containing static content to which the Distribution Server has read access. For example, if you want to distribute a Microsoft® Word® document, you can distribute it by specifying the fully qualified path and file name of the file, for example, D:\salesforecast\regionalquota.doc.
    • FTP. ReportCaster can schedule the retrieval of a file from any FTP server.

    The scheduled job includes distribution information, parameter values, and ReportCaster internal variables (such as schedule ID, schedule procedure name, pre-processing and post-processing procedures, and the user ID (owner ID) that scheduled the job).

  4. When the scheduled job is a:
    • procedure (WF Server Procedure or Managed Reporting procedure). The retrieved reports are packaged for submission to a Reporting Server. When ReportCaster prepares and submits a scheduled job for WF Server Procedures or WebFOCUS reports (Managed Reporting), it sends commands to the IBFS system to submit to the Reporting Server. Resource Analyzer, which is used to track and monitor requests submitted to the Reporting Server and resources used to create the report that will be distributed, then retrieves these commands for the purpose of monitoring the resources used to create the report. The Reporting Server runs the procedure, retrieves the data, creates the report, and returns the report to the IBFS system which returns it to the Distribution Server. The Distribution Server then processes the distribution information and distributes the report. For graph requests, the data is returned to the Distribution Server, which creates the graph image and distributes it.

      Note: You can specify that certain commands are to be run prior to the execution of a scheduled job by using the Universal Profile setting in the WebFOCUS Administration Console. For more information, see the WebFOCUS Security and Administration manual.

    • URL. The Distribution Server submits the URL to a web server, which runs the URL. The content is then sent back to the Distribution Server, which distributes it.
    • File. The Distribution Server accesses its mapped drives to retrieve the file, which it then distributes.
    • FTP. The Distribution Server accesses an FTP server and retrieves the report output, which it then distributes.
  5. The Distribution Server distributes scheduled output as an email message, through FTP or SFTP, to a printer, as a report in a Managed Reporting (WebFOCUS repository) folder, or to the Report Library. You can also distribute the scheduled output to a fax machine using a third-party email to fax provider.

    WF Server Procedures and Managed Reporting support bursting, which enables you to send portions of a report to specific recipients. If you are distributing a burst tabular report, the burst value is determined by the first BY field. If you are distributing a burst graph report, the burst value is determined by the second BY field. The burst value is automatically determined by the internal matrix. The internal matrix is a memory area that stores each database field value and calculates values referenced by the TABLE or GRAPH request.

  6. When the Distribution Server has distributed the output (or is unable to distribute the output), it then processes the log information and writes job information to the log tables in the WebFOCUS Repository.

    Note: The logging process has been modified so that messages are written to the WebFOCUS Repository as they are available, rather than all at once at the end of a schedule. ReportCaster log information is written to the log tables as the schedule progresses. As a result, you can run a log report while a schedule is running to determine how far a schedule has progressed.

    Error conditions in log reports appear in red text and warnings appear in orange text.

  7. If notification is requested, the Distribution Server sends an email notification. The name of the mail server that processes the notification email is specified in the Notify Mailhost setting in the Configuration tool. If mail server is blank, ReportCaster uses the default mail server used to distribute an email schedule, which is specified by the Mailhost setting in the Configuration tool.

    Error conditions occur for log reports or notification when:

    • A FOC error message is returned to the Distribution Server.
    • There is no report to distribute.
    • There was an error when communicating to services (Email, (S)FTP, printer, Managed Reporting, Report Library).

    Tip: We recommend using different mail servers for notification and email distribution. Using separate mail servers ensures that you will still receive notifications if the default mail server falters.



Example: Executing a Scheduled Job

In this example, the Distribution Server polls the BOTSCHED table every minute looking for scheduled jobs. However, note that ReportCaster enables authorized users to change the polling interval for the Distribution Server using the Reader interval setting in the Configuration tool. You can specify an interval from 1 to 999999 minutes.

  1. At 9:01 AM, you schedule a job with a start date/start time of today at 12:00 PM and an end date/end time of tomorrow at 3:00 PM. The job is scheduled to run every two hours.
  2. At 9:02 AM, the Distribution Server reads all records from the BOTSCHED table with a NEXTRUNTIME equal to the current time. The job does not qualify since it has a start time of 12:00 PM.
  3. The Distribution Server polls the BOTSCHED table every minute thereafter, looking for jobs with a NEXTRUNTIME less than or equal to the current time.
  4. At 12:00 PM, the Distribution Server reads the BOTSCHED table. The job qualifies since its NEXTRUNTIME is equal to the current time. The job is put in the Distribution Server queue and the Distribution Server updates its NEXTRUNTIME by two hours so that the NEXTRUNTIME is 2:00 PM.
  5. The Distribution Server polls the BOTSCHED table every minute thereafter, looking for jobs with a NEXTRUNTIME less than or equal to the current time.
  6. At 2:00 PM, the Distribution Server reads the BOTSCHED table. The job qualifies since its NEXTRUNTIME is equal to the current time. The job is put in the Distribution Server queue and the Distribution Server updates its NEXTRUNTIME by two hours so that the NEXTRUNTIME is 4:00 PM.
  7. This process repeats itself. The job will run every two hours until 3:00 PM tomorrow. The last time the job will be put in the run queue is tomorrow at 2:00 PM.

Note: For information about recovering jobs that were placed in the Distribution Server queue but whose NEXTRUNTIME was not updated, see Recovery. For additional schedule considerations, see Time Zone Considerations and Daylight Saving Time Considerations.


Top of page

x
Time Zone Considerations

Users who access ReportCaster remotely from a different time zone must schedule jobs using the time zone of the machine on which the Distribution Server is located. When viewing job schedules, the displayed date and time is from the time zone of the Distribution Server.

ReportCaster uses Java technology, which always adjusts for Daylight Saving Time, regardless of Windows® settings. If you are in an area that does not observe Daylight Saving Time, scheduled jobs will run at the correct time. However, some internal files will add an hour to time stamps during this period. These files include the following:


Top of page

x
Daylight Saving Time Considerations

When considering the effect of Daylight Saving Time (DST) for jobs scheduled by ReportCaster, the main thing to remember is that 1:59:59 AM is when the time change occurs. As a result, the clock time is set to either 3 AM (when DST begins) or 1 AM (when DST ends).

A simple rule to remember is that regardless of the time change, the schedule interval stays the same. This is because the schedule run time is based on elapsed time rather than the actual clock time.

The following table lists and describes the expected behavior for jobs scheduled by ReportCaster when Daylight Saving Time is in effect.

Interval

Description

For example:

Schedule is set to run once at a specific time, or to run every day, week, month, or year.

The schedule runs at that time, regardless of the time change.

A 9:15 AM schedule will still run at 9:15 AM.

Schedule is set to run every minute or hour when DST begins.

The schedule is advanced by 1 hour.

A schedule that runs every 2 hours: 12:00 PM, 2:00 AM, 4:00 AM, and so on.

Will run at the following times: 12:00 PM, 3:00 AM, 5:00 AM, and so on.

This occurs because at 1:59:59 AM, the clock is set ahead to 3:00 AM.

Schedule is set to run every minute or hour when DST ends.

The schedule is set back 1 hour.

A schedule that runs every 2 hours: 12:00 PM, 2:00 AM, 4:00 AM, and so on.

Will run at the following times: 12:00 PM, 1:00 AM, 3:00 AM, and so on.

This occurs because at 1:59:59 AM, the clock is set back to 1:00 AM.


WebFOCUS