OIRP Release Notes

Oracle Insurance Rules Palette Release Notes

The Oracle Insurance Rules Palette is a standalone application that can be used in conjunction with Oracle Insurance applications. The Rules Palette allows users to create and configure business rules that support their business process model. Plans hold related policies that share a set of business rules, plan rules, requirements, transactions, segments, plan data and plan values. Copybook functionality enables transactions and business rules to be used across multiple plans, leveraging existing information and reducing configuration time.

These release notes contain the enhancements made to the Oracle Insurance Rules Palette as part of the Oracle Insurance Policy Administration GA release 11.3.1.0.

Customer Support

If you have any questions about the installation or use of our products, please visit the My Oracle Support website: https://support.oracle.com or call (800) 223-1711.

Oracle customers have access to electronic support through My Oracle Support. For information, visit:

http://www.oracle.com/us/corporate/accessibility/support/index.html#info or http://www.oracle.com/us/corporate/accessibility/support/index.html#trs if you are hearing impaired.

Enhancements in the Oracle Insurance Rules Palette

This section describes the enhancements made to the Oracle Insurance Rules Palette:

Downstream Message Push using the JMS and SOAP Protocols

PushNotifications BR

PushNotifications attached business rule is introduced to push event-based notifications to the downstream applications via JMS or SOAP protocols. The rule can be configured to push appropriate messages to the downstream on "Successful Activity Processing or when an Activity Processing Fails (OnTransactionFailure)" after the activity processing is complete and before committing the persisted data to DB. The <PushNotifications> may include multiple <PushNotification> for each event, which can be triggered for a particular EVENTNAME that is defined as <Event> in DownstreamMessagePushDefinition rule for JMS/SOAP.

The rule can be overridden at Activity Plan, Activity Policy, Activity Client, Activity Company and is applicable for all activity types. PushNotifications BR uses custom-built expressions to construct the required event-based messages. Message templates can be created using Jelly expressions.

For more information, refer

DownstreamMessagePushDefinition for JMS/SOAP BR

DownstreamMessagePushDefinition rule is introduced to define message delivery to the downstream applications using JMS/SOAP protocols. This system rule contains the destination addresses, events, and the protocols using which the messages to be delivered to downstream applications using the PushNotifications BR. A user can configure messages for one or multiple events and map each event that has one or more messages to different downstream applications. When there are multiple messages defined for an event, the system validates a condition, and delivers appropriate messages.

The rule can be configured for different event environments such as Test, Prod, and Dev. The rule can be overridden at Primary Company level and Plan level.

Event environment that needs to be used by the rule should be defined in PAS property downstream.service.event.mode such that all the events use the same environment across the system. Different end points can be defined for each event environment for a given event.

The rule supports to configure asynchronous SOAP calls, if the PAS property InvokeOneWay is set to True. For asynchronous SOAP calls, OIPA pushes the message and does not wait for acknowledgment from the downstream.

For more information, refer:

MathVariable Element

MathVariable element is expanded to support a new MathVariable type. A new MathVariable type DATE is introduced to support Date format generation and conversion. When a MathVariable is configured in a transaction with this Date format, it returns a date format string as specified in TOFORMAT. For example, this enhancement enables to configure the date formats to push event-based notifications on activity processing to the downstream applications.

  • If a MathVariable TYPE=DATE and DATATYPE= FORMATDATE, OPRERATION=GENERATE, it generates the system Date/timestamp in a format specified in TOFORMAT
  • If a MathVariable TYPE=DATE and DATATYPE= FORMATDATE, OPRERATION= CONVERT, it converts the defined time into a format specified in TOFORMAT

For more information, refer MathVariable Element

Transaction Element

The Transaction element is modified to include a optional attribute PROCESSBYCYCLE, which allows a configuror to define whether the activities should be processed by Cycle or OIPA processing engine. The configuror can set the attribute's value to either “Yes/No”.

If the value is set to “Yes”, all the activities with an Effective Date less than or equal to the current system date are passed to the Cycle Agent for processing. If the value is set to “No” (default value) or when no value is provided in the configuration, the transaction is processed with the current behavior (activities are processed by OIPA from its UI).

