Many of our clients utilize InRule for data preparation, data cleansing and ETL processing. Recently, we’ve seen a rise in demand in this area so we thought we’d detail how InRule can be used for this scenario.
Before we get going, I want to provide a quick overview of ETL: ETL stands for Extract, Transform and Load. ETL solutions pull data in from multiple sources, cleanse and shape that data before it is finally compiled into a singular source. Once the data is in this singular repository, it can be used for a variety of different applications and functions.
Import the Schema
The first step in every rule application is to import the schema (you can also make it from scratch). irAuthor imports multiple formats including JSON. While using “Studio 3T” for MongoDB, we can browse our JSON documents.
When we right click on one of these documents, we can use a menu option to display the document view. For this rule application, we’ll select the “Mongo export Format,” select the JSON and place it into the clipboard.
Next, we’ll paste the JSON into irAuthor’s import schema dialog. When we’re done, we can see we were able to pull the schema into our rule application.
From here, we can write business rules against the imported entities. In our example, we have a rule checking the loan balance. The challenge was to reason against the customer’s state of residence and the balance of their loan. If the customer’s state of residence is in WA, CA, OR and the net balance of the loan is less than or equal to $1000, then set the status of the loan to near payoff and fire a notification with a friendly message.
Next, we test this rule using irVerify to ensure that our notification fires and the status of the loan is set properly. We can see below that this is true. If this rule application matured further, we would typically swap out the notification for an action that would drive a specific customer interaction.
Package the Rule Application
Once we have selected the features we want in the package, we can click “Package.” The service returns the requested JS file that we deploy. It’s completely portable; we can deploy it to a file system, a mobile device or even wrap it into a service. Below is what it looks like when I open it up in an editor. Note that it offers instructions on how to call the decision.
The next step is to integrate. For our purposes, we have written some JS code (Node.JS) that loops through all our JSON documents in MongoDB and then pushes the results to a new collection. We can look at what the code is doing below.
Note above that the entity state is retrieved from a MongoDB collection and each item is asserted to the engine without any modification or serialization steps. This reduces a lot of code and will perform better in the long run.
We can see what the execution of our rules looks like when we run it from the command prompt. The Node.JS process iterates throughout all the loans making decisions, firing notifications, and giving us feedback for errors.