Shopping recommendations in PMML – Kogito at Work

In a previous post (Shopping recommendations in PMML) we built the main infrastructure for making personalized shopping recommendations depending on the customer shopping history. The companion project was meant to demonstrate a standalone implementation of the Trusty-PMML engine.

In this post, we will show how to invoke the engine on a remote Kogito instance.

Kogito is designed from the ground up to run at scale on cloud infrastructure, which means it is dedicated to developing cloud-native applications. A Kogito service may be deployed as a standalone microservice or inside a container, like Kubernetes. Besides that, its native compilation makes it extremely fast.

The overall architecture and design of theKogito environment are out of the scope of the current post: the reader may find full documentation here.

Kogito setup

A detailed explanation of how to create and run a Kogito service is out of scope from the current post. Again, the reader may refer to official documentation. Simply put, the following three steps are required:

  1. create a Maven project with Kogito dependencies
  2. add the model file (cluster_buyer_predictor.pmml in our case) in the “resources folder
  3. start the Kogito service (we will use Quarkus environment in this post)

We will call the project "kogito-pmml-recommender", and sources are available here.

After issuing the command

mvn clean compile quarkus:dev

to service will be up and running, listening on port 8080. The endpoint for our model will be "KMeans" (the name of the model as defined inside cluster_buyer_predictor.pmml)

More details about usage ofTrusty-PMML inside Kogito may be found here.

REST invocation

It is possible to use the REST API to actually invoke the running engine, sending a POST request. The JSON content of such a post should contain the input data for the Trusty-PMML engine. As we may recall from the previous post, such data is a 30-sized array of doubles with only "0.0" or "1.0". This is an excerpt of that json:

{
  "0": 0.0,
  "1": 1.0,
  "2": 0.0,
  ...
  "28": 0.0,
  "29": 1.0
}

Request details are:

POST http://localhost:8080/KMeans
Content-Type: application/json

and curl equivalent is:

curl -X POST -H 'Accept: application/json' -H 'Content-Type: application/json' --data @commands/ClusterBuyerPredictor.json 'http://localhost:8080/KMeans

(the above curl invocation requires a "ClusterBuyerPredictor.json" file with the content listed before).

The companion project already contains the Json file.

Java-client invocation

Kogito services are exposed as standard REST endpoints, so the java client application simply needs to use an HTTP Client.

The kogito-pmml-recommender-client project is a modified version of the recommender-engine we saw in the previous post, with the only difference being that it features the HTTP client to retrieve predictions with a remote invocation to the Kogito service. As a matter of fact, there are only a couple of required modifications:

  1. fix dependencies inside pom, i.e. remove compilation-related ones
  2. modify the PMMLUtils class to use the http client to make a remote invocation.

Sum up

In this post, we have tackled a real-world recommendation scenario using the PMML and Trusty-PMML engine inside a Kogito microservice.

First, we have created a Kogito service project, basically containing only the cluster_buyer_predictor.pmml.

Then, we have provided a brief explanation on how to make a simple HTTP request to it.

Last, we have shown a bare-bone java project that, featuring a standard java HTTP client, is able to provide reliable recommendations.

But this is just to scratch the potentialities that the couple Trusty PMML + Kogito may offer.

This post explains how to use Kogito inside Kubernets, while this guide shows how to deploy a Quarkus microservice as AWS lambda.

Stay tuned!

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments