In this article
Introduction
dropdown icon
Business Rules Engine Implementation
    dropdown icon
    Before you begin
      Configure a BRE DataSync instance
    Accessing the BRE application
    Creating a set of rules
    dropdown icon
    BRE Request
      General Settings
      Query Parameters
      Parse Settings
      Decryption Settings
      Output Variables
    Creating a Flow with BRE Request Activity
    Frequently asked questions
    dropdown icon
    Configure ANI-Based Customer Data Lookups Using the Business Rules Engine
      Prepare the lookup data
Webex Contact Center Business Rules Engine User Guide
list-menuIn this article
list-menuFeedback?

The Business Rules Engine (BRE) in Webex Contact Center enables customers to upload specific data that the system can access during runtime to make routing decisions or display information to call agents.

Introduction

Cisco© Business Rules Engine is an application that helps in quick data lookups with in the Webex Contact Center. Using Cisco© Business Rules Engine (BRE), you can perform data lookups, custom routing and general implementation . The system retrieves the data at run time and uses it for routing decisions or displaying information to the agent.

For example, a tenant wants to route calls to a specific group of agents based on the Automatic Number Identification (ANI) dialed. In this scenario, the tenant can simply upload a list of ANIs. If the ANI of the incoming call is on that list, the system routes the call to the specified group of agents. If the ANI is not on the list, the system routes the call to the general queue.

A typical BRE implementation involves these major components:

  • BRE DataSync: The BRE DataSync configuration utility provides an interface for defining the Data Sync instances to import data into the BRE database. After the tenant defines the Data Sync instance, the tenant can upload a CSV file. The system converts the uploaded comma-separated value data into records in the BRE database.

  • Business Rules Engine: The business Rules Engine utility provides an interface for creating domains and rule sets. The BRE requires an incoming decision request to be associated with a domain. The domain contains a set of rules. Each rule is assigned a priority. The BRE tries to match the domain’s highest priority rule with the decision request based on the conditions in the rules.

  • Flow Designer: A drag-and-drop user interface used to define flows that orchestrate and automate the components of the Webex Contact Center. You can create a flow that invokes the BRE activity to perform a simple data lookup similar to the HTTP Request activity. However, in this case, the data resides within the Webex Contact Center.

Data Handling Guidelines

To maintain the integrity and security of the BRE, you must comply with the following data handling guidelines:

  • Permissible Data Types: Upload data that is essential for the operation and functionality of the BRE. This includes, but is not limited to, business rules, configurations, and non-sensitive operational data.

  • Restriction on PII: Do not upload any Personally Identifiable Information (PII) to the BRE except for the ANI data. PII includes, but is not limited to:

    • Full names
    • Social security numbers
    • Email addresses
    • Physical addresses
    • Financial information

ANI data refers to the telephone number associated with the calling party. ANI data is the only type of PII that is permissible for uploading to the BRE. This exception is to support specific business functionalities that rely on ANI data.

Business Rules Engine Implementation

Business Rules Engine consists of a real-time rules engine that gets invoked by the flow associated with an entry point. This rules engine typically consults with a data repository to assess the desired call handling.

A BRE lookup is a simple data dip within your flow, like a HTTP Request. However, the data for BRE lookup resides within Cisco Webex Contact Center Data center. The following image shows the various processes involved in the BRE data lookup.

Before you begin

Before you implement BRE:

  • Configure the BRE DataSync instance for your implementation with a clear understanding of the data model.
  • Get familiar with the following terminologies used throughout this guide:
    • Attribute: An attribute is a named variable or data field created within the BRE utility. It serves as a container for information that the BRE uses to process requests and generate outputs.
    • Context: A context is primarily used as an example name for an attribute that specifies the targeted domain for a BRE Request activity.
    • Label: A Label is a specific type of attribute that is designed to hold the output or result of a rule's evaluation.

See the FAQ section for more details.

Configure a BRE DataSync instance

The BRE DataSync utility accesses a database to make routing decisions. Ensure to periodically update the database with the appropriate information. This section describes how to configure the BRE DataSync utility to update the BRE repository.

Diagram for how the BRE DataySync utility is configured to update the BRE repository. BRE DataSync > CRUD > BRE Repository.
BRE DataSync utility

The tenant administrator must create a BRE DataSync instance for every data set that the Rules Engines consult's during its decision-making process. The administrator can create the data set or upload a CSV file. The data is converted into records in the BRE repository.

