Pre-Processing Data with Report Triggers

You should use the ‘Before report trigger’ functionality, which is configured within the Report Options section. This trigger points to a custom DB Package that contains pre- and post-processing functions. The functions used within this package must follow a specific naming convention: `afterpform`, `beforereport`, and `afterreport`, and they must return the boolean data type. In the specific case of the FA Depreciation Projection report, the Blitz Report references a custom package (e.g., `XXEN_FASPRJ`) that submits and waits for the completion of the standard Depreciation Projection program *before* the main report SQL executes.

The triggers can be used for various data pre- and post-processing activities. For example, the ‘Before report trigger’ can be used for activities such as table data updates that must occur before the extraction SQL is run. Conversely, the ‘After report trigger’ can be utilized for post-execution processing, such as calling standard Oracle PL/SQL code or cleaning up temporary data.

Yes, you can define a custom Unix shell script to be executed after the report completion, typically for tasks like file distribution or transformation. This is configured via the ‘Custom Postprocess’ option found both at the report level and as a runtime option. The script must reside in the `$CUSTOM_TOP/bin/custom/` directory (e.g., `$XXEN_TOP/bin/custom/generate_and_send_pdf.sh`) and is invoked with several run-time parameters, including the report name, request ID, and the path to the output file.

For maximum flexibility and maintainability, it is actually recommended to use `_all` tables and apply security through parameters. Security is implemented by introducing a required parameter, such as ‘Operating Unit’, with a List of Values (LOV) restricted to only the operating units allowed by the current user’s responsibility. This approach allows the database connection to run without having the application user session context fully initialized, making debugging via tools easier.

You can absolutely use Oracle VPD with Blitz Report to control access to sensitive data at the row or column level. Blitz Report provides several objects to manage this, including the lookup `XXEN_REPORT_VPD_POLICY_TABLES` to define the objects to be secured, and concurrent programs like ‘Blitz Report Update VPD Policies’ to activate the policies. However, remember that VPD policies set up this way only secure access through the Blitz Report concurrent program itself, not through direct database access tools.