Predefined Methods
This section describes the predefined methods available per object. These are available along with the methods described in other chapters for Event Store and Transformation.
Generic Methods
This section describes generic methods that are available in any Dynamic Logic.
addDynamicRecord
Adds a new dynamic record to an object.
If the record’s usage is configured as time-valid, then the record supports two additional attributes. They are startDate
and endDate
, of which the former is mandatory.
- Availability
-
This method is available for all objects that support dynamic records. It is available for functions, but not for conditions.
In or Out | Type | Description |
---|---|---|
In |
String |
The usage name |
In |
Map |
The attributes of the record, structured as name and value pairs |
- Example: Add a Non-Time-Valid Record
-
The following logic adds a non-time-valid record:
person.addDynamicRecord( "occurrence" , [ code : "06" , description : "Crime victim" ] )
- Example: Add A Time-Valid Record
-
Add a time-valid record in the same manner, except the map contains two extra attributes:
person.addDynamicRecord( "dynRecord1" , [ code : "06" , description : "dynRecord 1 value 6" , startDate : person.dateOfBirth , endDate : person.endDate ] )
deleteDynamicRecord
Deletes an existing dynamic record. If a key attribute is configured on the record’s definition, then the second input argument can delete a dynamic record with a specific key value. If no record with a matching key value is found, nothing is deleted. If multiple records match with the input key value, only one record is deleted. If the input key is NULL, or if no key attribute is configured at all, then all associated dynamic records are deleted.
- Availability
-
This method is available for all objects that support dynamic records. It is available for functions, but not for conditions.
In or Out | Type | Description |
---|---|---|
In |
String |
The usage name |
In |
String |
The record’s key attribute value, or |
- Examples
-
Assume an existing person has the following three values for the
dynRecord1
record. This dynamic record has two attributes:code
anddescription
, wherecode
is configured as the key.
Code | Description |
---|---|
01 |
dynRecord1 value 1 |
02 |
dynRecord1 value 2 |
03 |
dynRecord1 value 3 |
The following logic deletes the record with code 02
while leaving the other two records intact.
person.deleteDynamicRecord("dynRecord1", "02")
The following logic deletes all three occurrences in records.
person.deleteDynamicRecord("dynRecord1", null)
getSequenceNumber
Allows retrieval of a unique number from a user-defined sequence.
Passes the Code of the user-defined sequence.
Note that it is important to configure the sequence via the /usersequences
resource before using it.
In or Out | Type | Description |
---|---|---|
In |
String |
Code of the user-defined sequence |
- Example
batchNumber = getSequenceNumber("batch_sequence")
Oracle Insurance Gateway provides an event store to store opaque events coming from applications stored under a specific event type or topic. This section describes the predefined methods available to consume such events.
getSystemProperty
Returns the value of the property with the passed key as input.
- Availability
-
This method is available in the dynamic logic (Groovy script).
In or Out | Type | Description |
---|---|---|
In |
String |
Key of the property |
Out |
String |
Value of the property |
Validations: It is also possible to validate an XML payload against a XSD Schema please refer Validation from XSD for details. |
lookUpFlexCode
Returns the flex code object that matches the input character string.
- Availability
-
This method can be called without a base object.
In / Out | Type | Description |
---|---|---|
In |
String |
Key value of the flexCode |
In |
String |
Definition code of the flexCode |
Out |
flexCode |
The flex code |
- Example
person.dynamicFieldYesNoIndicator = lookUpFlexCode("YES", "YES_NO")
test
A method that tests a dynamic logic:
-
Follows the security restrictions of the unit under test (UUT).
-
The application sets the transaction to rollback only. Any data changes to the database are temporary.
- Availability
-
This method is available for a Dynamic Logic (Groovy script).
In or Out | Type | Description |
---|---|---|
In |
|
Dynamic logic Code of the UUT |
In |
|
Map with the input parameters of the UUT |
Out |
|
Contains the result of the test and the exception class if the test encounters any errors. Attributes of this object are:
|
- Example
def result = test("SPECIAL_BENEFIT_SELECT", [
"claim" : claim
])
updateDynamicRecord
Updates the attributes of an existing dynamic record. To find the correct record to update, match on the record’s key attribute value. If none of the existing records have a matching key value, nothing is updated. If multiple records match with the key value, only one of them is updated. If no key is configured at all, executing this method results in adding a record. This applies to both non-time-valid and time-valid dynamic records, so time-validity does not play a role in finding the record to update.
Only the attributes that are present in the input map are updated. Attributes that are not mentioned are left untouched.
- Availability
-
This method is available for all objects that support dynamic records. It is available for functions, but not for conditions.
In / Out | Type | Description |
---|---|---|
In |
String |
A usage name. |
In |
Map |
The attributes of the record, that can have a structure of name or value pairs. |
- Example, Update a Multi-Value Record
-
Assume an existing person has the following three values for the
dynRecord1
record. This dynamic record has three attributes:code
,description
, andlevel
, wherecode
is configured as the key.
Code | Description | Level |
---|---|---|
01 |
dynRecord1 value 1 |
3 |
02 |
dynRecord1 value 2 |
7 |
03 |
dynRecord1 value 3 |
12 |
The following logic updates the level
of the record with code 02
from 7
to 6
. Its description
is retained.
person.updateDynamicRecord( "dynRecord1" , [ code : "02" , level : 6 ] )
- Example: Update a Time-Valid Record
-
Update a record’s start and end date attribute in the same way as other attributes. Assume an existing person has the following two values for the
dynRecord1
record. Besides,startDate
andendDate
, this time-valid dynamic record has two attributes:code
,description
, wherecode
is configured as the key.
Code | Description | StartDate | EndDate |
---|---|---|---|
01 |
dynRecord1 value 1 |
2015-01-01 |
2015-12-31 |
02 |
dynRecord1 value 2 |
2016-01-01 |
The following logic sets the endDate
of the second record to the person’s end date. Its other attributes are retained.
person.updateDynamicRecord("dynRecord1" , [ code : "02" , endDate : person.endDate ] )
Event Consumption Methods
Whenever the system invokes any dynamic logic, it can obtain an eventReader
.
reader = eventReader("topic-1")
The above code snippet shows how to obtain an event reader to read events stored under event type 'topic-1'.
The dynamic logic infrastructure takes care of managing the resources that are used while reading from the events from this event type.
As the number of events can be quite large, an event reader exposes the results in a scrollable fashion to prevent memory exhaustion.
Every event that is read through this event reader will be automatically flagged as having been read/consumed.
Once the dynamic logic is complete, the resource supporting the reader is automatically closed.
Typically, operate on the scrollable event stream using standard dynamic logic idioms as shown in this example.
reader = eventReader("topic-1")
reader.readEvents().each { it ->
exchangeStep.addLogEntry(it.payload)
}
This flagging happens in the same transaction as the reading. This means that, in case an unhandled exception occurs, none of the previously read events are flagged as having been read. This might have consequences when structuring the exchange. This especially holds true when performing a callout to other systems using REST for instance. These operations should then typically be performing their actions in an idempotent way, so that repeated operation using the same information yields the same result. |
Data Structure of Objects Returned by eventReader
The eventReader can be operated on using standard dynamic logic idioms. The scrollable event stream returns objects of type IntegrationEvent that have the following shape.
Field | Description |
---|---|
eventId |
the primary key of the event |
type |
the type of the event (aka topic) |
integrationCode |
the identification of the integration which was in context of the read (aka consumer) |
payload |
the payload of the event |
timestamp |
the timestamp of the event |
correlation |
the correlation of the event |
The methods supported by the eventReader
are:
readEvents()
Reads all the events in streaming fashion for event type.
Parameters
In / Out |
Type |
Description |
Out |
EventScrollableCursorAdapter (subclass of org.eclipse.persistence.queries.ScrollableCursor) |
A stream of events for the passed in event type. |
- Example
reader = eventReader("topic-1")
reader.readEvents().each { it ->
exchangeStep.addLogEntry(it.payload)
}
readEvents(startDateTime, endDateTime)
Reads all the events in streaming fashion for the event type, within startDateTime and endDateTime.
Parameters
In or Out |
Type |
Description |
In |
Timestamp (Optional) |
If present, the creation date of the event should not be before this timestamp |
In |
Timestamp (Optional) |
If present, the creation date of the event should not be after this timestamp |
Out |
EventScrollableCursorAdapter (subclass of org.eclipse.persistence.queries.ScrollableCursor) |
A stream of events for the passed in event type and falling in the range of the timestamps. |
- Example
import java.time.LocalDate
import java.sql.Timestamp
LocalDate now = LocalDate.now()
LocalDate tomorrow = now.plusDays(1)
timeStampStartOfDay = Timestamp.valueOf(now.atStartOfDay())
tomorrowAtEight15PM = Timestamp.valueOf(tomorrow.atTime(20,15))
reader = eventReader("junit")
reader.readEvents(timeStampStartOfDay, tomorrowAtEight15PM).each { it ->
exchangeStep.addLogEntry(it.payload)
}
readUnhandledEvents()
This method checks for the last exchange that read events of this type and same integration using the consumption tracking entity; ExchangeEvents. All events that are not in the ExchangeEvents for the same type and integration are retrieved by this method.
- Availability
-
This method is available generically in all the dynamic logic.
Parameters
In or Out |
Type |
Description |
Out |
EventScrollableCursorAdapter (subclass of org.eclipse.persistence.queries.ScrollableCursor) |
A stream of unhandled events for the passed in event type |
- Example
reader = eventReader("topic-1")
reader.readUnhandledEvents().each { it ->
exchangeStep.addLogEntry(it.payload)
}
Object Methods
In this section, the methods are described that are only available on specific objects. For each method, the following information is given:
-
The purpose of the method.
-
On which objects the method can be called.
-
Description of the parameters.
-
An example of the usage.
addLogEntry
The addLogEntry method can be used to add a log statement for an exchange step. The logs entered through this method are marked with log type as "User".
- Availability
-
This method is available on ExchangeStep object.
Parameters
In or Out |
Type |
Description |
In |
String |
The log entry |
- Example
exchangeStep.addLogEntry("The transformation for Person A was not okay as details are not sufficient");
addResponseHeader
The addResponseHeader can be used to add response headers which are then automatically included when calling an external service or when returning the response for an Exchange that is executed in a synchronous/blocking fashion.
- Availability
-
This method is available on ExchangeStep and
headers
object.
The headers object is only available at exchange creation time when the integration is configured to perform parameter extraction through dynamic logic.
|
Parameters
In or Out |
Type |
Description |
In |
Key as String |
Response header key |
In |
Value as String |
Response header value |
- Example
-
Adding a response headers in any given dynamic logic invocation that is part of the Exchange’s lifecycle.
exchangeStep.addResponseHeader("my-header", "my-value")
markForRecovery
The markForRecovery method can be used to mark the exchange as Failed to enable its current exchange step to be recovered when the exchange is recovered.
This method when invoked, sets the exchange’s current exchange step (if any) for recovery along with all the exchange steps that belong to the same integration step as the current exchange step. This only happens if there is a recovery link present in the exchange properties for the current exchange steps' integration step to recover from the failed step.
If there is no recovery link or there is no current exchange step, this process will return false, meaning the exchange was not marked for recovery.
This method is useful when the process is not marked for autoRecovery, but is left on the discretion of the messages attached to the process notification.
- Availability
-
This method is available on Exchange object.
Parameters
In or Out |
Type |
Description |
Out |
Boolean |
True when the exchange is successfully marked for recovery, false otherwise. |
- Example
-
There is an activity step invoked and the step is not marked for autoRecovery. The step’s notification contains links for messages as well as for recovery. Following dynamic logic snippet can be used to check the messages and only mark the exchange and its steps as failed if messages contain a message with code 'OHI-FATAL-001'. This dynamic logic signature is 'Step Post Process' and messages are logged as logs on the previous step.
if(exchangeStep.previousExchangeStep!=null) {
def logs = new SearchBuilder(ExchangeLog.class)
.by("exchangeStep").eq(exchangeStep.previousExchangeStep)
.and()
.by(logLine).like("%OHI-FATAL-001%").execute()
if(logs.size > 0) {
exchange.markForRecovery()
// can also add code here to check if the exchange was actually marked for recovery
}
}
removeResponseHeader
This method can be used to selectively remove a response header or response headers from the Exchange that have been recorded up-to 'this' point.
- Availability
-
This method is available on ExchangeStep.
Parameters
In or Out |
Type |
Description |
In |
Predicate<Map.Entry<String, ?>> |
A predicate that describes a condition for the entry or entries to be removed from response headers. |
- Example
-
Removing all response headers recorded up-to this point that are in a specific set of well known headers.
import java.util.function.* setOfHeaders = ["header-one", "header-two"] Predicate isHeaderToRemove = { a -> setOfHeaders.contains(a.key) } exchangeStep.removeResponseHeader(isHeaderToRemove)
responseHeaders
This accessor (which is a representation of the method getResponseHeaders) can be used to obtain the complete set of response headers that have been recorded on the Exchange up-to 'this' point.
- Availability
-
This method is available on ExchangeStep.
setDynamicField
The method sets the dynamic field to an object.
- Availability
-
This method is available for all objects that support dynamic fields.
Parameters
In or Out | Type | Description |
---|---|---|
In |
String |
A usage name |
In |
Object |
Structure of the dynamic field |
- Example
-
The following logic sets a time-valid field usage:
policy.setDynamicField("policyCoverage", new DynamicFieldPeriod(polCovRef.policyCoverage,polCovRef.startDate,polCovRef.endDate))
The recommended way to use the dynamic field is mentioned in the Writing section. |