Gateway Dynamic Logic Bindings
In Oracle Insurance Gateway, dynamic logic can be invoked in various integration steps and is used to transform or process data. This section describes to which information a piece of dynamic logic has access.
Bind variables are used to store information about the invocation of an exchange and results of a exchange step such that these can be accessed in the dynamic logic of subsequent steps. The set of bind variables is determined by the dynamic logic’s signature. The following bindings are available in any dynamic logic:
Binding Name | Binding Type | Description |
---|---|---|
trigger |
DataFileSet or String |
This is the payload that the integration is invoked with. If it is invoked with a file, the binding refers to a DataFileSet, else it is a plain String containing the payload. |
<Configured Output Name> |
DataFileSet or String |
The results of a step are stored in output objects. The name of the output object is specified by the step property outputName. If the outputName is not specified then the output object is stored under the name of the integration step. If a step produces a file, then the output object refers to a DataFileSet, else it is plain String object. |
exchangeStep |
ExchangeStep |
The object that represents the exchange step that is executed. |
properties |
Map |
The properties map is a way for integration steps to share information. Properties can be used in the dynamic logic of a subsequent step or as bind parameter to a query or extract step |
Trigger
The content of the trigger can be accessed in the following ways.
Integration Invoked With One or More Files
Fileset
For an Integration invoked with a one or more files the trigger is an object of the type DataFileSet. The following code snippet shows how to traverse each of the files in the fileset:
trigger.dataFiles.each{dataFile ->
exchangeStep.addLogEntry("datafile code,descr :"+dataFile.code+" , "+dataFile.descr)
}
Integration Invoked With a Payload
Text
When the integration is invoked the payload of the type text, the trigger object will be of type String and the text with which the exchange was invoked can be logged with the following code snippet:
exchangeStep.addLogEntry(trigger)
OutputName
The results of a step are stored in output objects. The name of the output object is specified by the step property outputName. If the outputName is not specified then the output object is stored under the name of the integration step.
If a step produces a file, then the output object refers to a DataFileSet, else it is plain String object.
For example an integration with the following steps
[{
"code" : "Policies Query",
"sequence" : 1,
"subtype" : "QUERY",
"outputName" : "policiesQueryOutput",
"typeConfig": {
"resourceName": "policyenrollments",
"q": "person.code.eq({memberCode})",
"fields" : "policyEnrollmentProductList.groupAccountProduct.enrollmentProduct.code"
},
"destination": {"code": "policiesGetDestination"}
},
{
"code" : "Claims Query",
"sequence" : 2,
"subtype" : "QUERY",
"outputName" : "claimsQueryOutput",
"typeConfig": {
"resourceName": "claims",
"q": "person.code.eq({memberCode})",
"fields" : "claimLineList.claimLineMessageList.message.message"
},
"destination": {"code": "claimsGetDestination"}
},
{
"code" : "Process query results in Custom step",
"sequence" : 3,
"subtype" : "CUSTOM",
"outputName" : "customStepOutput",
"typeConfig" : {
"customFunctionCode" : "mergePoliciesandClaimsQueryOutput" },
"destination" : {"code": "claimsGetDestination"}
}]
The dynamic logic function in the third step mergePoliciesandClaimsQueryOutput
,
can access the output from the first 2 steps by referring to the outputNames of the first 2 steps.
In this case to 'policiesQueryOutput' and to 'claimsQueryOutput'
Dynamic logic: mergePoliciesandClaimsQueryOutput
exchangeStep.addLogEntry(policiesQueryOutput)
exchangeStep.addLogEntry(claimsQueryOutput)
ExchangeStep
The exchangeStep
bind variable is the object that represents the exchange step that is executed.
exchangeStep.addLogEntry("The exchange id :" + exchangeStep.exchange.id)
exchangeStep.addLogEntry("The integration code:" + exchangeStep.exchange.integration.code)
exchangeStep.addLogEntry("The integration description:" + exchangeStep.exchange.integration.descr)
Via the exchangeStep
the Exchange
is accessible.
The following example sets a customer-defined transactionIdentifier
on the Exchange
to identify that the Exchange
is "step 1" of business transaction "TX1":
exchangeStep.exchange.transactionIdentifier1 = "transaction_TX1_step_1"
The following example shows how to search Exchanges
for a certain (business) transaction:
def SearchBuilder sb =
new SearchBuilder(Exchange.class).by("transactionIdentifier1").eq("transaction_TX1_step_1")
def exchanges = sb.execute()
if (exchanges.size() >= 1) {
log.debug("First Exchange found: " + exchanges[0].getId())
}
Alternatively, use both transactionIdentifier
attributes that are available on an Exchange
, for example:
exchangeStep.exchange.transactionIdentifier1 = "TX1"
exchangeStep.exchange.transactionIdentifier2 = "step_1"
And search Exchanges
for the (business) transaction in the following manner:
def SearchBuilder sb =
new SearchBuilder(Exchange.class).by("transactionIdentifier1").eq("TX1")
.and().by("transactionIdentifier2").eq("step_1")
def exchanges = sb.execute()
if (exchanges.size() >= 1) {
log.debug("First Exchange found: " + exchanges[0].getId())
}
Properties
The properties map is a way to share information across Exchange Steps and Exchanges. Properties can be used in the Dynamic Logic of a subsequent step or as bind parameter to a Query or Extract Step.
Accessing Properties
Access to Properties in Dynamic Logic
The value of an entry in the properties map can be accessed via its key, for example:
properties["propertyKey"]
The following example shows how to add a new property with key "key". If a property with that key already exists its value will be updated:
properties.put("key","the value of the property")
Properties as Bind Parameters
In any step configuration, properties can be used as bind parameters.
Below configuration shows a query on the claims resources where in the query string
a condition on the value of the property correlation id that is identified by {correlationId}
:
{
"typeConfig": {
"resourceName": "claims",
"q": "correlationId.eq({correlationId})",
"fields": "claimLineList.claimLineMessageList.message.message"
}
}
Available Properties
The properties map contains the following information:
-
the parameters with which the integration was invoked
-
the header values with which the integration was invoked (except the Authorization header)
-
all properties that were added to the properties map in dynamic logic in the previous or current step
-
framework properties
Parameters
If an integration is invoked with parameters, then these parameters are also made available as part of the properties map.
For instance if the exchange /ClaimsIntegration/withParameters is invoked with the payload
POST {{OIG_URL}}/oig-ws/api/exchanges/integration/ClaimsIntegration/withParameters
{ "claimCode" : "OIG_OO1"}
In Dynamic Logic the properties map can be accessed by referring to properties['key']. Extending the example above, the following adds the value of the claimCode property as a log entry:
exchangeStep.addLogEntry("Claim code" + properties["claimCode"] )
Properties Added in Dynamic Logic
In Dynamic Logic additional key value pairs can be added to the properties map. The following snippet shows how to add the Exchange id as the value of key "correlationId"
properties.put("correlationId",exchangeStep.exchange.id.toString())
Framework Properties
The framework adds the following properties:
We recommend uploading files with sizes under 20 MB. Larger files impact the stability of the system. |
Property Name | Property Type | Description |
---|---|---|
timeAllowedInMillis |
Long |
If an exchange is invoked with a header parameter: ohi-exchange-allowed-time-ms, to make sure that it completes in that time, else is stopped, this property stores the time allowed for the exchange. |
notificationResult |
String |
If a step has a notification result, due to external notification, this property stores the notificationResult. Success or Failure. |
dataFileSetCode |
String |
If there is a step in the exchange that performs a file upload as destination, then this property holds the data file set code of the uploaded file |
responseDataFileSetCode |
String |
If there is a step in the exchange that performs a file upload as destination, then this property holds the data file set code of the expected response file. |
<integrationStepCode>-recoveryLink |
String |
The url to recover the exchange step if it is a long running process and it failed. |
<integrationStepCode>-locationHeader |
String |
The url to fetch the status of the process if the process runs for too long and times-out at gateway end. |
Retrieving Exchanges using Exchange Properties
The following Dynamic Logic example demonstrates searching for Exchanges
by customer-defined properties "transactionId" and "transactionProcessed" status:
def SearchBuilder sb =
new SearchBuilder(Exchange.class).by("transactionId").eq("TX1")
.and().by("transactionProcessed").eq("false")
def exchanges = sb.execute()
log.debug("Number of Exchanges found: " + exchanges.size())
The index that facilitates searching Exchanges by properties is updated every 15 minutes.
For a query to return the Exchange, the property values must be updated in the index.
As a result, it could take 15 minutes to retrieve Exchanges
by recently changed property values.
Alternatively, use the transactionIdentifier1
and transactionIdentifier2
attributes of an Exchange for near real-time Exchange
retrieval.