Rules as a Service

Quantum Fabric provides the ability to write business rules in a simplified text form by using the Rules-as-a-Service feature. The Rules service makes defining business logic closer to human language and is built using MVEL. Instead of embedding rules within Fabric integration services, with Rules as a first-class service, the business logic and conditions are externalized and can be managed separately. For example, let’s say in a Banking app there could be certain business rules defined to control whether a customer is eligible for a loan. However, these business rules for loan eligibility (like credit score and income level) might vary from time to time based on market conditions, bank’s promotional offers, and regulatory changes. In such cases, Fabric Rules-as-a-Service provides the ideal design to abstract these business rules from other application logic and manage them separately. This also provides Rules-as-a-Service all the capability of any Fabric service including versioning, export, import across Fabric apps, API management.

You can use the Rules service tab to define and store your business logic as a set of rules. A collection of rules defined in a Rules service are stored in a Ruleset. For example, a Loan Ruleset can have multiple rules such as Home Loan Rule, Education Loan Rule, Vehicle Loan Rule and so on. Similar to how any Fabric service operation can be protected by Operation security levels, rules in a Ruleset can also be protected by Rule Security Level. These are: Authenticated App Users, Anonymous App Users, Public, and Private.

How Rules as Service Works

Rules in a Rules service are not dependent on any back-end system and are executed within the Quantum App Server. So, rules defined as a service are dependent between a client app and a Fabric app. The rules can be changed for a particular app and republish the app as required. Based on request input parameters in a request sent to a Fabric app, a set of conditions in a particular rule will be evaluated and the corresponding action will be performed whenever the condition matches. And, then Quantum App Server sends the response to the client.

Why and When to Use Rules-as-a-service

When you are creating an application that has a significant portion of business logic/rules that need to be managed/modified from time to time, define those business logic as separate rules service in your Fabric application. The following are some of the sample use cases where you can use Rules-as-a-service: 

  • For Banks and financial institutions when they want to develop lending apps – to abstract Rules determining Loan eligibility
  • For Retail and e-commerce institutions when they want to separate out promotional campaigns – which can then be modified seasonally
  • For Insurance providers when they evaluate if a potential new customer meets eligibility requirements

Use Case:

A bank app with a set of rules defined as a Rules service in a Fabric app is published. A user of this client app sends request to the app to check loan eligibility. The request may contain input params, which can be used to evaluate the condition in Rules, for example, the condition is: Credit Rating between 300 and 669, credit length less than 5. Quantum App Server executes the logic defined in the rules service in the app based on the input params (creditRatingand creditLengthInYears), and then sends the desired response.

The following table details client requests and Fabric Server responses executed based on a sample rule.

Step 1 

Client App

A user sends requests with Input Params
to the published Fabric app
as follows:

Step 2

Fabric App with Rules Service published to Quantum App Server

a. Quantum App Server executes the logic defined in the Rules service b. Quantum App Server sends the Response to the client app
  • creditRating = 300 or 669
  • creditLengthInYears = 5

Sample rule

name: "Credit Rating between 300 and 669, credit length less than 5 "
								description: "Credit Rating between 300 and 669, credit length less than 5 "
								condition: "creditRating >= 300 && creditRating <= 669 && creditLengthInYears <= 5"
								actions:
								- "results.addParam(\"status\", \"Reject\")"
---
name: "Credit Rating between 300 and 669, credit greater than 5 " description: "Credit Rating between 300 and 669, credit greater than 5 " condition: "creditRating >= 300 && creditRating <= 669 && creditLengthInYears > 5 " actions: - "results.addParam(\"status\", \"Review\")"
---
name: "Credit Rating between 670 and 750, credit length less than 5 " description: "Credit Rating between 670 and 750, credit length less than 5 " condition: "creditRating >= 670 && creditRating < 750 && creditLengthInYears <= 5 " actions: - "results.addParam(\"status\", \"Approve\")" - "results.addParam(\"interestRate\", \"10\")"
---
name: "Credit Rating greater than 750, credit greater than 5 " description: "Credit Rating greater than 750, credit greater than 5 "
condition: creditRating >= 750 && creditLengthInYears > 5
actions:
- "results.addParam(\"status\", \"Approve\")"
- "results.addParam(\"interestRate\", \"5\")"
{
"opstatus":0,"status" : "Reject"
}
  • creditRating = 300 or 669
  • creditLengthInYears = 6
{
"opstatus":0,"status" : "Review"
}
  • creditRating = 670 or 740
  • creditLengthInYears = 5 or 6
{
"interestRate": "10"
"opstatus":0,"status" : "Approve"
}
  • creditRating = 750 or 880
  • creditLengthInYears = 5 or 6
{
"interestRate": "5"
"opstatus":0,"status" : "Approve"
}

What is the Structure of Rules: Rules have a structure in the form of statements, as shown in the following table:

Sample Rules Structure
name: "<Name of the rule>"
description: "<Description of the rule>"
priority: <Priority of the rule>
condition: "<Condition to evaluate>"
actions:
   - "<Set of actions to execute>"
