Dynamic Logic Overview

Oracle Insurance Gateway provides a facility to express certain behavior in an object-oriented language. These modules (code snippets) are invoked at particular moments, during data collection, transformation, invoke process, subflows and data output steps.

The language in which Dynamic Logic modules are written is Groovy. Groovy is a language that is closely related to Java. This manual will not elaborate on the language itself. There are many books and online resources available for this purpose. Dynamic Logic modules can easily be tested in an IDE such as Eclipse, or on a web page such as http://groovyconsole.appspot.com/. It can be difficult however to emulate the application environment in a standalone editor. Therefore, a full test should always take place in the flow in which the module is used.

Two types of Dynamic Logic are distinguished: conditions and functions. A condition operates on one or more objects and returns a boolean. A function operates on one or more objects and returns a value.

All types of dynamic logic can embed a call to an external service. This call out is also explained in a separate chapter.

Each piece of dynamic logic adheres to a signature. The signature describes both the functional usage (wherein the configuration is it used?) and the technical usage (which objects are available in the Groovy code and what is the expected return value?). The following is a list of all existing signatures per logic type.

The following condition signatures exist:

  • Step Invocation Check

The following function signatures exist:

  • Data Collection Custom

  • Data Transformation Payload

  • Parameter Extraction

  • Step Post Process

  • Invoke Function Payload

  • Error Payload

  • Extension

  • Subflow

  • Notification Payload Extractor

  • Reusable Code

Inbuilt Time Out

Writing Dynamic Logic incorrectly, can impact the performance and stability of the system. One of those specific implications concerns managing long-running processes or resources logging by mal-formed units of dynamic logic. The framework plugs-in a TimedInterrupt in every dynamic logic. The value of the timeout is governed by two properties:

Property Name

Data Type

Default Value

Description

ohi.dynamiclogic.timeout

integer

300

The global maximum time a unit of dynamic logic can run before the process monitor will interrupt the thread. The value is in seconds, and the default is 300 seconds.

ohi.dynamiclogic.timeout.<CODE>

integer

N/A

This is a dynamic property. <CODE> matches the code of the unit of dynamic logic, and will override the default time out for that unit of dynamic logic.

If the timeout expires, the system interrupts the dynamic logic and throws a timeout exception with code OHI-DYLO-008 and message Dynamic Logic with code {code} timed out on line number {line number}: {exception message}.

Please note that when the dynamic logic timeout property is added/updated, the dynamic logic(s) need to be recompiled for the property change to take effect. This can be done by using the "Invalidate Dynamic Logic Integration Point" explained in the Developer Guide.

Considerations When Writing Dynamic Logic

Writing Dynamic Logic incorrectly can impact the performance and stability of the system. So when writing Dynamic Logic, make sure to:

  1. Understand the use case where the logic is going to be used to judge what is and is not acceptable.

  2. Avoid costly operations.

Costly operations are :

  • Logic that results in a database query. A database query involves network communication and processing on another machine, so this is the most expensive operation in general. Note that a domain method potentially may result in a database query as well.

  • Extensive looping over large number of objects.

  • Carefully assess the impact of the logic on system performance and stability. This can be done by running a performance test with and without the new/changed logic in place. Test the script (in a test environment) with "timing.dynamicLogic" switched on (see below).

Enable Time Logging of Dynamic Logic Execution

This can be enabled using the log level "trace" for the logger "timing.dynamicLogic":

<logger name="timing.dynamicLogic" level="trace" />

Each dynamic logic execution will now be written to the application log files.

2018-08-02 12:05:02,234 ... TRACE timing.dynamicLogic - NAFMDFLT 0.042289 ms
2018-08-02 12:05:02,280 ... TRACE timing.dynamicLogic - ORGDYNREC1 0.267327 ms
Only enable this in test or development environments, as this will impact performance.