Screen Configuration

Screen Business Rules

Out of the box, the pages of the OIPA web-based user interface only implement generic functionality that is deemed to be of value to a cross-section of insurers. The pages can be customized through business rules to meet specific insurance product needs. The business rules are created and maintained by the Oracle Insurance Rules Palette in XML format and considered a part of a custom implementation, along with transactions and other configuration.

Business rules that govern the content, look and behavior of pages are called screen business rules. The screen rules provide a wide variety of features that allow customizing pages to meet client-specific needs.

A comprehensive set of input components: text, date, currency, drop-down combo-box, radio button, and so on.

As with other business rules, screen rules can be set up so that pages look and behave differently for different products and jurisdictions.

The above diagram illustrates the concept of the page configuration. A screen business rule is used to create a set of fields that are displayed on a page. A set of Java classes, generated at run-time and based on the rule's logic, is responsible for handling screen events – page load, page submit and field value changes.

Converting the rule logic from XML to Java classes does away with the inefficiencies of an interpreted language like XML and replaces it with the compiled efficiency of Java, improving system performance. Furthermore, when the system has to parse the same screen rule again, it recognizes the existence of a generated class and uses it, instead of regenerating the class.

When the user performs an action to save the information entered on the screen, the configured validation in the screen rule is invoked. Only after the screen rule configuration confirms the validity of the data does the system persist information to the database.

Configurable Dynamic Fields

Configuring the pages of the OIPA application with client-specific rules essentially customizes the application data model to satisfy customer's business requirements. The base application data model is extremely flexible and can be extended as required for a particular client implementation.

Only a few generic data fields, known as fixed fields and shared between all client-specific implementations, are stored by default in the application database. Fixed fields are represented as columns in the database tables. The dynamic fields that are configured through the screen business rules as described in the previous section are stored in the tables with names that have a suffix of Field (As<EntityName>Field). A value of a configured field of a business entity is stored in its own row in the corresponding Field table:

The above example shows a screen rule for a hypothetical business entity called Entity. Some business entity examples are Policy, Client, and Activity. The rule specifies that the Entity has two dynamic fields. The Entity's fixed attributes are stored in one row as column values in the AsEntity table. The AsEntityField table stores dynamic fields, one value per row, that match the configuration in the Entity screen business rule. Each row contains a GUID of a parent entity, field name, field data type, and value that is stored depending on field's data type.

This approach to data configuration and storage enables clients to extend the application data model without affecting the database schema. This not only makes database administration easier but also reduces the effort required to upgrade, because schema changes made in the core product with new releases will not conflict with changes made by clients.

 

 

 

 

 

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. About Oracle Insurance | Contact Us