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:

In or Out	Name	Type	Description
In	authorization	Authorization	The authorization being processed
Out	n/a	Alphanumerical	The authorization code

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:

In or Out	Name	Type	Description
In	authorizationLine	AuthorizationLine	The authorization line being processed
Out	n/a	Alphanumerical	The authorization line code

// 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:

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 = [e-mail]()

• 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.

Whenever you decide to not 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 if you assign 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:

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.

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:

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

HTTP Link

A HTTP link references a dynamic logic function to build up the URL needed to access - in a different browser tab - the report. The context from which the link is clicked serves as input object for the dynamic logic.

In or Out	Name	Type	Description
In	Depends on the page	Depends on the page	The object that the page provides as input.
In	httpLink	HTTP Link	The http link that is being evaluated
Out	n/a	Alphanumerical	The composed URL

Example:

// Navigate to external overview page
return "http://"+getSystemProperty('reports.server.name')+".benefitsoverview?p_auth_code="+authorization.code

where the server location for the report is stored in a property so that different environments can navigate to different servers for that.

Name Format

Name formats are defined by a dynamic logic function. The dynamic logic function constructs a formatted name for a person, using the available person fields such as the first name, prefix and titles. The following signature applies:

In or Out	Name	Type	Description
In	person	Person	The person of which the name is to be displayed
Out	n/a	Alphanumerical	The string that contains the formatted name of the person

The following signature for individual providers applies:

In or Out	Name	Type	Description
In	individualProvider	IndividualProvider	The individual provider of which the name is to be displayed
Out	n/a	Alphanumerical	The string that contains the formatted name of the individual provider

This function is called whenever a formatted name is displayed. Consider the following example for persons, where the formatted name consists of the person’s initials, prefix, (last) name and suffix respectively:

nf = ''
if (person.initials) nf += person.initials + ' '
if (person.prefix) nf += person.prefix.displayCode + ' '
if (person.name) nf += person.name
if (person.suffix) nf += ' ' + person.suffix
return nf

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:

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

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.

Test Unit

Dynamic logic of this signature do not implement business functionality. They act instead as test drivers of other dynamic logic.

Dynamic logic can be tested by invoking the business process where the logic is called and see if it performs as expected. This is however a cumbersome process: many business process flows can only be executed under very specific circumstances and executing them may take long.

Here a test unit helps. The logic of the test unit can construct (or retrieve) input objects and pass them to the dynamic logic that is to be tested and validate the output. There is no need to start the business process. The Test Unit enables unit-testing of dynamic logic.

The following signature applies:

In / Out	Name	Type	Description
Out	n/a	Boolean	True if the Test Unit ran successfully, false otherwise.

NOTE

Test Units can be executed by invoking the Test Dynamic Logic Integration Point

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.

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.

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.