Bootstrap

Studio

Higson Studio is a Java application and can be run at JVM machine equipped with:

at least Java 17 JRE,
4 GB of RAM,
2 CPU,
Linux, Windows or macOS machine.

Docker#

Higson Studio distribution does not contain JDBC drivers other than H2 database. Every image contains description how to configure JDBC driver.

Full docker repository is available here.

Runtime

Prerequisites:

Java 17
Maven 3.x
Higson Studio

JavaDoc

We will show how to configure Higson Engine using Spring Boot configuration

Maven configuration#

Apart from standard spring boot dependencies, you need to include higson-runtime dependency, available in Maven Central.

1
2
3
4
5


<dependency>
    <groupId>io.higson</groupId>
    <artifactId>higson-runtime</artifactId>
    <version>${higson-runtime.version}</version>
</dependency>

Another needed dependency is the JDBC driver to the database of choice, e.g., h2, oracle, mssql, postgresql and database connection pool managing library:

1
2
3
4
5
6
7


<dependencies>
  <dependency>
     <groupId>com.h2database</groupId>
     <artifactId>h2</artifactId>
     <version>${h2-database.version}</version>
 </dependency>
</dependencies>

Properties#

Add Higson Runtime data source properties to application.properties file.

1
2
3


higson.database.url=<jdbc\_url\to\database>
higson.database.username=<username>
higson.database.password=<password>

Properties are available here

Spring configuration#

Add required beans to your java class annotated with @Configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


  @Autowired
  private Environment env;
  
  private static final Logger log = LoggerFactory.getLogger(TestConfiguration.class);
  
  @Bean
  public DialectRegistry getDialectRegistry() {
      DialectRegistry registry = new DialectRegistry();
      registry.setDialect(env.getProperty("higson.database.dialect"));
      return registry;
  }
  
  @Bean
  public DialectTemplate getDialectTemplate(DialectRegistry dialectRegistry) {
          return dialectRegistry.create();
  }
  
  @Bean(destroyMethod = "close")
  public DataSource getDataSource(DialectTemplate dialectTemplate) {
      BasicDataSource dataSource = new BasicDataSource();
      dataSource.setUsername(env.getProperty("higson.database.username"));
      dataSource.setPassword(env.getProperty("higson.database.password"));
      dataSource.setUrl(env.getProperty("higson.database.url"));
      dataSource.setInitialSize(4);
      dataSource.setDriverClassName(dialectTemplate.getJdbcDriverClassName());
      return dataSource;
  }
  
  @Bean(destroyMethod = "destroy")
  public HigsonEngineFactory getHigsonEngineFactory(DataSource dataSource) {
      log.info("Engine factory begin creation...");
      HigsonEngineFactory higsonEngineFactory = new HigsonEngineFactory();
      higsonEngineFactory.setDataSource(dataSource);
      return higsonEngineFactory;
  }
  
  @Bean
  public HigsonEngine getHigsonEngine(HigsonEngineFactory higsonEngineFactory) {
      log.info("Engine begin creation...");
      return higsonEngineFactory.create();
  }

The application is ready to start. After successfully starting the application, you can see similar log output:

Runtime Rest Spring Boot Starter

Prerequisites#

Java 17
Maven 3.x
Spring Boot

Maven configuration#

Apart from standard spring boot dependencies, you need to include higson-runtime-spring-boot-starter dependency, available in Maven Central. Add higson-runtime-spring-boot-starter dependency to pom.xml file:

1
2
3
4
5


<dependency>
 <groupId>io.higson</groupId>
 <artifactId>higson-runtime-spring-boot-starter</artifactId>
 <version>${higson-runtime.version}</version>
</dependency>

Another needed dependency is the JDBC driver to the database of choice, e.g., h2, oracle, mssql, postgresql:

1
2
3
4
5


<dependency>
 <groupId>com.h2database</groupId>
 <artifactId>h2</artifactId>
 <version>${h2-database.version}</version>
</dependency>

Properties#

With the above setup, all the configuration that is needed is application.properties file with database properties:

1
2
3
4
5


higson:
 database:
  username: <username>
  password: <password>
  url: <jdbc_url>

