Generating Reporting Views

Introduction

The Reporting View Generator works similar to a Base Views generator based on the existing tables of the running application.

  • For example, when running this generator from the Policies application it generates Base Views for the Policies table, the same logic applies for Reporting Views as well per application.

  • Base view is generated one to one with the OHI tables, after joining with translation tables, while reporting views are built keeping business needs in mind by combining multiple tables.

This page describes the process of how these views are generated.

These reporting views are seeded. It is required to generate the reporting views to resolve dynamic fields in the seeded reporting views.

Naming of the Views

The view names adhere to the following conventions:

  • Starts with the abbreviation of the application name the view is stored in, for example, POL, CLA.

  • To distinguish Base Views from Reporting Views, REP is added after the application reference.

  • The third part is a reference to the purpose of the view, for example, POLICIES_IN_PROGRESS, CLAIMS_IN_PROGRESS.

  • The name ends with _VW to indicate that this is a view.

  • The entire name is written in capitals and words are separated by an underscore.

    • For example: POL_REP_POLICIES_IN_PROGRESS_VW.

Supporting Entities

Reporting Views

  • The Reporting Views table contain all the views, both the Base Views as the Reporting Views.

  • Entries for the Base Views are generated by the Base View generator, and entries for the Reporting Views are seeded.

  • A Reporting View entity has an indicator (uiReporting) whether the view is meant for reporting or not.

View Columns

  • The View Columns table contains an entry for each column of either a Base View or Reporting View.

  • Entries for the Base Views are generated by the Base View generator, and entries for the Reporting Views can either be seeded or generated.

    • The Reporting Views contain single valued dynamic data, hence entries for those columns are added by the generator.

    • Fixed columns are seeded. A View Column entry has an indicator if the column is representing dynamic data or not.

Metadata IP

For UI display, the metadata of the Reporting Views needs to be fetched.

To do this, invoke with a GET operation call the /{reportingViewCode}/metadata endpoint to the Reporting View IP.

This IP fetches the Reporting View based on the path parameter. For this view all the view columns are fetched and a JSON is created containing the following information:

  • Column name

  • Column data type, which can be

    • String,

    • Date,

    • Number,

    • Boolean,

    • Amount,

    • Array

  • Indicator if the column is searchable

  • Additional properties of the column

    • These properties are only filled if the data type is Array or Amount.

    • In case of Amount, the properties reflect that this field contains both a currency and a value.

    • In case of Array, the properties reflect the fields that are reflected in that Array.

    • An Array always represents a JSON value and thus contains multiple fields.

    • The content of the properties field is seeded in case of an Array data type.

Authorization

This API requires a grant for access restriction operationalReporting IP.