Introduction
Most WebFOCUS teams treat ReportCaster as a scheduler that sends reports by email. That description is technically accurate, but it dramatically undersells what the tool does architecturally — and why the decisions made during ReportCaster configuration have downstream effects on performance, security, and compliance that are hard to undo later.
This post covers the ReportCaster architecture in enterprise WebFOCUS deployments: the Distribution Server model, burst scheduling, failover design, and how security policies govern what gets distributed to whom. If you are sizing a ReportCaster deployment or auditing an existing one, this is the guide to work from.
The Distribution Server: More Than a Queue Manager
ReportCaster’s execution engine is the Distribution Server, a separate component from the WebFOCUS Reporting Server that manages the queuing, scheduling, and delivery of report output. The Distribution Server communicates with the WebFOCUS Repository to retrieve schedule metadata and with the Reporting Server to execute report procedures (FEX files).
A commonly missed architectural point: the Distribution Server calls the WebFOCUS repository during startup to obtain communication parameters. If the Repository is unavailable at startup, the Distribution Server will not start. This dependency means Repository availability is a prerequisite for ReportCaster operations — something that needs to be accounted for in high-availability design.
For high-volume environments, TIBCO supports configuring multiple Distribution Server instances across one or more hosts. The Workload Distribution feature assigns scheduled jobs across those servers, providing parallel processing for large schedule inventories. A Distribution Server Failover configuration, using a synchronized monitoring service, allows a backup server to take over automatically if the primary is interrupted.
Burst Scheduling: One Job, Many Recipients
Burst scheduling is one of ReportCaster’s most powerful capabilities for enterprise report distribution, and one that is frequently implemented suboptimally in legacy environments.
A burst schedule takes a single report procedure and executes it once, splitting the output by a burst value — typically a field like region, department, or cost center — and distributing each segment to a different recipient or group. The result is that a single scheduled job can generate and deliver 50, 500, or 5,000 personalized report outputs without running the report once per recipient.
This matters for performance because a naive approach — scheduling one job per user — multiplies Reporting Server load linearly with recipient count. A burst schedule with 500 recipients is a single execution that produces 500 outputs, not 500 separate executions. For environments with large distribution lists, this distinction is significant.
Burst values and recipient mappings can be defined through static distribution lists stored in the Repository, or through a Dynamic Distribution List that queries a live data source (SQL database, flat file, LDAP, or FOCUS data source) at execution time. The Dynamic Distribution List approach is preferable for environments where the recipient list changes frequently, as it eliminates the overhead of maintaining static lists in ReportCaster.
Security: How ReportCaster Enforces Access Control
ReportCaster is fully integrated with the WebFOCUS Client Security Authorization model. Users, groups, schedules, distribution lists, and access lists are all stored in the WebFOCUS Repository, meaning the same role-based access control that governs who can run which reports also governs who can create, manage, and view schedules.
Distribution methods can be restricted at both the global level (through ReportCaster configuration) and at the user or group level (through security operations). This means an administrator can prevent specific users from distributing to FTP or external email addresses, limiting delivery to the Report Library or internal managed reporting destinations.
The Report Library is particularly important in regulated industries. Reports distributed to the Library are stored in the Repository with access controls, creating an auditable record of what was distributed, when, and to whom. Watch List subscriptions allow authorized users to receive notifications when library content is updated without requiring the content to leave the controlled environment.
For group-owned schedules, ReportCaster runs the schedule as the last user to own it — typically the creator. This ownership model has compliance implications in environments where personnel changes are frequent, as schedules owned by departed users can continue running under that user’s security context. Auditing group-owned schedule ownership as part of regular access reviews is a practice worth formalizing.
Common Configuration Decisions That Affect Production Performance
Trace files. The Distribution Server generates trace files and log files during execution. The default trace setting generates data that is useful for debugging but creates I/O overhead at scale. Configuring the trace level appropriately for production versus troubleshooting environments is a maintenance consideration that often gets overlooked.
Recovery settings. The Recovery parameter in the ReportCaster Server Configuration tool controls how incomplete jobs are handled after a Distribution Server interruption. Configuring this correctly for your environment prevents duplicate deliveries after a failover event.
Purge settings. The Purge Library function controls how long Report Library content is retained. In high-volume environments, library storage can grow significantly without a documented purge schedule. The Delete Schedules function similarly handles nonrecurring schedules that accumulate over time.
Email distribution of HTML reports. Inline email distribution (report content in the email body rather than as an attachment) is only supported for HTML, DHTML, WP, and DOC output formats. Teams that deliver reports to mobile devices or email clients with limited attachment support should design their report formats accordingly.
Conclusion
ReportCaster is a governed distribution engine, not just a scheduler. The architectural decisions around Distribution Server topology, burst scheduling strategy, security ownership, and library policy have direct effects on performance, compliance, and operational sustainability at scale. Getting these right at implementation — rather than retrofitting later — is where the real value of experienced WebFOCUS development services shows up.
Need to optimize or audit your WebFOCUS ReportCaster environment? Prism Analytics provides WebFOCUS development services and support for teams managing complex legacy reporting architectures. Get in touch.