Description of Rules Structure
  • Name: A unique name of the rule. This is a mandatory field.
  • Description: A description for the rule.
  • Priority: An integer value that represents the order to execute the rule. The bigger the value, the higher the priority.
  • Condition: An expression that is evaluated by the Rules engine. When the condition evaluates to True, the engine executes a set of actions. This is a mandatory field.
    For example, response != null can be used to check whether the back-end response is empty.
  • Action: A set of statements that are executed when the condition evaluates to True. This is a mandatory field.
    For example, statusCode = 200 sets status code to 200.

 

How to Create a Rules Service

To go to the Rules service tab from the Quantum Fabric Console dashboard, click Add New or select any existing Quantum Fabric app, and click the Rules tab. The Rules tab landing page appears. Creating a rules service involves two stages, a ruleset and rules. Rules defined in a Rules service are stored in a rules-set. A Ruleset is a collection of rules.

  1. Create theService definition for a Rules service.
    1. Click CONFIGURE NEW to create a ruleset. The following details are displayed in the Rules service designer.

    2. In the Name field, provide a unique name for your ruleset.
    3. NOTE: All options in the Advanced section are optional.

    4. Click SAVE & ADD RULE to save the rules definition (rules-set). A Rule List tab appears.
  2. Create Rules in a Ruleset.
    1. In the Rules List, click ADD RULE to add a new, if required.
    2. Provide the following details to create a Rule:
      FieldDescription
      NameThe rule name appears in the Name field. You can modify the name, if required.
      Rule Security Level

      The Rule Security Level specifies how the client must authenticate for invoking this rule

      NOTE: The field is set to Authenticated App User, by default.

    3. Configure your business rules logic in the Rule Logic text field. This field contains sample MVEL rule logic. You can modify as per your business requirement.
    4. NOTE: All options in the Advanced section for operations are optional.

    5. Enter the Description for the operation.
    6. Click SAVE RULE. Now, you can configure input request and response output for your rule. The following sections detail how to create input and output operations for rules.

Configure Request for a Rule

  1. In the Request Input > Body tab, do the following:
    1. Click Add Parameter button to create new entries for the input.

      NOTE: - To make duplicate entries, select the check box for the entry, click Copy, and then click Paste.



      - To delete an entry, select the check box for an entry, and then click the Delete button.

    2. Configure parameters in the client's body, do the following:
      FieldDescription
      NameIt Contains a Unique Identifier. Change the name if required.
      Value

      Select Request or Session. It is set to Request by default.

      1. Request indicates that the value must be retrieved from the HTTP request received from the mobile device.
      2. Session indicates that the value must be retrieved from the HTTP session stored on Quantum Fabric.
      3. Identity: If this is selected, you can filter the request parameters based on the response from the identity provider. For more details to configure identity filters, refer to Enhanced Identity Filters - Integration Services.
      TEST VALUEEnter a value. A test value is used for testing the service.
      DEFAULT VALUEEnter the value, if required. The default value will be used if the test value is empty.
      Datatype
      Encode

      Select the check box to enable encoding of an input parameter. For example, the name New York Times would be encoded as New%20York%20Times when the encoding is set to True. The encoding must also adhere to the HTML URL encoding standards.

      DescriptionProvide a suitable description.
  1. In the Request Input > Header tab, do the following:
    1. Click Add Parameter button to create new entries for the input.

      NOTE: - To make duplicate entries, select the check box for the entry, click Copy, and then click Paste.



      - To delete an entry, select the check box for an entry, and then click the Delete button.

    2. Configure parameters in the client's header, do the following:
      FieldDescription
      NameIt Contains a Unique Identifier. Change the name if required.
      Value

      Select Request or Session. It is set to Request by default.

      By default, this field is set to Request. Five different options are available in Quantum Fabric under Request Input > Headers > VALUE during configuration of any operation. When you start editing this field, dependent identity services are auto populated. These options primarily determine the source of the value of the header.

      • Request: If this option is selected, the Integration Server picks the value pairs from the client's request during run time and forwards the same to the back-end.

        User has the option to configure the default value. This default value is taken if the request does not have the header.

      • Session: If this option is selected, the value of header is picked from session context based on the user configuration.
      • Constant: Constant is used to configure the value that is picked and sent to back-end by the Integration Server during the run-time.
      • Expression: Select this option to configure the velocity template expressions for the header values.

        You cannot edit the default value for expression.

      • Identity: If this is selected, you can filter the request parameters based on the response from the identity provider. For more details to configure identity filters, refer to Enhanced Identity Filters - Integration Services.

        NOTE: If the header value is scoped as a Request (or) Session and the same header is accessed under the Expression header value, then the expression must be represented as $request.header (or) $session.header.



        Example: If a header 1 value is a request and header 2 value is an expression, then the value of the expression must be $Request.header1.



      TEST VALUEEnter a value. A test value is used for testing the service.
      DEFAULT VALUEEnter the value, if required. The default value will be used if the test value is empty.
      Datatype
      DescriptionProvide a suitable description.
  2. Click SAVE RULE to save the rule. The system updates the rule's definition.

