Event Based Reporting - Concept for best utilizing the BO events

[Former Member]

In our daily Business Objects reports scheduling life, we often use events as a key factor for triggering the BO Reports. Data quality can be obtained by fixing the events as a dependency to a BO Report. If I'm not wrong, almost everyone who uses Business Objects follow this event dependency concept to maintain the quality of data in the reports. What else, we can play with those events??...

I thought of sharing on how well we can utilize the BO events for Load balancing, Data quality and Maintenance activities.

Basically, events are classified into 3 types.

1. Custom Event - Occurs when you explicitly clicks its "Trigger this event" button.
2. File Event - Waits for the particular file to generate in the desired location to trigger the event.
3. Schedule Event - Triggers the event, when a particular object has been processed.

To know more about events, read Page#229 in Admin guide.

Load Balancing:

Rudiments:

Dummy Reports - 3 or 4 Reports*

Schedule Events - 3 or 4 Events*

Priority events can be created to maintain the load balancing on BO servers. By creating these events, the reports will be kicked off based on the criticality. The four dummy reports which we have created will be executed every 1 min* and triggers the corresponding schedule events.

Here, we can name those 4 dummy reports as Priority1_Report, Priority2_Report, Priority3_Report and Priority4_Report.

Name those 4 schedule events as Event_P1, Event_P2, Event_P3 and Event_P4. (Fix the events as a OUT Conditions for corresponding Priority reports)

The Priority events will be fixed as a condition to all the BO Reports based on the start time of the reports. For example,

Event Names	Fixed to the reports
Event_P1	Scheduled to start between 8 AM -10 AM
Event_P2	Scheduled to start between 10:01 AM - 11:30 AM
Event_P3	Scheduled to start between 11:31 AM - 1:00 PM
Event_P4	Scheduled to start after 1:01 PM

How these events can be used?

• Pause these Priority Reports when there is a delay in the data load or any other issues to avoid reports kicking off at the same time.
• Once the data load process got completed or any other issues are fixed, release the "Priority1_Report" first to generate the critical reports depends on Event_P1.

• Release the "Priority2_Report" after 30-45 mins* after confirming that there are enough resource available for processing the next set of reports. By this time, most of the P1 reports might have completed.

• Release the "Priority3_Report" and "Priority4_Report" reports after 30-45 mins* respectively by checking the number of reports in RUNNING state.

Maintenance Activities:

I divide this module into 2 segments.

1. Maintenance on BO Server
2. Maintenance on Data load server (DB)

For Maintenance on BO Server, Rudiments:

Dummy Reports - 1 Report

Schedule Events - 1 Event

To avoid report failures or to stop all the BO reports from kicking off, we can have this one dummy report to manage all these actions. The dummy reports which we have created will be executed every 1 min* and triggers the corresponding schedule events.

Here, we can name that 1 dummy report as Allow_All_Reports.

Name the schedule event as Event_AllowAll. (Fix this event as a OUT Conditions for "Allow_All_Reports" reports)

How this event can be used?

• Make this event event as a mandatory event while scheduling a report.
• This event is going to be the key for BO Reports to stop or kick off.
• Incase of any issues, if you don't want your reports to trigger and to avoid the report failures, you can go-ahead and pause one single report "Allow_All_Reports" to control all other scheduled reports on your environment.
• Once the issues are resolved, you can resume this "Allow_All_Reports" to allow all the reports to kick off.

Note - If you pause this report by mistake then none of your reports will trigger.

For Maintenance on Data Load Server (DB), Rudiments:

Dummy Reports - 3 or 4 Reports*

Schedule Events - 3 or 4 Events*

To avoid report failures or to stop all the BO reports which are hitting specific database during planned or unplanned maintenance on data load servers (DB), we can have these dummy report to manage all these actions. The dummy reports which we have created will be executed every 1 min* and triggers the corresponding schedule events.

Here, we can name that 3 dummy report based on the DB Names like DB1_Report, DB2_Report and DB3_Report.

Name the schedule event as Event_DB1, Event_DB2 and Event_DB3. (Fix these event as a OUT Conditions for respective DB Event reports)

For example, Consider DB1_Report is scheduled for Oracle DB reports. Then, fix the Event_DB1 as a in-condition for all the reports which are hitting the Oracle Database. Incase of any unplanned maintenance or any issues with the database, we don't have to look for the metadata or identify the list of reports hitting the Oracle DB and pause them manually. All you need to do is, go-ahead and pause the DB1_Report which will in-turn hold all the reports which are hitting the Oracle DB since we have scheduled those reports with DB Event conditions.

Event Name	Reports hitting ...
Event_DB1	Oracle Database
Event_DB2	SQL Database
Event_DB3	Teradata

Data Quality:

The Quality of data in the report can be maintained by fixing any of the 3 events (Custom, Schedule or File events). Based on the ETL jobs which loads the data to the tables used by the reports, we can fix the best event type as a condition to the BO Reports.

• If ETL jobs are generating any trigger files after processing the data, file event can be fixed as a condition to all those reports which are using the tables loaded by that particular ETL job.
• Custom Event can be used to kick off the reports, once the specific table got loaded.
• Scheduled event will be acting as a WATCHER Reports to monitor the status of ETL job. Based on the completion of ETL job, instance will be successful and triggers the corresponding event.

To Summarize:

While scheduling any reports, plan to fix the below events as a dependency to maintain the quality of data, load balancing and to avoid report failures or to pause \ resume any reports during planned \ unplanned maintenance period.

Event to wait for:  Event_AllowAll, <<Priority Event>>, <<Database Event>>, <<Data Load Event>>

1. Event_AllowAll - Default event which should be fixed as a dependency for all scheduled reports. Pausing this report will hold all the reports in your environment.
2. Priority Event - Should be fixed based on the scheduled start time of the report. Helps in Load balancing during loads delay or any other issues.
3. Database Event - Fix this dependency based on the database the report is running against. Helps to pause \ resume the reports during maintenance period or any DB issues.
4. Data Load Event -Based on the ETL process, fix the best suitable event for ensuring the data quality.

Points to be noted:

• No DB connections are required for the dummy reports which has been created for load balancing and maintenance.

• As these reports are not hitting any DB's, instances will complete in few seconds.

• Place these event reports in a separate folder and maintain security level in such a way that only Administrators can Pause \ Resume these reports. (Customize your security levels based on the requirement)
• Fix the report LIMITS as 10.
• These event reports will be acting as a one stop location where you can control almost all the reports which are scheduled in your environment.

*Based on business requirements.

I welcome the feedback, comments and complements.

Thanks

Vijay Madhav