Higson, developed by Decerto, is an advanced business rules engine that allows both business and technical users to define, modify, and deploy business rules without deep programming knowledge.
As a developer, I have had numerous opportunities to implement it across various projects. With its intuitive user interface, especially with the release of Studio version 4, Higson BRE enables companies to swiftly adapt to changing market conditions by adjusting their business rules in real time. This solution is particularly valued in the insurance industry for optimizing processes and enhancing operational efficiency.
Deployment
Deploying Higson can be done in several ways. To start using Higson, you need to set up a database such as H2 (for non-production purposes), PostgreSQL, Oracle, MSSQL, or MySQL. Next, install Higson Studio, which is written in Java and offers flexible deployment methods. Higson Studio can be provided as a WAR file to run on an application container or as a Docker image.Higson Studio
Higson Studio
The primary method I often use to deploy Higson Studio is deploying the WAR file on an appropriate application container like Tomcat. While you could choose alternatives like JBoss, I find Tomcat to be the best option due to its ease of configuration and lightweight nature. It supports servlet handling without the full JEE stack. Configure the necessary files, including database connection details. Higson can be downloaded from the provided link.
Additionally, Higson Studio can be deployed using provided Docker images or as a Kubernetes deployment. Note that Higson Studio is delivered without bundled database drivers. For Docker images, you need to include the driver via a volume or build your own Docker image.
Example Dockerfile with JDBC driver included:
FROM decerto/higson-studio:4.0.6
ARG DRIVER=postgresql.jar
COPY ${DRIVER} /usr/local/tomcat/lib/driver.jar
EXPOSE 38080
Example Kubernetes deployment:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: higson-studio
namespace: higson-dev
labels:
app.kubernetes.io/name: higson-studio
app.kubernetes.io/part-of: higson
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: higson-studio
template:
metadata:
labels:
app.kubernetes.io/name: higson-studio
app.kubernetes.io/version: 4.0.6
app.kubernetes.io/part-of: higson
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
containers:
- name: higson-studio
image: higson/higson-studio:4.0.6
imagePullPolicy: Always
env:
- name: HIGSON_DATABASE_URL
value: jdbc:postgresql://postgres:5432/higson?userhigson&password=higson
- name: HIGSON_DATABASE_DIALECT
value: postgresql
- name: HIGSON_ENVIRONMENT_ID
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
ports:
- name: http
containerPort: 38080
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: [ "ALL" ]
seccompProfile:
type: RuntimeDefault
livenessProbe:
httpGet:
path: /higson/api/actuator/health
port: http
scheme: HTTP
initialDelaySeconds: 60
failureThreshold: 3
readinessProbe:
httpGet:
path: /higson/api/actuator/health
port: http
scheme: HTTP
initialDelaySeconds: 10
failureThreshold: 3
resources:
requests:
cpu: 200m
memory: 1Gi
limits:
memory: 4Gi
---
apiVersion: v1
kind: Service
metadata:
name: higson-studio
namespace: higson-dev
labels:
app.kubernetes.io/name: higson-studio
app.kubernetes.io/part-of: higson
spec:
selector:
app.kubernetes.io/name: higson-studio
ports:
- name: http
port: 8080
targetPort: http
Ensure you input parameters like database address, and remember that the Docker image must include the JDBC driver, as mentioned above.
The choice of deployment type depends on your current infrastructure. Traditional application container deployment is straightforward and familiar to many administrators and allows easy debugging. On the other hand, using Docker or Kubernetes offers better scalability and portability.
Higson Runtime
While Higson Studio is sufficient to start, you usually need to integrate your application with the tool. For this, you can use the JAR library io.higson/higson-runtime, which allows full utilization of Higson. If you're using Spring Boot, there is also the io.higson/spring-boot-starter-higson-runtime starter. This library integrates through the database, making it the fastest possible integration method.
Since Higson's database can only be modified via Studio, data synchronization issues are minimized. This is the simplest way to integrate Higson and is ideal for monolithic applications.
For microservices, the scenario is more complex. Studio and Runtime versions must be consistent, making version updates in microservices challenging due to the need for synchronization across different applications. Fortunately, there's a solution for this.
Higson Runtime Rest
You can deploy an additional application that integrates with Higson and exposes data via a REST API, called Higson Runtime Rest. This application, like Studio, is provided as a WAR file and can be deployed similarly. A Docker image is also available, allowing deployment as a Docker container or on Kubernetes. Remember to include the JDBC driver.
Example Dockerfile with JDBC driver includes:
FROM decerto/higson-runtime-rest:4.0.6
ARG DRIVER=postgresql.jar
COPY ${DRIVER} driver.jar
ENTRYPOINT [ "java","-Dloader.path=driver.jar", "-jar", "/runtime-rest.jar" ]
Example Kubernetes deployment:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: higson-runtime-rest
namespace: higson-test
labels:
app.kubernetes.io/name: higson-runtime-rest
app.kubernetes.io/part-of: higson
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: higson-runtime-rest
template:
metadata:
labels:
app.kubernetes.io/name: higson-runtime-rest
app.kubernetes.io/version: 4.0.6
app.kubernetes.io/part-of: higson
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
containers:
- name: higson-runtime-rest
image: higson/higson-runtime-rest:4.0.6
imagePullPolicy: Always
env:
- name: HIGSON_DATABASE_URL
value: jdbc:postgresql://postgres:5432/higson?userhigson&password=higson
- name: HIGSON_DATABASE_DIALECT
value: postgresql
- name: HIGSON_ENVIRONMENT_ID
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
ports:
- name: http
containerPort: 8081
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: [ "ALL" ]
seccompProfile:
type: RuntimeDefault
livenessProbe:
httpGet:
path: /actuator/health
port: http
scheme: HTTP
initialDelaySeconds: 60
failureThreshold: 3
readinessProbe:
httpGet:
path: /actuator/health
port: http
scheme: HTTP
initialDelaySeconds: 10
failureThreshold: 3
resources:
requests:
cpu: 200m
memory: 1Gi
limits:
memory: 4Gi
---
apiVersion: v1
kind: Service
metadata:
name: higson-runtime-rest
namespace: higson-test
labels:
app.kubernetes.io/name: higson-runtime-rest
app.kubernetes.io/part-of: higson
spec:
selector:
app.kubernetes.io/name: higson-runtime-rest
ports:
- name: http
port: 8080
targetPort: http
Deployment Recommendation
The most effective way to deploy Higson currently is by using an orchestrator like Kubernetes. This approach has several advantages. Firstly, it makes version updates seamless, and the application can easily scale to multiple instances. With database synchronization, Higson manages multiple instances without any issues. Additionally, once the deployment files are prepared, they can be easily transferred to other environments or clusters. In my view, this is the most convenient deployment method, assuming your organization already uses Kubernetes.
In this setup, it’s best to use both Higson Studio and Higson Runtime Rest. It’s a good idea to allocate Higson to a separate namespace. To ensure service discovery within a single namespace, you can add an ExternalName service to the application namespace, like this:
---
kind: Service
apiVersion: v1
metadata:
name: higson
namespace: app-dev
labels:
app.kubernetes.io/part-of: app
spec:
type: ExternalName
externalName: higson-runtime-rest.higson-dev.svc.cluster.local
ports:
- port: 8080
For proper requests and limits settings, the initial recommended values are:
Higson Studio:
- Requests:
- Memory: 1 Gi,
- CPU: 200 m.
- Limits:
- Memory: 4 Gi,
- CPU: none.
Higson Runtime Rest:
- Requests:
- Memory: 1 Gi,
- CPU: 200 m..
- Limits:
- Memory: 4 Gi,
- CPU: none.
Summary
In this article, I have outlined how to deploy Higson rules engine along with Studio and how to integrate it with your applications. The deployment process is straightforward, requiring only attention to proper addresses and network traffic. By default, Higson should not be exposed to the public internet; however, due to the various supported authentication methods, it can be made accessible outside the internal network. Regardless of the deployment and integration method you choose, I recommend thoroughly reading the documentation, as it provides answers to most questions.
Using business rules engine like Higson provides flexibility in building business applications. We can shift the configuration burden to this tool, thereby lightening the load on the application being developed. In my opinion, it’s crucial to carefully consider which parameters to offload to Higson and how to construct the domain. A bit of good planning can pay off significantly when developing and maintaining systems that rely on data from Higson.
