Skip Headers

Oracle® Argus Safety BI Publisher Periodic Reporting Extensibility Guide Release 8.0 E56916-02 |
| Contents

Previous | Next |

# 5 Design Structure

This chapter contains the following sections:

- Section 5.1, "BI Publisher Periodic Reports Design Structure"

- Section 5.2, "Report Data Flow"

## 5.1 BI Publisher Periodic Reports Design Structure

This section provides an overview of the BI Publisher Periodic Reporting data model and report layout. Oracle recommends you go through BI Publisher guides for more information.

Each report in Argus Safety BI Publisher Periodic Reporting has categories:

- BI Publisher data model comprising parameters and XML file triggers

- BI Publisher Layout templates

- Database package

### 5.1.1 BI Publisher Data Model

The BI Publisher data model comprises:

- The data set for each report

- Event triggers

- Parameters and associated lists

#### 5.1.1.1 Data Sets

Each BIP report has its own data sets. A data set is the XML data file used to generate the report output. Figure 5-1 displays the data set of the Periodic Benefit Risk Assessment Report (PBRER).

Figure 5-1 Data Sets

Each box represents a query that can fill in a group.

#### 5.1.1.2 Event Triggers

The Before data trigger and the After data trigger are the two event trigger types.

The Before data trigger is the starting point of the report after submission. The Before data trigger executes the pkg_agg_rpt.f_before_data procedure. You can customize trigger names per your requirements.

The Before data trigger call to the pkg_agg_rpt.f_before_data package passes the following arguments:

- XDO User name: The user logged in.

- Template ID: 1 represents PBRER, 2 represents PMAR, and 3 represents DSUR.

You can create multiple Before data triggers, and the system executes them in the arranged order.

The After data type trigger fires after the completion of the Before data triggers. OOTB reports call an empty function in this trigger so that the end user can modify the function.

#### 5.1.1.3 Parameters

Parameters are part of the data model. Figure 5-2 displays the parameters of the PBRER.

Figure 5-2 PBRER Parameters

Description of "Figure 5-2 PBRER Parameters"

The data model has the following types of parameters:

- Text

- Menu (list of values)

- Date

Text parameters are the simplest form. If you provide a default value, the system considers it automatically when no value is passed.

Menu parameters are LOVs and are associated with attached queries. For example, the AGENCY parameter is associated with the query in Figure 5-3.

Figure 5-3 Menu Parameters

Description of "Figure 5-3 Menu Parameters"

Argus Safety does not use date type parameters.

Note: The default values take precedence even if there is a value present in the report configuration and you did not select a value during report execution.

You may see many -999999999 values as the default values. Inputting a value of -999999999 would show the -- SELECT -- record on the BIP Parameters screen. When no value is selected, the report tries to fetch any default value present in the report configuration.

For example, for Main Case Series, when the parameter value is not selected and is left at -- SELECT --, the report selects the main case associated with the report configuration.

Enterprise ID and Report Configuration Name are mandatory parameters. The report fails if either of these parameters is not submitted.

### 5.1.2 BI Publisher Report Layout

BI Publisher Periodic Reporting uses Rich Text Format (RTF) for its templates. The layout maps the data sets and displays data at run time. You can also design the data model so the template calls other layouts within itself.

Figure 5-4 displays a portion of the PBRER data model. The report template calls other templates from the Cover and Summary pages.

Figure 5-4 PBRER Data Model

Description of "Figure 5-4 PBRER Data Model"

## 5.2 Report Data Flow

This section explains the flow of data from the time the user creates the report configuration until the report is executed completely.

### 5.2.1 Argus Safety UI Entry

To configure a report, navigate to the Periodic Report Configuration screen and enter the required configuration. The system saves this data in the required configuration tables.

You can either generate the case series or run the BIP report in a single step. A case series is generated in both cases.

For an ICH PSUR configuration, the following case series can be generated:

- Main Case Series

- Cumulative Case Series

- Section 6.2 Case Series

- Ad hoc Case series (1-4) when ad hoc listings are supplied

For a CTPR configuration, only Main Case Series and Cumulative Case Series tables are present.

The case series are stored in the case series tables.

### 5.2.2 BI Publisher Data Flow

If you run the report from the Argus Safety UI directly, the system passes only the Enterprise ID, Report Configuration, Print As, and Reg Report ID parameters. Other parameters are picked up if no default values are provided at the BIP level.

1. Navigate to the BIP report that displays the parameter page.

2. Select the mandatory parameter ENTERPRISE ID.

   This selection executes the associated LOV query.

   The selected value is verified by the query present in the CFG_RPT_AGG_PARMS table for the parameter.

   After verification, the enterprise ID is set for the session.

3. Select the mandatory parameter REPORT_CONFIGURATION.

   This parameter determines whether the report will be in the Data Lock Point (DLP).

   If the case series parameters are not selected, the default case series associated with this report configuration is set automatically.

   This parameter is an LOV and the query present in the CFG_RPT_AGG_PARMS table for the parameter validates the selected value.

4. Input the other parameters, and click Submit.

   This invokes the Before data trigger that calls the f_beforedata function of the pkg_agg_rpt package.

This function:

1. Sets up all parameter values from the BI Publisher to Package variables.

2. Validates whether the mandatory parameters have been supplied.

3. Checks if the user's access has expired.

4. Determines whether the BIP report call is made from the Argus Safety UI or from the BIP console.

5. Handles case, study, or site security.

6. Finds the BIP report job.

7. Inserts records in CMN_REG_REPORTS.

8. Inserts records in PER_RPT_QUEUE and PER_RPT_STATUS.

9. Obtains the default values of all parameters using CFG_RPT_AGG_PARAMS.

10. Determines whether the report is DLP.

11. Populates the data for listedness, drugs, events, event to drugs, and case data.

12. After the case data has been populated, fills in the health authority details and drug names.

13. Sets up the lexical parameters, if any.

14. Based on the persist data common switches, fills in the data for MART tables:

    1. PERSIST_BIP_DATA: whether data from GTT needs to be moved to RM tables.

    2. PERSIST_DURATION: number of days for which the data is to be left at RM tables.

This results in the package filling in the complete data for data sets.

1. After the PLSQL code is complete, the BI report internally generates the data XML, renders the pages, and stores the output in its repository data.

2. The database job calls the pkg_rpt_util.p_fetchrptoutput function, which obtains the list of reports that are run based on the RPT_AGG_BIP_JOB table.

3. The database then queries the BIP Metadata Repository (MDR) and verifies that the report is complete. If the report has failed, the database updates the failure status and proceeds to the next report.

4. If the report is successful, the database checks if the Draft/Final tables are updated.

5. The system copies the report output blob to the reporting tables. It updates CMN_REG_REPORTS and the corresponding records in the PER_RPT_QUEUE and PER_RPT_STATUS tables.

After this operation is complete, you can view the report output in BIP and Argus Safety.

Note: The report output in BIP might be completed earlier than in Argus UI. This is because the job picks up the output and pushes it to the Argus database.