Before you begin

Contact Cisco Customer Service Account Manager to get access to the BRE DataSync account.

BRE DataSync is currently enabled only for Full Administrator role. Tenants with the Full Administrator role can upload data either using the CSV file upload or key-value pairs. Users with this role can upload only their organization-specific data.

Partner Administrator, External Administrator, Agents, and Supervisors don't have access to the BRE DataSync utility.

1

As an administrator, log in to the BRE DataSync utility.

In compliance with the recent enhancements in BRE Hosting and Scalability, the URLs for the DataSync utility have changed. Ensure to use the updated URLs to upload data into BRE.

2

Select BRE Data List to view all the information that is related to the tenant organization.

3

To add data as key-value pairs to the BRE repository: Select Add BRE Data

  1. Select the organization name from the TenantName drop-down list.

  2. Select the BRE Lookup Type from the drop-down list.

    See the following sizing limitations for adding BRE Lookup Type:

    • Maximum character limit for BRE Lookup Type: VARCHAR(200)
    • Maximum character limit for value field: VARCHAR(500)
    • Maximum number of Lookup Types per organization: 100
    • Maximum number of rows per Lookup Type: 100K row
    • Maximum file size limit for upload: 10 MB

    Contact Cisco Customer Success Manager or Solution Assurance Contact to add new lookup types.

  3. Click Add Data to enter the Key and Value.

  4. (Optional) Click Remove to delete an existing Key and Value.

  5. Click Submit.

4

To upload a CSV file to the BRE repository: Select Upload BRE CSV Data .

  1. Select the organization name from the TenantName drop-down list.

  2. Select the BRE Lookup Type from the drop-down list.

  3. Select Upload to browse and upload the CSV file.

  4. Click Submit.

    Sample CSV file for the BRE CSV data upload. Column headers are 'ANI', 'Extension', and 'Action'.
    Sample CSV file with data
    The actions Delete, Update, and Add aren't case-sensitive. You can also use the syntax 725160001,,Delete to delete the data.

Accessing the BRE application

You can access the Business Rules Engine application from the Webex Contact Center administration portal.

  1. Sign in to the Webex Contact Center administration portal.
  2. Click Business Rules to open the Business Rules Engine dashboard.

    BRE uses identity service and a Single Sign-On interaction. If you're already signed in through Common Identity, you can access the BRE utility for your organization without signing in again.

The system opens the Business Rules Engine (BRE) application in a new browser tab. The Dashboard page appears with a graphical representation of the number of rules and executions.BRE Dashboard

Creating a set of rules

Diagram of the Business Rule Engine utility being invoked by a flow in Webex Contact Center. Flow control in Webex Contact Center Flow Designer > Lookup Request > Cisco BRE > Read > BRE Repository.

Access the BRE portal and configure the Attribute, Label, Context and Rules, as described below.

1

To create an attribute to associate with your organization:

  1. Select Attributes and click Add on the Attributes page.

  2. Enter context in the Name field.

  3. Select the Data Type as Text from the drop-down list.

    The data type has to be Text in the BRE utility.

  4. Click Save.

2

Label adds meaning to your data. To create a Label:

  1. Select Labels and click Add on the Labels page.

  2. Enter a name for the label in the Name field .

  3. Click Save.

3

Click Contexts to navigate to the Contexts page. Click +Add Context.

  1. Enter Name which is the Generated Context in the BRE Data List.

  2. Enter an optional Description.

  3. If more than one attribute is created, select the attribute you want to associate with this context from the Attribute drop-down list.

  4. Click Save.

4

To create rules, navigate to the Contexts page. Click +Add Rule Editor and configure the following details:

  • Name: Provide a name for the rule.
  • Description: An optional description of the rule.
  • Active: Check the check box to specify that the rule is active.
  • Label: Choose the required label from the drop-down list.
  • Priority: Drag the slider to assign a priority to the rule. The system runs the rules based on the assigned priority, from highest (100) to lowest. It's recommended that you start assigning priorities from 100 in the descending order.
  • Rule Editor (tool to enter code, as shown in the screenshots below): Enter the code for the rule.

Create two rules: one if the system finds a match and the other when the system does not find a match.

