Functions

A dynamic logic function is the most generic type of dynamic logic: it can have one or more input arguments and return different types of output. A dynamic logic function is used to extend default behavior in certain areas. Each usage of dynamic logic functions is described in a separate paragraph below.

Authorization Code Generation

An authorization code can be produced by a dynamic function. The following signature applies:

Table 1. Authorization Code Generation
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization being processed
Out	n/a	Alphanumerical	The authorization code

Only one function dynamic logic with this signature can be created (OHI-DYLO-028).

Example

  // Use the id of the authorization with 'AUT-', to use as code
  return "AUT-"+ authorization.id.toString()

Authorization Line Code Generation

An authorization line code can be produced by a dynamic function. The following signature applies:

Table 2. Authorization Line Code Generation
In or Out	Name	Type	Description
In	authorizationLine	AuthorizationLine	The authorization line being processed
Out	n/a	Alphanumerical	The authorization line code

Only one function dynamic logic with this signature can be created (OHI-DYLO-028).

Example

// Use the id of the authorization line with 'AUL-', to use as code
return "AUL-"+ authorizationLine.id.toString()

Callout Rule

A Callout Rule specifies dynamic function to create a request message body, make the callout and to handle the response message.

The following signature applies to the dynamic logic:

Table 3. Callout Rule
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization that is being evaluated
In	calloutRule	CalloutRule	The callout rule that is being evaluated (can be used to parametrize the dynamic logic)

This signature’s as-of date defaults to the authorization start date. Using this function dynamic logic the authorization (except for the Authorization Status, Code and Requested for fields) authorization service types, authorization lines, authorization baskets, authorization diagnoses and authorization messages can be modified.

The following example shows dynamic logic that creates a callout message with information about the person for whom the authorization is requested and the brand to which the authorization message belongs to.

  def writer = new StringWriter()
  def xml = new groovy.xml.MarkupBuilder(writer)

  xml.authorization(code:authorization.code) {
      personCode(authorization.person.code)
      brand(authorization.brand?.code)
  }

  String response = initCallout(WebTarget.class)
                       .path("post")
                       .request("application/xml")
                       .buildPost(Entity.xml(writer.toString()))
                       .invoke()
                       .readEntity(String.class)

  def result = new XmlSlurper().parseText(response)

  authorization.dynamicFieldABCD = result.customMessage.@dynamicFieldABCD.text()

Parsing XML in dynamic logic can be done with the Groovy XmlSlurper library.

By default, the callout invocation to the external service endpoint is done in an unsecured way. Property "ohi.service.{0}.client.authentication" (for example: "ohi.service.DYLO_CODE.client.authentication" where DYLO_CODE is the uniquely identifying code of the Dynamic Logic script) must be set to value BasicAuthentication to send the request using HTTP Basic Authentication. In that case the credentials must be specified using the "credentials" resource. The default value for "ohi.service.{0}.client.authentication" is None.

Alternatively, a callout request can also be specified with a callerId to identify the client, for example:

//Make the callout request
String response = initCallout(WebTarget.class, "MY_CALLER_ID")
                   .path("post")
                   .request()
                   .buildPost(Entity.xml(writer.toString()))
                   .invoke()
                   .readEntity(String.class)

In that case the authentication feature can be controlled with property "ohi.service.MY_CALLER_ID.client.authentication". This feature also allows use of multiple clients in one dynamic logic function and precise specification of features on a per client basis.

Deciding not to call the readEntity operation on the Response that is returned from the invoke() operation - you have to make sure that the underlying response is closed. So, in the above example assigning the result of invoke() to a variable - and work with that variable in the remainder of the dynamic logic, call the operation close() on it.

For a configured callout rule to be resolved to a callable endpoint, a property should be set. "ohi.{0}.endpoint.request" (for example: "ohi.DYLO_CODE.endpoint.request" where DYLO_CODE is the code of the configured callout rule) should be set to the URI of the end point, this is the actual (external) HTTP address that is used by the REST callout client. An example of this value is 'http://machine.domain:port/{0}

External callouts can be logged at a fairly low level. In particular, this enables to trace HTTP request and response between the system that initiates the request for enrollment status information and the enrollment system that responds back to these inquiries. To set this up, add the following piece of information to the logging configuration:

<logger name="ohi.rest.client" level="info"/>

Country Format

This function is attached to a country and defines the format of addresses within that country. The following signature applies:

Table 4. Country Format
In / Out	Name	Type	Description
In	address	Address	The address that is to be displayed
Out	n/a	String	The character string that represents the formatted address.

This function is executed whenever an address is displayed. There is no default as-of date.