Create Response for a Rule

  1. Click the Response Output tab, and enter the values for required fields such as name, path, scope, data type, collection ID, record ID, format, format value, and description.

    NOTE: If you define parameters inside a record as the session, the session scope will not get reflected for the parameters.

  2. Click SAVE RULE to save the rule. The system updates the rule definition.

    If you click Cancel, the Edit Service Parameters window will close without saving any information.

    NOTE: You can view the service in the Data Panel feature of Quantum Visualizer. By using the Data Panel, you can link back-end data services to your application UI elements seamlessly with low-code to no code. For more information on Data Panel, click here.

    NOTE: By using Visualizer SDKs, you can invoke the Rules in a Ruleset, similar to integration services. For more details on Fabric Integration Service SDKs, refer to Visualizer SDK > Invoking an Integration Service

 

Built-in Objects

The following objects help you to write rules in Quantum Fabric.

Objects Description
"configurationParameters"

Used to access the Server and Client App parameters that are set by the developer in the App Services console. This is equivalent to using ConfigurableParameters in Java.

"customMetrics"

This is used to access custom metrics.

For more details to create custom reports and Metrics, refer Custom Reporting – Metrics, Reports, and Dashboard Guide

“deviceHeadersMap”

Used to set headers that are passed to the client and is equivalent to using setDeviceHeaders in Java.

"headerMap"

Used to access the header map of a request. A client can directly access the header map or the individual key-value pairs of the header map.

“identityHandler"

Used to access the identity attributes when a service is protected by an identity service.

"inputMap"

Used to access the input map of a request. A client can directly access the input map or the individual key-value pairs of the input map.

"logger" Used to add a log statement with the appropriate level.
"response"

Used to modify the response body and is equivalent to using setResponse in Java.

"results"

Used to modify the results. The Result is a collection of Params, Data-sets, and Records. For more details, refer Result.

"resultCache"

Used to perfom read/write in the cache. This is equivalent to using ResultCache in Java.

"servicesManager"

Used to invoke any service with the specified service id, operation id and version.

"session"

Used to modify the session that is associated with the request.

For more details, refer Session

A client can access values from the session and the individual attributes of the session.

“statusCode” Used to set the status code of the response and is equivalent to using setStatusCode in Java.
"ua"

Used to access the User Agent Header of the request.

Built-in Functions

The following functions help you to write rules in Quantum Fabric.

Functions Description
"Check.isWithin"

Checks if an element is in a specified range. It will return true if the element present in the specified range, otherwise false.

  • Signature: isWithin(double fromInclusive, double toInclusive, double elementToFind)
  • Example
    Check.isWithin(100, 300, 250) = true
    Check.isWithin(100, 300, 350) = false
"Check.isEmpty"

Checks if a CharSequence is empty ("") or null.

  • Signature: isEmpty(final CharSequence cs)
  • Example
    Check.isEmpty(null)      = true
    Check.isEmpty("") = true Check.isEmpty(" ") = false Check.isEmpty("xyz") = false Check.isEmpty(" abc ") = false
"Check.isNotEmpty"

Checks if a CharSequence is not empty ("") and not null.

  • Signature: isNotEmpty(final CharSequence cs)
  • Example
    Check.isNotEmpty(null)      = false
    Check.isNotEmpty("") = false Check.isNotEmpty(" ") = true Check.isNotEmpty("xyz") = true Check.isNotEmpty(" abc ") = true
"Check.isBlank"

Checks if a CharSequence is empty (""), null or white-space only.

  • Signature: isBlank(final CharSequence cs)
  • Example
    Check.isBlank(null)      = true
    Check.isBlank("")        = true
    Check.isBlank(" ")       = true
    Check.isBlank("xyz")     = false
    Check.isBlank("  abc  ") = false
    
"Check.isNotBlank"

Checks if a CharSequence is not empty (""), not null and not white-space only.

  • Signature: isNotBlank(final CharSequence cs)
  • Example
    Check.isNotBlank(null)      = false
    Check.isNotBlank("")        = false
    Check.isNotBlank(" ")       = false
    Check.isNotBlank("xyz")     = true
    Check.isNotBlank("  abc  ") = true
    
"Check.isEqualTo"

Compares two CharSequences, returning true if they represent equal sequences of characters.

  • Signature: isEqualTo(final CharSequence cs1, final CharSequence cs2)
  • Example
    Check.isEqualTo(null, null)   = true
    Check.isEqualTo(null, "abc")  = false
    Check.isEqualTo("abc", null)  = false
    Check.isEqualTo("abc", "abc") = true
    Check.isEqualTo("abc", "ABC") = false
    
"Check.isEqualToIgnoringCase"

Compares two CharSequences, returning true if they represent equal sequences of characters, ignoring case.

  • Signature: isEqualToIgnoringCase(final CharSequence str1, final CharSequence str2)
  • Example
    Check.isEqualToIgnoringCase(null, null)   = true
    Check.isEqualToIgnoringCase(null, "abc")  = false
    Check.isEqualToIgnoringCase("abc", null)  = false
    Check.isEqualToIgnoringCase("abc", "abc") = true
    Check.isEqualToIgnoringCase("abc", "ABC") = true
    

Sample Rules