模板开发示例
本节提供了一些示例，这些示例说明了规则开发人员可以在“模板开发”选项卡中配置的内容。有关如何配置规则模板以与 Genesys Intelligent Workload Distribution (iWD) 解决方案一起使用的特定信息，请参阅 iWD 和 Genesys Rules System 指南。
示例 1：条件与操作
年龄范围条件
如果客户的年龄在特定范围内，则将指定特定的座席组。在这种情况下，条件是客户的年龄是否落在该范围内。在 Genesys Rules Development Tool 中，条件将配置如下：
Name: Age Range
Language Expression: Customer’s age is between {ageLow} and {ageHigh}
Rule Language Mapping: Customer(age >= '{ageLow}' && age <= '{ageHigh}')
不要在规则语言表达式中使用单词“end”。这会导致规则解析错误。
下图显示了此条件在 GRAT 模板开发中的显示方式。
呼叫者条件
除了测试 Caller 是否存在之外，下一个条件还创建了 $Caller 变量，该变量将被操作用来修改 Caller 事实。修改后的呼叫者将在评估请求的结果中返回。
您不能在规则中多次创建变量，并且如果未在条件中定义变量，则不能在操作中使用变量。
Name: Caller Language Expression: Caller exists Rule Language Mapping: $Caller:Caller
下图显示了此条件在 GRAT 规则开发中的显示方式。
目标座席组操作
可以按以下方式配置操作：
Name: Route to Agent Group
Language Expression: Route to agent group {agentGroup}
Rule Language Mapping: $Caller.targetAgentGroup='{agentgroup}'
下图显示了此操作在 GRAT 规则开发中的显示方式。
参数
此示例中的条件有两个参数：
- {ageLow}
- {ageHigh}
该操作具有 {agentGroup} 参数。参数编辑器快照显示了一个示例 {ageHigh} 参数。
===运作原理===。
前面示例的运作原理如下：
- 规则开发人员创建一个事实模型（或者事实模型可以作为特定 Genesys 解决方案开箱即用的规则模板一部分包含在内）。事实模型描述了 Customer 事实和 Caller 事实的属性。在这种情况下，我们可以看到 Customer 事实具有称为 age（可能是整数）的属性，而 Caller 事实具有称为 targetAgentGroup（很可能是字符串）的属性。
- 规则开发人员创建 ageLow 和 ageHigh 参数，这些参数将成为业务用户在编写使用该规则模板的业务规则时将要填写的可编辑字段。这些参数的类型为输入值，其中值类型可能是整数。规则开发人员可以选择输入最小值和/或最大值来限制业务用户将能够输入的可能值。
- 规则开发人员还会创建 agentGroup 参数，该参数很可能是一个可选列表，向业务用户显示从 Genesys Configuration Server 或外部数据源提取的值下拉列表。此参数的行为取决于规则开发人员选择的参数类型。
- 规则开发者如前所述创建一个规则操作和规则条件。操作和条件包括规则语言映射，这些规则语言映射根据作为（来自 SCXML 应用程序等客户端应用程序的规则评估请求的）一部分传递给规则引擎的信息，指示规则引擎使用或更新哪些事实。
- 规则开发人员将规则模板发布到规则存储库。
- 规则作者使用此规则模板创建一个或多个业务规则，这些业务规则利用组合中描述规则作者要强制执行业务逻辑所需的条件和操作。在这种情况下，前面描述的条件和操作可能会在单个规则中一起使用，但是条件和操作也可以与其他可用条件和操作组合以创建不同的业务策略。
- 规则作者将规则包部署到规则引擎应用程序服务器。
- 诸如 VXML 或 SCXML 应用程序之类的客户端应用程序将调用规则引擎并指定要评估的规则包。向规则引擎发起的请求将包含事实模型的输入和输出参数。在此示例中，它必须包括客户事实的 age 属性。该属性可能是在调用规则引擎之前通过 GVP 收集的或从客户数据库中提取的。 根据作为规则评估请求的一部分传递到规则引擎中的 Customer.age 事实属性值，规则引擎将评估已部署的特定规则集。在此示例中，它将评估 Customer.age 是否落在规则作者在规则中指定的上下范围之内。
- 如果规则引擎认为该规则为 true，则 Caller 事实的 targetAgentGroup 属性将使用座席组的名称进行更新，座席组名称是业务规则作者在写入规则时选择的。 Caller.targetAgentGroup 属性的值将传递回客户端应用程序以进行进一步处理。在此示例中，也许 Caller.targetAgentGroup 的值将映射到 Composer 应用程序变量，然后将其传递到“目标”块，以要求 Genesys Universal Routing Server 将该座席组作为目标。
示例 2：函数
函数用于更复杂的元素，并在 Java 中编写。在此示例中，该函数用于比较日期。可以按以下方式配置：
Name: compareDates
Description: This function is required to compare dates.
Implementation:
import java.util.Date;
import java.text.SimpleDateFormat;
function int _GRS_compareDate(String a, String b) {
// Compare two dates and returns:
// -99 : invalid/bogus input
// -1 : if a < b
// 0 : if a = b
// 1 : if a > b
SimpleDateFormat dtFormat = new SimpleDateFormat(“dd-MMM-yyyy”);
try {
Date dt1= dtFormat.parse(a);
Date dt2= dtFormat.parse(b);
return dt1.compareTo(dt2);
} catch (Exception e) {
return -99;
}
}
对于用户提供的类，.jar 文件都必须位于 GRAT 和 GRE 的 CLASSPATH 中。
下图显示了此函数在 GRAT 规则开发中的显示方式。
示例 3：使用 JSON 对象
模板开发人员可以创建模板，使客户端应用程序可以将事实作为 JSON 对象传递给 GRE，而不必将每个字段明确地映射到事实模型。
本示例说明如何创建一个包含用于传递 JSON 对象的类（称为 MyJson）的模板。
开始
- 创建以下类并将其导入规则模板：
package simple; import org.json.JSONObject; import org.apache.log4j.Logger; public class MyJson { private static final Logger LOG = Logger.getLogger(MyJson.class); private JSONObject jsonObject = null; public String getString( String key) { try { if ( jsonObject != null) return jsonObject.getString( key); } catch (Exception e) { } LOG.debug("Oops, jsonObect null "); return null; } public void put( String key, String value) { try { if (jsonObject == null) { jsonObject = new JSONObject(); } jsonObject.put( key, value); } catch (Exception e) { } } } - 在模板中创建一个名为 (MyJson) 的虚设事实对象。
- 将 MyJson.class 添加到 GRAT 和 GRE 的类路径中。
- 创建以下条件和操作：
Is JSON string "{key}" equal "{value}" eval($MyJson.getString("{key}").equals("{value}")) Set JSON string "{key}" to "{value}" $MyJson.put("{key}", "{value}"); - 在 json.test 包内的规则中使用此条件和操作。将生成以下内容：
rule "Rule-100 Rule 1" salience 100000 agenda-group "level0" dialect "mvel" when $MyJson:MyJson() and ( eval($MyJson.getString("category").equals("test")) ) then $MyJson.put("newKey", "newValue"); end - 将 json.test 包部署到 GRE。
- 从 RESTClient 运行以下执行请求：
{"knowledgebase-request":{ "inOutFacts":{"anon-fact":{"fact":{"@class":"simple.MyJson", "jsonObject": {"map":{"entry":[{"string":["category","test"]},{"string":["anotherKey","anotherValue"]}]}}}}}}} - 生成以下响应：
{"knowledgebase-response":{"inOutFacts":{"anon-fact":[{"fact":{"@class":"simple.MyJson","jsonObject": {"map":{"entry":[{"string":["category","test"]},{"string":["newKey","newValue"]}, {"string":["anotherKey","anotherValue"]}]}}}}], "executionResult":{"rulesApplied":{"string":["Rule-100 Rule 1"]}}}}}
结束
示例 4：开发模板以启用测试方案
有关此主题的更多信息，请参阅 8.1.3 GRDT 帮助中的开发模板以启用测试方案。
将规则参数的多个实例映射到单个参数定义
在创建参数时，规则模板开发人员无需创建 ageLow 和 ageHigh 参数，可以如以下示例所示创建单个 {age} 参数并使用下划线表示法，以便创建索引应用于需要多个具有相同 (age)（常与范围一起使用）类型的参数实例的场景。例如： {age_1}, {age_2}....{age_n} 这些将成为可编辑字段。此功能最通常用于更有效地定义范围。
事实/条件
通过在事实名称前加上 $ 符号可以在条件和操作中引用事实。例如，事实 Caller 可以用名称 $Caller 来引用。GRS 将隐式地生成一个条件，该条件将变量 $Caller 与事实 Caller（即 $Caller:Caller()）相关联。
条件 $Caller:Caller() 需要一个 Caller 对象作为规则执行的输入，此条件才能评估为 true。