The following example code returns the value for an attribute named routeInfo. This occurs if the number that the caller dialed from (ANI) matches the ANI on the list of tenants that are uploaded to the BRE database. Copy and paste the following rule in the Rule Editor:
when
c: Contact()
eval(c.getGlobalValuesManager().getAsString( c.getTenantId(),
c.getAttribute("context")+"."+
c.getAttribute("ani")) != null)
then
c.putAttribute("routeInfo",
c.getGlobalValuesManager().getAsString(c.getTenantId(),
c.getAttribute("context")+"." + c.getAttribute("ani")));
end
BRE Contexts page with an example code returns value for ANIFound for attribute routeinfo.

The following example code returns the value NotFound for the attribute routeInfo. This occurs if a number that the caller dialed from (ANI) doesn't match an ANI on the list of tenants that are uploaded to the BRE database. Copy and paste the following rule in the Rule Editor:

when
c: Contact()
eval(c.getGlobalValuesManager().getAsString( c.getTenantId(),
c.getAttribute("context")+"." + c.getAttribute("ani")) == null)
then
c.putAttribute("routeInfo", "NotFound ");
end

BRE Contexts page with an example code returns value for ANINotFound for attribute routeinfo.
5

Click Save.

BRE Request

Use the BRE Request activity to retrieve the data from your organization's Business Rules Engine (BRE) to use in the flow. The BRE Request activity uses standard HTTP protocols to fetch data from the BRE.

The following sections enable you to configure the BRE Request activity:

General Settings

Parameter

Description

Activity Label

Enter a name for the activity.

Activity Description

(Optional) Enter a description for the activity.

Query Parameters

As part of the BRE Request, you can pass the parameters that are provided in the API call to the BRE. In the Key‐Value columns, you can enter the key for the query and the associated value to send along with the query. You can also use the double curly braces syntax to pass variable values.

The BRE activity has one predefined Query Parameter: context. This query parameter is passed in the API call to the BRE.

The TenantID is automatically injected as a parameter and does not need to be configured.

Table 1. Query Parameters

Parameter

Description

Context

Contains the reason for the request. This mandatory parameter can't be edited or deleted.

This parameter must contain the same value as the value specified in the Attribute context in BRE. For more information, see the Creating a Set of Rules section in the Cisco Webex Contact Center Business Rules Engine User Guide.

ANI

Contains the originating phone number of the call. This is a default parameter that you can edit or delete, based on the rules configuration in the BRE.

A sample value for ANI is {{NewContact.ANI}}

Response Timeout

Specifies the connection timeout for the BRE Request. Default is set at 2000 milliseconds.

Number of Retries

Specifies the number of times the BRE Request is attempted after failure.

This parameter is used if the status code is 5xx; for example, 500 or 501.

To add a query parameter, click Add New. This adds a row where you can enter the key value pairs. You can add as many query parameters as required as part of the BRE Request.

Parse Settings

This section enables you to parse the response from the BRE Request into different variables:

Parameter

Description

Response Variable

Choose a variable to which you want to extract a particular section from the BRE Request response object. You can choose only Custom Flow variables from the drop-down list.

Path Expression

Define the Path Expression for parsing the response object. Depending on the kind of data structure of the response object and the use cases for extracting a subset of that information, the Path Expression varies.

Data is normalized to an object hierarchy before Path Expression execution, so JSONPath is used in the response object regardless of the configured Content Type.

Decryption Settings

You can decrypt the output variables of the BRE Request activity. If decryption is enabled at the flow level, users with debug decryption access can view the unmasked output values of the BRE Request activity in the flow debug logs. Turn off the Enable decryption toggle to disable decryption at the activity level for additional protection.

Output Variables

The BRE Request returns two output variables:

  • BRERequest1.httpResponseBody: Returns the response body for the BRE Request.

  • BRERequest1.httpStatusCode: Returns the status code of the BRE Request.

    These response codes are classified into the following categories:

    • Informational responses (100–199)

    • Successful responses (200–299)

    • Redirects (300–399)

    • Client errors (400–499)

    • Server errors (500–599)

Content Type Formats

The following examples describe sample input Content Type formats and the JSON response.

Content Type XML

Use this tool to convert XML into JSON format https://codeshack.io/xml-to-json-converter/.

XML Input Format:

<note>
  <to>Tove</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Test application</body>
</note>

Data/JSON Normalized Response

{
   "note": {
      "to": "Tove",
      "from": "Jani",
      "heading": "Reminder",
      "body": "Test application"
   }
}

Example JSON Path Expression: Use $.note.from to get the value as Jani.

Content Type TOML