For more information, refer Transaction Element

ClientRoleScreen BR

The ClientRoleScreen business rule is extended with a new optional element <ApplicationRole>. The configuration of this element controls the display of the Application Roles tab in OIPA, if the ClientRoleScreen business rule is configured with <ApplicationRole SHOW="Yes">. For security,

a new button for ApplicationRole is added under Company Security/Company Pages/Client Role to show or hide the ApplicationRole tab in OIPA.

For more information, refer ClientRoleScreen

VerificationScreen BR

Currently in the VerificationScreen rule, when the SHOWORIGINAL attribute under <Allocations> is configured with a value "Yes", the original and final fund allocations are displayed and when the value is "No", the screen displays only the final allocation. Now, the VerificationScreen rule provides the ability to hide/display original and final fund allocations based on a MathVariable value when the VerificationScreen business rule is attached to an activity. The SHOWORIGINAL attribute in the rule can be configured to accept a MathVariable value, which defines the displaying of original and final fund allocations in the VerificationScreen.

For more information, refer VerificationScreen

ActivityResultsScreen BR

Currently when an activity is executed, the ActivityResultsScreen displays the fund allocation details based on the MathVariable or field data available in the persisted activity data. If the value of SHOWORIGINAL is "Yes", both final and original allocations are displayed. If the value is "No", only final allocation is displayed on ActivityResultsScreen.

Now, the ActivityResultsScreen rule provides the ability to hide/display original and final fund allocations based on a math variable value passed from the SHOWORIGINAL attribute, when an activity is executed.

For more information, refer ActivityResultsScreen

CreateClients BR

The CreateClients business rule is enhanced with an ability to add phone records and attach them to Client or Addresses through an activity. It allows the user to add a phone record while creating a new Client through CreateClients BR and attach the phone record to the Client and Client address.

For more information, refer CreateClients

CreatePhones BR

This new attached business rule is introduced to add a phone record to existing Client and Client address. It allows the user to add a phone record to the existing Client through CreatePhones BR and attach the phone record to the Client and Client address.

For more information, refer CreatePhones

MaintainBillDetail

Currently, the group-billing feature allows OIPA to generate a bill with multiple details through generation business rules attached to multiple activities. This enhancement allows revoking a payment and its subsequent bill detail reconciliations. The user can add an activity at current Effective date (not a payment date) to reverse the effects of the payment. It provides the ability to move the bill detail statuses from RECONCILED to BILLED.

In the existing functionality, the "MaintainBillDetail" business rule is used to update of the Bill Detail record status using the below elements:

<ShadowBillDetail>Yes|No</ShadowBillDetail> (if yes Bill Detail status is changed to SHADOW)

<ReconcileBillDetail>Yes|No</ReconcileBillDetail> (if yes Bill Detail status is changed to RECONCILED – one record)

<ReconcileBillDetailCollection>collection</ReconcileBillDetailCollection> (All identified Bill Detail statuses are changed to RECONCILED)

The functionality has been expanded to allow updates to any Bill Detail Status through a new tags <UpdateBillDetailStatus> or <UpdateBillDetailStatusCollection>. The rule supports the "Pending, Billed, UnderRecon/Shadowed" statuses of the bill.

For more information, refer MaintainBillDetail

External Links / Deep Links

Currently, OIPA supports configurable External/Deep links to access third party client applications such as Accounting Management Systems, Document Management Systems (DMS), other External Systems or any other web page that operate outside and independent of OIPA.

Now, when a user configures either Deep Links / External Links business rule with external links that should be accessed from OIPA, the system validates the configured sites/URLs and allows only approved or allowed domains to be configured by the configuror. The list of allowed domains that can be used for configuration are maintained in the ASALLOWEDDOMIN table.

For more information, refer

Display Multifield Rows Based on User Interaction on OIPA Screen