If required properties are not available, higson-runtime-spring-boot-starter will return an adequate message.

To configure external sources, you have to set comma separated list of external sources names and connection properties for each of them. You can do it by using the properties below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


higson:
 runtime:
  external-datasource:
   sql:
    postgres:
     url: <postgres_jdbc_url>
     password: <postgres_password>
     username: <postgres_username>
    h2:
     url: <h2_jdbc_url>
     username: <h2_username>
     password: <h2_password>
    names: postgres,h2

Using auto-configured HigsonEngine#

After successfully configuring properties while starting the application, spring will create HigsonEngine bean available in the spring application context, then which can be injected anywhere:

1
2
3
4
5


@Component
public class HigsonClient {
 @Autowired
 private HigsonEngine engine;
}

Overriding default configuration#

To override default auto-configuration, you need to define HigsonEngine bean in the @Configuration class:

1
2
3
4
5
6
7
8


@Configuration
class CustomHigsonConfiguration {
 @Bean
 public HigsonEngine higsonEngine() {
  var factory = new HigsonEngineFactory();
  return factory.create();
 }
}

Existing auto-configured DataSource and HigsonRuntimeProperties can be used simply by injecting them:

1
2
3
4


public class HigsonEngine(
        HigsonRuntimeProperties properties,
        @Qualifier("higsonDataSource") DataSource dataSource
) {}

Disabling Higson#

If you want to disable higson temporarily for some reason, you can do it with property higson.runtime.enabled set to false.

1
2
3


higson:
 runtime:
  enabled: false

Runtime Rest

Higson Runtime REST is a web application that provides REST API for decision table/function/domain access. It is a REST implementation of Java’s Higson Runtime jar. It is available in two forms:

Spring boot’s executable jar, available here: https://mvnrepository.com/artifact/io.higson/higson-runtime-rest
Docker image, available here: https://hub.docker.com/repository/docker/decerto/higson-runtime-rest

Environment#

Higson Runtime REST is a Java application and can run with any Java 8 or higher on Windows, MacOS X and Linux/Unix.

CLI#

To run Runtime-Rest from cli you must pass four properties:

loader.path - path to jdbc driver
higson.database.url
higson.database.username
higson.database.password

Download latest version of higson runtime rest and database driver (postgresql for example)

1
2
3
4
5
6
7


wget  https://repo1.maven.org/maven2/pl/decerto/higson-runtime-rest/4.0.0/higson-runtime-rest-4.0.0.jar -O higson-runtime-rest.jar
wget  https://repo1.maven.org/maven2/org/postgresql/postgresql-42.6.0/postgresql-42.6.0.jar -O postgresql.jar

java -Dloader.path=./postgresql.jar -jar ./higson-runtime-rest.jar \
        -Dhigson.database.url=”jdbc:postgresql://your_postgresql_database:5432/higson?currentSchema=public” \
        -Dhigson.database.username=”admin” \
        -Dhigson.database.password=”admin”

Docker#

To run Higson Runtime REST as a docker image, there is need to build a separate docker image based on decerto/higson-runtime-rest image, add your database driver jar and run Higson Runtime REST jar with additional path.

Example:

1
2
3
4


FROM decerto/higson-runtime-rest:4.0.0
ARG DRIVER=postgresql.jar
COPY ${DRIVER} driver.jar
ENTRYPOINT [`java`,`-Dloader.path=driver.jar`, `-jar`,`/runtime-rest.jar`]

Additionally, you need to pass 3 properties:

higson.database.url
higson.database.username
higson.database.password

An invocation example:

1
2
3
4


docker run -p 8080:8081 -e higson.database.url=jdbc:postgresql://your_postgresql_database:5432/higson?currentSchema=public
-e higson.database.username=admin
-e higson.database.pasword=password
-t my-container

Using Higson Runtime REST#

This short tutorial will guide you through the process of running Higson Runtime REST as a docker image and invoking decision table/function/domain element.

Prerequisites#

In order to run examples from this article you will need:

running docker. See https://docs.docker.com/installation/#installation for details on setting Docker up for your machine.
a favorite REST API Client to send requests such as Postman
a favorite internet browser