Use this tool to convert TOML to JSON format https://www.convertjson.com/toml-to-json.htm.

TOML Input Format:

title = "TOML Example"
[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00

Data/JSON Normalized Response

{
   "title": "TOML Example",
   "owner": {
      "name": "Tom Preston-Werner",
      "dob": "1979-05-27T15:32:00.000Z"
   }
}

Example JSON Path Expression: Use $.owner.name to get the value as ‘Tom Preston-Werner’.

Content Type YAML

Use this tool to convert YAML to JSON format https://www.convertjson.com/yaml-to-json.htm.

YAML Input Format:

# An employee record
martin:
  name: Martin D'vloper
  job: Developer
  skill: Elite

Data/JSON Normalized Response

{
   "martin": {
      "name": "Martin D'vloper",
      "job": "Developer",
      "skill": "Elite"
   }
}

Example JSON Path Expression: Use $.martin.job to get the value Developer.

Content Type JSON

Use the JSON Expression Evaluator https://jsonpath.com/.

JSON Input Format:

{
   "martin": {
      "name": "Martin D'vloper",
      "job": "Developer",
      "skill": "Elite"
   }
}

Data/JSON Normalized Response

{
   "martin": {
      "name": "Martin D'vloper",
      "job": "Developer",
      "skill": "Elite"
   }
}

Example JSON Path Expression: Use $.martin.job to get the value Developer.

Creating a Flow with BRE Request Activity

You can create flows using the Flow Designer interface available in the Webex Contact Center. Create a flow with the BRE Request activity in the Webex Contact Center Flow Designer.

For more information about configuring the flow, see the BRE Request.

Frequently asked questions

  1. What is the purpose of an attribute?

    Attributes are fundamental for linking incoming BRE lookup requests to specific rule sets defined within BRE, and for storing the results of rule evaluations.

  2. How do you create attributes?

    Create attributes under Provisioning > Attributes in the BRE utility. For example, you might create an attribute named context.

  3. What is the purpose of a context?

    Context defines the specific scenario or lookup type that BRE applies. When a flow invokes the BRE Request activity, it needs to tell the BRE which set of rules to evaluate. An attribute, often named Context is set to the name of the specific domain.

  4. What is a domain?

    A domain is the table within BRE that contains the relevant data. The domain's name guides BRE to the correct data and its corresponding rule set.

  5. What is a label?

    After BRE evaluates its rules, it must communicate the outcome back to the calling system (for example, a Webex Contact Center Flow containing BRE Request activity). Rules are configured to set the value of a designated label attribute based on their conditions.

  6. What is the relationship between an attribute, context, and a label?

    You can create an Attribute, for example, named context. You can associate this attribute with a domain (the actual table like ANILookup). When invoking the BRE Request activity, the flow sets the value of this attribute (that is, domain = ANILookup) to specify the context (which domain's rules to use).

    Within that domain, rules are written in Drools Syntax to evaluate conditions and set the value of another attribute, often referred to as a label (for example, label = "MatchFound"). This represents the rule's outcome that is returned as a Response to the Flow.

  7. How are attributes, contexts, and labels related to query parameters of the request?

    The BRE is invoked by a Flow, typically through an API call (BRE Request activity) to a hardcoded internal URL. This is a REST API that enables lookup of BRE values uploaded in CSV (key/value pairs). The data required for the BRE to make a decision is passed as part of this request, similar to how query parameters or a request body would function in a regular REST API call.

    • Input Data: Information from the incoming call (like the caller's ANI, account number, and other similar data) is captured as Call Associated Data (CAD) variables in the Webex Contact Center call flow.
    • BRE Configuration Data: Other necessary parameters, such as context and the attribute specifying the domain (e.g., domain = ANILookup), are also set as variables in the Flow's BRE Request node.
    • Request Variables: In the BRE Request step of the Flow, the CAD variables and configured variables are selected as variables in the BRE Request configuration. These variables are then sent to the BRE's execution backend engine.
    • Function: Essentially, the 'Request Variables' act as the 'query parameters' or input payload for the BRE. The BRE uses these incoming values to evaluate the conditions defined in its rules.

Configure ANI-Based Customer Data Lookups Using the Business Rules Engine

This sample work flow uses Business Rules Engine (BRE) to look up customer data using a caller's Automatic Number Identification (ANI), process the returned data in a Webex Contact Center flow, and display selected information in the agent desktop. The steps are described below:

Prepare the lookup data

Create a CSV file containing a unique lookup key and its associated data. For this workflow, the caller's ANI is used as the lookup key. Store one or more customer fields in the value column. Separate multiple fields with a pipe (|).

15551234567,VIP Customer|John Smith|Premium Queue|Toronto 15559876543,Standard Customer|Jane Smith|General Queue|Vancouver

In this example, column 1 contains the ANI and column 2 contains the customer type, customer name, queue, and location.

BRE is intended for read-oriented lookups, not as a transactional database for frequently updated individual records.

Create the BRE lookup type and upload data

Open the Webex Contact Center BRE Data Sync tool and select your tenant. If the required lookup type is unavailable, ask the operations team to create it. Use a descriptive name such as ANILookup. Record the generated context name because the BRE configuration and flow must use the same case-sensitive value.

To add a test record:

  1. Open Add Data.
  2. Select the tenant and ANILookup.
  3. Enter the ANI and its associated value.
  4. Submit the record.

To load the full dataset, open Upload BRE, select the tenant and lookup type, and upload the CSV file. Open BRE Data List and confirm that the records appear. Ensure that the ANI format in the CSV matches the format sent by the flow.

Launch Business Rules

Sign in to the Webex Contact Center administration portal, open Business Rules, and launch the BRE dashboard:

Create the context attribute:

  1. Navigate to Home > Attributes > .
  2. Add an attribute with the following values:
    • Name: context
    • Data type: Text
  3. Save the result attribute. The context attribute identifies the uploaded lookup dataset that the rule queries.
  4. Add a text attribute that represents the returned data. Give the attribute a meaningful name even when the returned value contains multiple pipe-delimited fields. Save the attribute. In this example, customerType is used as sample.
  5. Open Contexts and add a context. Enter the generated Data Sync context name, such as ANILookup, associate it with the context attribute, and save it. The context name is case-sensitive and must match the generated Data Sync context exactly.

Create ANI-found rule and ANI-not-found rule

Open the context and select Add Rule Editor. Name the rule ANIFound, activate it, and assign it a higher priority, such as 100. Add the following rule and save it:

when c: Contact() eval(c.getGlobalValuesManager().getAsString( c.getTenantId(), c.getAttribute("context") + "." + c.getAttribute("ani") ) != null) then c.putAttribute( "customerType", c.getGlobalValuesManager().getAsString( c.getTenantId(), c.getAttribute("context") + "." + c.getAttribute("ani") ) ); end

The rule combines the context and ANI to form the lookup key. When a matching value exists, it assigns the result to the customerType response attribute.

Add another active rule named ANINotFound. Assign it a lower, unique priority, such as 99. Configure the rule to set customerType to Not Found when no matching record exists, and save it. Do not assign the same priority to both rules.

Create the Contact Center flow

Open Flow Designer and create or open a test flow. Add a BRE Request activity at the point where the flow must retrieve the caller's information, and connect the activity to the appropriate flow path.

Normalize the ANI

If the uploaded keys omit the +1 country-code prefix, create a preprocessing expression that removes it from the ANI:

ANI.replace("+1", "")

Use the normalized value as the lookup key. Apply this transformation only when the stored values omit +1; the request value and uploaded keys must use the same format.

Configure the BRE Request

Configure the activity with the following values:

  • Context: ANILookup
  • Request attribute: ani
  • Request value: The normalized ANI
  • Timeout: 5 seconds
  • Retries: 3
  • Response attribute: customerType

Map the response to a string flow variable. The context selects the dataset, while ani supplies the individual record key.

Process a multi-field response

If BRE returns VIP Customer|John Smith|Premium Queue|Toronto, split the string by using an escaped pipe delimiter (\|). The resulting elements contain the customer type, customer name, queue, and location. Assign the required elements to separate flow variables. The demonstration extracts the final element, Toronto.

Configure the screen pop

Add or configure the agent-desktop screen-pop activity. Map the extracted customer information to the required screen-pop field, connect the flow to the queue or agent-routing path, and then save and publish the flow.

Test the demonstration

Place a call from an ANI that exists in the uploaded dataset. Confirm that the flow normalizes the ANI, the BRE Request follows its success path, and the extracted information appears in the agent desktop. Repeat the test with an ANI that is not in the dataset and confirm that the not-found path returns the configured fallback value.

Was this article helpful?
Was this article helpful?