Jump to: navigation, search

Working with Composer's Business Rule Block

Summary

Once the Rule Packages (created from Rule Templates) that you want to work with are deployed to the Genesys Rules Engine, you can use the Business Rule block on the Server Side palette to create voice and routing applications that use business rules.

Use this block to have Composer query the Genesys Rules Authoring Tool (GRAT) for deployed packages. For the Rule Package that you specify, Composer will query the GRAT for the Facts associated with the Rule Package. You can then set values for the Facts, call the Genesys Rules Engine for evaluation, and save the results in a variable.

Simple Workflow

Composer1.png

In this typical workflow:

  1. The Identify Customer block is used to identify the customer based on certain search criteria, such as ANI.
  2. The Query Customer block is used to pull out the customer profile data.
  3. The Query Services block is called to pull any related services for this customer.
  4. The Query States block is called to pull the states related to a particular service.
  5. The Query Task block is called to pull the tasks associated with a particular service or state.
  6. The Business Rule block may be placed anywhere in the workflow/callflow, assuming the data needed for the rules called by the Business Rule block have already been fetched.
  7. The Assign block enables the workflow to access all the different decisions of the CM rule package. The decision(s) requested by the Business Rule block and made by the Rules Engine are returned to the workflow/callflow which carries them out. The GRS does not actually execute the decisions (e.g. update the customer profile, transfer to agent, an so on).

User Variables in the Workflow

In this example workflow, the following user variables have been defined to retrieve data necessary for, as well as demonstrate the various decisions made by, the CM rules.

Variable Name Default Value Expected Type Description
customer undefined JSON object Customer profile data as returned by Query Customer block.
services undefined JSON array Services of the customer as returned by Query Services block.
states undefined JSON array States of a particular service as returned by Query States block.
tasks undefined JSON array Tasks of a particular service or state as returned by Query Tasks block. (In Context Services, Tasks may be associated with service or state.)
contractEndDate undefined String Contract end date timestamp string in the format of 2014-07-14T13:23:35.392Z.
mediaType undefined String Media type of the current interaction.
businessRulesResultObject undefined JSON object Output of Business Rules block.
customerID undefined String ID of the customer as returned by Identify Customer block.
serviceID undefined String ID of a service of the customer to use in Query States and Query Tasks blocks.
stateID undefined String ID of a state of a service of the customer to use in Query Task block. (Not used when querying tasks associated with service.)
cmResults undefined JSON object Results from CM rules. This is extracted from businessRulesResultObject for easier access.
updatedFields undefined JSON object CM Rules decision: Customer profile fields to update. Each key-value pair of this object correspond to a contact attribute. This is extracted from cmResults for easier access later in the workflow.
offerServiceResumption false Boolean CM Rules decision: Whether to offer service resumption to customer. This is extracted from cmResults for easier access later in the workflow.
offerSurvey false Boolean CM Rules decision: Whether to offer survey to customer. This is extracted from cmResults for easier access later in the workflow.
blockCommunication false Boolean CM Rules decision: Whether to block further communication to customer. This is extracted from cmResults for easier access later in the workflow.
sendCommunication undefined String CM Rules decision: Which media type to use for further communication with customer. This is extracted from cmResults for easier access later in the workflow.
requestedAgent undefined String CM Rules decision: Which particular agent to route this customer to. This is extracted from cmResults for easier access later in the workflow.
requestedAgentGroup undefined String CM Rules decision: Which agent group to route this customer to. This is extracted from cmResults for easier access later in the workflow.
requestedPlaceGroup undefined String CM Rules decision: Which place group to route this customer to. This is extracted from cmResults for easier access later in the workflow.
requestedSkill undefined String CM Rules decision: Which skill to route this customer to. This is extracted from cmResults for easier access later in the workflow.

Query Customer Block

This is the Query Customer block. Note the Output: Result is stored in the user variable customer.

Block1.png

Query Services Block

The following is the Query Services block.

Block2.png

Notes:

  • The result Output—Service Data is stored in user variable services.
  • Query Criteria—Identifier is set to customerID, meaning we are querying services of the identified customer.
  • Query Criteria—Service Status is set to All to ensure both conditions for active services and completed services can be correctly checked.
  • Query Criteria—Service Type is not set, ensuring services of all service types are returned for service type-related rule conditions.
  • No Query Date Range is set, which is needed for date checking service conditions.

Query States Block

The following is the Query States block.

Block3.png

Notes:

  • The result Output—States Data is stored in user variable states.
  • Query Criteria—Service ID is set to serviceID, which should be previously extracted from Query Services results.
  • Query Criteria—State Status is set to All to ensure both conditions for active states and completed states can be correctly checked.
  • Query Criteria—State Types is not set, ensuring states of all state types are returned for state type-related rule conditions.
  • Since Query States may only fetch states of a single service, the current CM template expects all states supplied are associated with a single service. If states of multiple services are aggregated to a CM rule package, the rules may not behave as expected.

