Exposing Business Rules as Microservices Through Chatbot and Cloud Functions

DZone 's Guide to

Exposing Business Rules as Microservices Through Chatbot and Cloud Functions

Learn how to externalize business rules as microservices in a central system using IBM Operational Decision Manager.

· Microservices Zone ·
Free Resource

Business rules management is always a concern for companies that deliver value and cannot rely on technology staff to change the rules embedded in monolithic applications or when the company wants to keep data within their knowledge base despite people turnover.

There is a class of solutions that provides a way to externalize business rules in a central system, enabling easy control of the rules' lifecycle and understandability. One of these tools is IBM Operational Decision Manager, a WebSphere Application Server-based solution descending from the former ILOG JRules solution. 

Rules in the Microservices World

Bringing this context to the microservices world, I proposed this small scenario below that shows how can we leverage existing decision services to be highly reusable, available, and integrated with artificial intelligence (AI) and API management solutions.  The role of AI in this demo is to provide a seamless interaction between the customer and the company in an unstructured way. AI can also provide contextual information inferred from the user input that Decision Service needs to accomplish its task. The compute part of this scenario uses IBM Cloud Functions, a FaaS framework powered by OpenWhisk. Such an approach enables the solution to increase processing power according to demand as OpenWhisk deals with addressing necessary compute resources for functions without user interaction.  The API Connect has the purpose of managing security, availability, and billing of decision service APIs to end users. This product comes with Elasticsearch, Logstash, snd Kibana stack to deliver actionable insights in real time from an API data source.

Image title

Use Case: Medical Examination Schedule Using a Chatbot

The processing is as follows:

  1. The user starts a chat on Facebook;

  2. A Facebook app is configured to use webhooks to interact via Cloud Functions with IBM Watson Assistant. Every message received is sent to IBM Watson, which handles the conversation according to the modeled intents and dialog;

  3. IBM Watson Assistant collects information from the user using Slots. Slots are a way to gather multiple pieces of information from a user at his pace. Details the user provides upfront are saved, and the service asks only for the details they have not provided. Once all data is available, IBM Watson calls the backend service using Cloud Function as well. The code below is an IBM Cloud function (FaaS) action that calls Decision Service through API Connect. 

var request = require("request");

function main(params) {

   var req = {
      "cliente": {
        "peso": params.p,
        "altura": params.a,
        "sexo": params.s,
        "idade": params.i
      "questionario": {
        "exame": params.exame,
        "perguntas": []
   var options = {
      method: 'POST',
      url: 'https://api.us.apiconnect.ibmcloud.com/luizyanaigmailcom-dev/sb/odm/dev/DecisionService/rest/AgendarExameService/1.0/ConsultarQuestionario/1.0',
      headers: {
          'Content-Type' : 'application/json',
          'Accept' : 'application/json',
          'Authorization' : 'Basic dGVzdGVyLmZpZEB0MTEyODorK25pZVlsS3JZK2llVXpSZ2gzMWVFRzFPS2czRTlhM3VZaFZwSkd4'
      json: true
   return new Promise(function (resolve, reject) {
      request(options, function (err, resp) {
         if (err) {
            return reject({err: err});
      return resolve(resp.body);

This code uses Promise to send a parameterized JSON request through API Connect gateway (IBM Data Power). The parameters were obtained from the dialog context variables and passed to the Cloud Functions using the following web action call.

  "output": {
    "text": {
      "values": [
        "Vamos lhe fazer algumas perguntas. Ok?"
      "selection_policy": "sequential"
  "actions": [
      "name": "luiz.yanai@gmail.com_dev/package/consultarQuestionario.json",
      "type": "web_action",
      "parameters": {
        "a": "<? context['Altura'] ?>",
        "i": "<? context['Idade'] ?>",
        "p": "<? context['Peso'] ?>",
        "s": "<? context['Sexo'] ?>",
        "exame": "<? context['Exame'] ?>"
      "result_variable": "context.retorno"

The decision service handles the request and returns the results of applying a list of business rules defined on decision tables or BAL (business action language) as follows:

Image title

 API Connect applies security over all the API transactions using a clientId/clientSecret mechanism or OAuth flows, and also provides information about the performance and usage.

Image title

Business Rules as Microservices

Business Rules implemented in IBM WebSphere Operational Decision Manager have many characteristics similar to microservices:

  • There is a team of developers working on the application (for each business area).
  • The application must be easy to understand and modify (IBM ODM uses BAL and other rule artifacts that are easy to understand for non-IT staff).
  • You want to practice continuous deployment of the application (IBM ODM provides build tools for distributing the decision service and can be integrated with a CI/CD pipeline).
  • You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements (decision services are stateless so multiples copies can be deployed).

This proposed topology exploits this synergy with microservices and adds extra value, aggregating AI features and API monitoring. 

This demo is available on GitHub for further reference.

ai ,api gateway ,brms ,chatbot analytics ,faas ,microservices ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}