Setting up a docker images#

The tutorial will be based on our motor insurance. It consists of the insurance web application, Higson Studio, and Higson Runtime REST modules. There is a docker-compose.yml file that makes the whole application easy to run. Just download a project from GitHub, open terminal in that directory, and run the following command:

1
2
3
4
5


docker-compose up

//or depending which docker version is installed

docker compose up

If you look closely inside the docker-compose.yml file, you will see that Higson Runtime REST docker image needs three additional properties to be passed to run properly:

higson.database.url : JDBC url to Higson’s database
higson.database.username : Higson’s database username
higson.database.password : Higson’s database password

If you want to connect to other database types such as Oracle, Postgres, MsSQL or MySQL, then you must build your own docker image and provide your database driver. Here’s a Docker file example that copies custom database driver and runs Runtime REST application:

1
2
3
4


FROM decerto/higson-runtime-rest:latest
ARG DRIVER\_JAR=dbDriver.jar
COPY ${DRIVER\_JAR} driver.jar
ENTRYPOINT\["java","-Dloader.path=driver.jar","-jar","/runtime-rest.jar"\]

Demo app should be available at localhost:48080/demo
Higson Studio should be available at localhost:38080/higson/app
Higson Runtime REST should be available at localhost:8081

To access higson services use followed credentials: User: admin Password: admin

Getting decision table value#

We will be using decision table examples from this article. Let’s get the value of a demo.motor.coverage.position decision table for the “BI” coverage code. Here’s the request we’re going to use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


{  
 "ctx": {  
  "properties": [  
    {    
     "key":"coverage.code",    
     "value":"BI"  
    }  
   ]  
 },  
 "elements": [  
  {  
   "code":"demo.motor.coverage.position",  
   "type":"PARAMETER"  
  }  
 ]
}

It consists of 2 main parts: ctx and elements. The former represents the input values we want to pass to Higson. We can pass there simple as well as complex objects. The latter is a list of Higson elements to invoke.

When we send this request to the localhost:8081/api/execution/invoke url, we should receive the following response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


[  
  {  
   "element": {  
    "code":"demo.motor.coverage.position",  
    "type":"PARAMETER",  
    "attributeCode":null,  
    "profileCode":null  
    },  
   "resultValue": [  
    {    
     "fields": [      
      {       
       "key": "position",       
       "value": 1      
      }    
     ]  
    }  
   ]  
  }
]

We receive a list of executed Higson elements with corresponding values.

Let’s see how the response will look like if more than one row will be returned from the decision table. In this example, we are going to use the demo.motor.dict.vehicle.available decision table. Here’s the request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{  
 "ctx": {  
  "properties": [  
   {    
    "key":"quote.vehicle.productionYear",    
    "value":1972  
   },
   {    
    "key":"coverage.code",    
    "value": "BI"  
   }   
  ]  
 },  
 "elements": [  
  {  
   "code":"demo.motor.dict.vehicle.availableMakes",  
   "type":"PARAMETER"  
  },   
  {  
   "code": "demo.motor.coverage.position",  
   "type":"PARAMETER"  
  }  
 ]
}

Besides a new decision table code and context property, you can see how to invoke more than one Higson element in a single JSON request. Let’s see the response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69