Extension

This is a common signature, available in all the applications. This signature has no bindings. It allows for writing extensions to the dynamic logic scripts that are delivered by the product.

A dynamic logic function of signature Extension should be accompanied with a reference to the base dynamic logic and vice-versa (OHI-DYLO-031). The referenced base dynamic logic function cannot be of signature Reusable Code or Extension (OHI-DYLO-030).

Event Rule

The fields that are additionally sent out on the event message when an event rule is triggered are produced by a dynamic function. This dynamic function produces a list of name value pairs. This list of name value pairs is shown in the event messages in the <fields> element. This signature’s as-of date defaults to the authorization start date.

The following signature applies:

Table 5. Event Rule
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization being processed
Out	n/a	Map	The field names and their values

Pend Reason

The fields that are additionally sent out on the workflow message are produced by a dynamic function. This dynamic function produces a list of name value pairs. This list of name value pairs is shown in the workflow messages in the <fields> element. This signature’s as-of date defaults to the authorization start date.

The following signature applies:

Table 6. Pend Reason
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization being processed
Out	n/a	Map	The field names and their values

Person Data Replication Transformation

Data replication is required to synchronize or replicate data between different Oracle Health Insurance applications. An entity replicates data from a source to a target application using dynamic logic that overcomes differences between the two applications. Person Data Replication Transformation is a dynamic logic function used to replicate data of a Person entity. A Data Replication Transformation dynamic logic is configured between a combination of Oracle Health Insurance applications that are certified to exchange data using the data replication mechanism.

Parameters:

Table 7. Person Data Replication Transformation
In / Out	Name	Type	Description
In	payload	StringReader	The JSON payload representation of the entity retrieved from the source system. Oracle recommends using the JsonSlurper.
In	persistable	Oracle Health Insurance Domain class	The OHI domain class that was constructed from the entity and retrieved from the source system.

Example: The following sample logic sets the value of (dynamic) field, field, defined in the target system to the value of the (dynamic) field, anotherField, defined in the source system:

def message = new groovy.json.JsonSlurper().parse(payload)
assert message instanceof Map
persistable.field = message.anotherField

Provider Code Generation

A provider code can be produced by a dynamic function. This function can use the generated sequence number for generating a provider code. If the dynamic logic is not present, then the code defaults to the primary key of the entity. The following signature applies:

Table 8. Provider Code Generation
In or Out	Name	Type	Description
In	provider	Provider	The provider being created
Out	n/a	Alphanumerical	The provider code

Only one function dynamic logic with this signature can be created (OHI-DYLO-028).

Example

// Uses the id of the provider and prefixes it with 'PROV-'
return "PROV-" + provider.id.toString()

A field validation rule on the Provider Flex Code Definition may enforce a specific format and or value of the provider code. If such a validation rule exists the provider code generation dynamic logic must meet that validation.

Reusable Code

This is a common signature, available in all the applications. This signature has no bindings. It allows for writing standalone methods/reusable classes code that can be shared across other scripts.

If a reusable dynamic logic is changed, and the changes are not reflected in the dynamic logics that have used or imported the reusable dynamic logic. To get it to work, invoke the invalidateall operation before starting other operations. See Invalidate Dynamic Logic, for more info.

Test Unit

A dynamic logic with the Test Unit signature tests another dynamic logic. Such a dynamic logic that runs a test on another dynamic logic is called a test case. A test case sends objects as input to the unit under test (UUT) and validates the output.

Table 9. Test Unit
In or Out	Name	Type	Description
Out	Not Available	Boolean	Returns `true` if the test case ran successfully, `false` otherwise.

You can run a test case using the Test Dynamic Logic.

URL Composition

A flex code field usage of a dynamic record definition can reference a dynamic logic function to build up the URL needed to access an external application. In this way it is possible to change for example a server location in a central way.

Table 10. URL Composition
In or Out	Name	Type	Description
In	dynamicRecord	DynamicRecord	The dynamic record
Out	n/a	Alphanumerical	The composed URL

Example:

return "http://financialsystem.oracle.com?p_check_number="+dynamicRecord.checkNumber

Validation Rule

A validation rule is evaluated during the processing of an authorization.

Table 11. Validation Rule
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization that is being evaluated
In	validationRule	ValidationRule	The validation rule being evaluated (can be used to parametrize the dynamic logic)

This signature’s as-of date defaults to the authorization start date. Using this function dynamic logic the authorization (except for the Authorization Status, Code and Requested for Insurable entity type and code fields), authorization service types, authorization lines, authorization baskets, authorization diagnoses and authorization messages can be modified.