Higson Rules Engine Deployment: From Setup to Seamless Integration

Juliusz Marciniak
July 30, 2024
Blog

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:
  1. Memory: 1 Gi,  
  2. CPU: 200 m.
  • Limits:  
  1. Memory: 4 Gi,  
  2. CPU: none.

Higson Runtime Rest:

  • Requests:  
  1. Memory: 1 Gi,  
  2. CPU: 200 m..
  • Limits:  
  1. Memory: 4 Gi,
  2. 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.

Index
Get a personalized evaluation of Higson's potential for your use case
More stories

Power of Personalization in Insurance: How Tailored Experiences Are Redefining the Industry

Discover how personalization is transforming the insurance industry through data analytics, AI, and tailored experiences that boost customer satisfaction

READ MORE

Decision Tables for Smarter Rule Management: Higson Example

Explore decision tables in business rule management, their benefits, and how Higson leverages them for clearer, more efficient decision-making.

READ MORE

How Business Rules Engines Drive Back-Office Efficiency

Discover how Business Rules Engines streamline back-office operations, boost efficiency, ensure compliance, and support scalable growth.

READ MORE