[  
 {   
  "element": {   
   "code": "demo.motor.coverage.position",   
   "type": "PARAMETER",  
   "attributeCode": null,   
   "profileCode": null  
  },   
  "resultValue": [  
   {   
    "fields": [      
     {       
      "key": "position",       
      "value": 1      
     }    
    ]  
   }  
  ]  
 },{   
  "element": {   
  "code": "demo.motor.dict.vehicle.availableMakes",   
  "type": "PARAMETER",   
  "attributeCode": null,   
  "profileCode": null  
 },   
 "resultValue": [  
  {   
   "fields": [      
    {       
     "key": "make",       
     "value": "STAR"      
    },{       
     "key": "make_id",       
     "value": 722      
    }    
   ]  
  },{   
   "fields": [      
    {       
     "key": "make",       
     "value": "TRABANT"      
    },{       
     "key": "make_id",       
     "value": 221      
    }    
   ]  
  },{   
   "fields": [      
    {       
     "key": "make",       
     "value": "UAZ"      
    },{       
     "key": "make_id",       
     "value": 315      
    }    
   ]  
  },{   
   "fields": [      
    {       
     "key": "make",       
     "value": "WARTBURG"      
    },{       
     "key": "make_id",       
     "value": 230      
    }    
   ]  
  }  
 ]  
]

As we see, each element has its own JSON section in returned array. What’s more, each row in the decision table’s matrix corresponds to one complex element in the resultValue array.

Calling function#

Let’s get the computed value of the demo.insurance.calc.premium function. Here’s the request we’re going to use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{  
 "ctx": {  
  "properties": [    
   {      
    "key":"policy.premiumPerDay",      
    "value":200    
   },{      
    "key":"policy.startDate",      
    "value": "2017-01-01"    
   },{      
    "key":"policy.endDate",      
    "value":"2017-01-03"    
   }  
  ]  
 },  
 "elements": [  
  {    
   "code":"demo.insurance.calcpremium",    
   "type":"FUNCTION"  
  }  
 ]
}

It’s basically the same request as the one used in the decision table section. However, we pass here three context key-value pairs instead of one. Here’s the response we should get by calling the localhost:8081/api/execution/invoke endpoint:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[  
 {  
  "element": {    
    "code":"demo.insurance.calcpremium",    
    "type":"FUNCTION",    
    "attributeCode":null,    
    "profileCode":null  
  },  
  "resultValue": 600.0  
 }
]

Again, the same response format as in the decision table’s.

Accessing domain attributes#

Last but not least, let’s see how to access domain attributes through invoke API. We’ll be using examples from this article. Let’s see how to evaluate a position attribute of a coverage BI domain element:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{  
 "ctx": {  
  "properties": [  
   {    
    "key":"coverage.code",   
    "value":"COLL"  
   }  
  ]  
 },  
 "elements": [  
  {  
   "profileCode":"DEMO",  
   "code":"/PLANS[FULL]/COVERAGES[BI]/",  
   "attributeCode":"POSITION",  
   "type":"DOMAIN_OBJECT"  
  }  
 ]
}

The main difference between domain element and decision table/function is the presence of 2 additional attributes: profileCode and attributeCode, which names are self-describing. Let’s look at the response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


[  
 {  
  "element": {  
   "code":"/PLANS[FULL]/COVERAGES[BI]/",  
   "type":"DOMAIN_OBJECT",  
   "attributeCode":"POSITION",  
   "profileCode":"DEMO"  
  },  
  "resultValue": [  
   {    
    "fields": [      
     {       
      "key": "position",       
      "value": 8      
     }    
    ]  
   }  
  ]  
 }
]

As we see, the response format is the same as in the decision table/function section.

If you want to learn more or discover other available endpoints, there is a Runtime REST swagger online documentation available at: http://localhost:8081/swagger-ui/index.html.

Accessing Swagger UI#

The Swagger UI link is generated automatically based on the installation type (Docker or Bundle). The Swagger UI is accessible at the following address format:

http://[host]:[port]/[appname]/[apiname]/swagger-ui/index.html

For Docker-based Deployments#

When the application is running in a Docker environment, the URL components are determined as follows:

host: localhost (or the container’s IP address if accessed externally)
port: retrieved from the server.port property (e.g., 8080)
apiname: the value of server.servlet.context-path from the application’s configuration (e.g., /api)

Example: http://localhost:8080/api/swagger-ui/index.html

For Bundle Installations#

In the case of a bundle installation:

host: localhost
port: retrieved from the conf/server.xml configuration file by locating a line such as:
```
<Connector port="38080" protocol="HTTP/1.1" ... />
```
In this example, the port is 38080.
appname and apiname: determined based on the directory structure within the webapps folder. For version 4.1, the typical folder name is higson#api, which translates to:
- appname = higson
- apiname = api

Example: http://localhost:38080/higson/api/swagger-ui/index.html

By following these rules, you can easily determine the correct Swagger UI URL regardless of the deployment method.