Currently, Multifields business rule allows a user to configure a set of one or more, or a range of fields to be displayed on OIPA screens that support the Multifields rule. The configuror can define the number, or a range of fields between the <Start> and <End> tags in the Multifield configuration that are needed to be displayed on an OIPA UI. This limits the configuror to define the number of fields between the <Start> and <End> tags appropriately in advance (the fields that may be needed by the CSR to enter data), as the count of repeating fields required are dependent on the set variables, fields, or derived values on the OIPA screen.

With this enhancement, OIPA has the ability to dynamically display the number of repeating fields, based on evaluated expressions, or a set of variables on the basis of user interaction on OIPA Screens in which the Multifields rule is configured. Based on the user's interaction with the OIPA Screen, the system dynamically generates and displays the number of Multifield indices on that particular screen.

The configuror can configure an auxiliary field in the Multifields rule in an associated transaction, which is used by the system to dynamically assign a value for <Start> and <End> tags to generate the specified number of fields. The functionality of this enhancement is limited to the Activity screen, but is not limited to any specific type of event.

For more information, refer Multifields

Configurable Web Services

CycleService - SubmitTask REST Service APIs

The CycleService REST API is introduced to support the transfer of activity processing from OIPA to the Cycle Agent. A user can configure this service in a transaction to allow cycle processing from OIPA. When a PROCESSBYCYCLE attribute value in a transaction is configured as "Yes", the OIPA allows the users to send the SubmitTask service request to the Cycle for activity processing. When a user sends a SubmitTask request to the Cycle Service, all the activities with an Effective Date less than or equal to the current system date are submitted to the Cycle Agent for processing. The REST service, CycleService is created in the AsAuthWebService table with SubmitTask as a webservice method.

For more information, refer CycleService

Allowed Domains - REST Service APIs

Allowed domains REST APIs are introduced to create and manage secured domains (external sites/URLs) in OIPA. A user can use these REST services to add/retrieve/modify/remove the allowed domains in the ASALLOWEDDOMIN table. The configuror can use these valid domains (secured domains) maintained in the ASALLOWEDDOMIN table, to configure in the Deep Links or ExternalLinks business rule that are used to access the third party applications/systems from OIPA.

For more information, refer Allowed Domains

Rules Palette Enhancements

Access Stack Trace in a Secure Way and Implement User Friendly Error Messages

Currently, stack traces are thrown in OIPA user interface (UI) for all the exceptions that may occur while the system is accessed by different users such as business users and configurors, or technical engineers that operate OIPA. Now, OIPA provides a secure way of accessing stack traces on UI by restricting specific user roles such as business users to view or access the stack trace through security groups.

A new node ShowStackTraces is added in the security section of Admin Explorer for page security in Palette to support all stack traces access for specific user roles. The button Show Stack Traces can be enabled for the configurors or other technical engineering users to allow access for the stack traces.

  • When this option is configured, only the Admin or users with specific roles that have security defined are allowed to view and access the stack trace information with possible Error Cause and Fix Tips to debug/troubleshoot various system/configuration/data errors generated during the runtime.
  • With the stack trace access restriction, OIPA displays only user friendly error messages to the business users on any exceptions/errors that occurs while activity processing, or in case of any configuration errors, or any system errors.

For more information refer,

Rules Palette Opens Up an Entry for State Override with the Selection of the Product

Currently, the business rules at the state level can only be overridden with the combination of a Plan or a Subsidiary Company. Now with this enhancement, the business rules in the policy context can be overridden at the Product-State level. OIPA recognizes the possibility of a business rule override at the Product-State level using the best match logic.

  • When a business rule is overridden at the Product-State level, OIPA implements the functionality as per the configuration defined in the Product-State override. For example, if EligibleTransactionByPolicyStatus(ETBPS) rule is configured at the Product-State level, then ActivityScreen in OIPA shows all the eligible transactions as per the override defined in its configuration.
  • When a business rule is overridden at a more specific level than the Product-State level, for example, with the combination of Plan-State level, OIPA implements the same functionality the way it is now currently as per the configuration defined in the Plan-State override level.

This enhancement is available only if the functionality of Products is enabled in the OIPA system properties file. Otherwise, the products are listed as plans in the Plans dropdown and the user can make plan-state override.