Query Tasks Block

The following is the Query Tasks block.

Block5.png

Notes:

  • The result Output—Task Data is stored in user variable tasks.
  • Query Criteria—Service ID is set to serviceID, which should be previously extracted from Query Services results.
  • Query Criteria—State ID is set to stateID, which should be previously extracted from Query States results. This field may be omitted when querying tasks associated with a service.
  • Query Criteria—Task Status is set to All to ensure both conditions for active tasks and completed tasks can be correctly checked.
  • Query Criteria—Task Types is not set, ensuring tasks of all task types are returned for task type-related rule conditions.
  • Since Query Tasks may only fetch tasks of a single service or state, the current CM template expects all tasks supplied are associated with a single service or state. If tasks of multiple services/states are aggregated to a CM rule package, the rules may not behave as expected.

Business Rules Block

Block6.png

Notes:

  • The Business Rule block is where GRS is invoked in the workflow/callflow. Before configuring this block, a rule package using the CM template should already be authored and deployed to GRE.
  • Business Rule Package is the name of the rule package. This is chosen from a list of all deployed rule packages on the GRE specified in Windows -> Preferences.
  • Output Result is copied to user variable businessRulesResultObject.
  • Facts brings up a list of all facts to send to GRE. See below for further detail.

Facts

_GRS_Environment

Fact1.png

The _GRS_Environment fact class is available to rules packages of all types, this fact class is for storing global environment variables.

com.genesys.brs.api.RulesResults

Fact class com.genesys.brs.api.RulesResults is a placeholder for storing results from GRE. It is required for CM rule packages. No value should be set for the data field.

Fact2.png

com.genesyslab.brs.api.CustomerProfile

Fact class com.genesyslab.brs.api.CustomerProfile provides the customer profile from Query Customer block to GRE. It is required only if customer-related conditions are used; otherwise it is ignored. If it is not provided, all customer-related conditions are considered failed.

In this example, the value of jSONObject is set to the user variable customer, which was previously populated by Query Customer block.

Facts3.png

com.genesyslab.brs.api.Services

Fact class com.genesyslab.brs.api.Services provides services from Query Services block to GRE. It is only required if service-related conditions are used; otherwise it is ignored. If it is not provided, all service-related conditions are considered failed.

In this example, the services field is set to the user variable services, which was previously populated by Query Services block.

Fact4.png

com.genesyslab.brs.api.States

Fact class com.genesyslab.brs.api.States provides the states from Query States block to GRE. It is required only if state-related conditions are used; otherwise it is ignored. If it is not provided, all state-related conditions are considered failed. In this example, the states field is set to the user variable states, which was previously populated by Query States block.

Fact5.png

com.genesyslab.brs.api.Tasks

Fact class com.genesyslab.brs.api.Tasks provides the states from Query Tasks block to GRE. It is required only if task-related conditions are used; otherwise it is ignored. If it is not provided, all task-related conditions are considered failed. In this example, the tasks field is set to the user variable tasks, which was previously populated by Query Tasks block.

Fact6.png

Interaction

Fact class Interaction provides the media type of the current interaction to GRE. It is required only if media type-related conditions are used; otherwise it is ignored. If it is not provided, all media type-related conditions are considered failed. In this example, the mediaType field is set to the user variable mediaType, which is not actually populated in previous blocks in the current workflow. In normal usage, the user variable for providing media type to this fact should either be pre-populated in a previous block, or hard-coded based on the workflow (for example, if this workflow is only executed for voice).

Fact7.png

Contract

Fact class Contract provides the contract end date of the user to GRE. It is only required if contract-related conditions are used; otherwise it is ignored. If it is not provided, all contract-related conditions are considered failed.

In this example, the contractEndDate field is set to the user variable contractEndDate, which is not actually populated in previous blocks in the current workflow. In normal usage, the user variable for providing contract end date to this fact should should be pre-populated in a previous block (for example, calculated based on service start date and pre-configured contract length, fetched from external services).

Fact8.png


ECMA Script Block

The purpose of this ECMA Script block is to extract the decisions/recommendations of the CM rule package from businessRulesResultObject (output of Business Rule block) into the user variable cmResults. It is not absolutely necessary, but as businessRulesResultObject contains all the input to the Business Rule block, and actual results of the CM rule package are buried in deep.

Fact9.png


Assign Block

The purpose of this block is to demonstrate how to access all the different decisions of the CM rule package. Notice all results are in the rule_results field of cmResults, and the updated_fields field of cmResults stores any customer profile updates.

In this example, the Boolean values are assigned either true or false even if the rule package did not make any decision. If the "=== true" part is removed, the value would be undefined if no decision was made by the rule package one way or another, which, depending on the situation, could be a valid branch for a Branching block.

Fact10.png

This page was last modified on February 19, 2015, at 10:43.

Feedback

Comment on this article:

blog comments powered by Disqus