Índice
Exemplos de desenvolvimento de modelos
Esta seção fornece alguns exemplos do que um desenvolvedor de regras pode configurar na guia Desenvolvimento de modelo. Para obter informações específicas sobre como os modelos de regras devem ser usados com a solução Genesys intelligent Workload Distribution (iWD), consulte o guia iWD e Genesys Rules System.
Exemplo 1: Condição e Ação
Condição de faixa etária
Se a idade de um cliente estiver dentro de um intervalo específico, um grupo de agentes específico será direcionado. Nesse cenário, a condição é se a idade do cliente está dentro do intervalo. No Genesys Rules Development Tool, as condições seriam configuradas da seguinte forma.
Name: Age Range
Language Expression: Customer’s age is between {ageLow} and {ageHigh}
Rule Language Mapping: Customer(age >= '{ageLow}' && age <= '{ageHigh}')
Não use a palavra 'end' em expressões de linguagem da regra. Isso causa erros de análise de regra.
A figura abaixo mostra como essa condição apareceria no desenvolvimento de modelos do GRAT.
Condição do autor da chamada
Além de testar a existência do autor da chamada, a próxima condição também cria a variável $Caller, usada por ações para modificar o fato do autor da chamada. O autor da chamada modificado retornará nos resultados da solicitação de avaliação.
Não é possível criar uma variável mais de uma vez dentro de uma regra e não é possível usar variáveis em ações se as variáveis não tiverem sido definidas na condição.
Name: Caller Language Expression: Caller exists Rule Language Mapping: $Caller:Caller
A figura abaixo mostra como essa condição apareceria no desenvolvimento de regras do GRAT.
Ação do grupo de agentes de destino
A ação seria configurada da seguinte forma:
Name: Route to Agent Group
Language Expression: Route to agent group {agentGroup}
Rule Language Mapping: $Caller.targetAgentGroup='{agentgroup}'
A figura abaixo mostra como essa ação seria exibida no desenvolvimento de regras do GRAT.
Parâmetros
A condição neste exemplo possui dois parâmetros:
- {ageLow}
- {ageHigh}
A ação possui o parâmetro{agentGroup}. A captura de tela do Editor de parâmetros mostra um exemplo de parâmetro {ageHigh}.
Como funciona
O funcionamento do exemplo anterior é o seguinte:
- O desenvolvedor de regras cria um modelo de fatos (ou o modelo de fatos pode ser incluído como parte de um modelo de regras pronto para uso com uma solução específica da Genesys). O modelo de fato descreve as propriedades do fato Customer e do fato Caller. Nesse caso, podemos ver que o fato Customer possui uma propriedade chamada age (provavelmente um número inteiro) e o fato Caller possui uma propriedade chamada targetAgentGroup (provavelmente uma cadeia de caracteres).
- O desenvolvedor da regra cria os parâmetros ageLow e ageHigh, que se tornarão campos editáveis que o usuário comercial preencherá ao criar uma regra comercial que use esse modelo de regra. Esses parâmetros seriam do tipo Input Value, onde o Value Type provavelmente seria um número inteiro. O desenvolvedor de regras pode tem a opção de restringir os possíveis valores que o usuário comercial poderá inserir digitando um mínimo e/ou um máximo.
- O desenvolvedor da regra também cria o parâmetro agentGroup, que provavelmente será uma lista selecionável pela qual o usuário comercial será apresentado a uma lista suspensa de valores extraídos do Genesys Configuration Server ou de uma fonte de dados externa. O comportamento desse parâmetro depende do tipo de parâmetro selecionado pelo desenvolvedor de regras.
- O desenvolvedor da regra cria uma ação e uma condição para a regra, conforme descrito anteriormente. A ação e a condição incluem mapeamentos de linguagem da regra que instruem o Mecanismo de regras sobre quais fatos usar ou atualizar com base nas informações passadas para o Mecanismo de regras como parte (da solicitação de avaliação de regra vinda de um aplicativo cliente, como um aplicativo SCXML).
- O desenvolvedor da regra publica o modelo de regra no Repositório de regras.
- O autor de regras usa esse modelo de regra para criar uma ou mais regras de negócios que utilizam as condições e ações nas combinações necessárias para descrever a lógica comercial que o autor das regras deseja aplicar. Nesse caso, as condições e ações descritas anteriormente provavelmente seriam usadas juntas em uma única regra, mas as condições e ações também poderiam ser combinadas com outras condições e ações disponíveis para criar políticas de negócios diferentes.
- O autor de regras implanta o pacote de regras no servidor de aplicativo do Mecanismo de regras.
- Um aplicativo cliente, como um aplicativo VXML ou SCXML, chama o Mecanismo de regras e especifica o pacote de regras a ser avaliado. A solicitação para o Mecanismo de regras incluirá os parâmetros de entrada e saída para o modelo de fatos. Neste exemplo, teria que incluir a propriedade idade do fato do Cliente. Essa idade pode ter sido coletada por meio do GVP ou extraída de um banco de dados do cliente antes do Mecanismo de regras ser chamado. Com base no valor da propriedade de fato Customer.age que é passada para o Mecanismo de regras como parte da solicitação de avaliação de regras, o Mecanismo de Regras avaliará um conjunto específico de regras que foram implantadas. Neste exemplo, será avaliado se Customer.age fica entre os limites inferior e superior que o autor de regras especificou na regra.
- Se a regra for avaliada como verdadeira pelo Mecanismo de regras, a propriedade targetAgentGroup do fato Autor da chamada será atualizada com o nome do Grupo de agentes selecionado pelo autor de regras de negócios quando a regra foi escrita. O valor da propriedade Caller.targetAgentGroup será transmitido de volta ao aplicativo cliente para processamento adicional. Neste exemplo, talvez o valor de Caller.targetAgentGroup seja mapeado para uma variável de aplicativo Composer que será então passada para o bloco Meta para solicitar ao Genesys Universal Routing Server que direcione esse grupo de agentes.
Exemplo 2: Função
As funções são usadas para elementos mais complexos e são escritas em Java. Neste exemplo, a função é usada para comparar datas. Ela seria configurada da seguinte forma:
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;
}
}
Para classes fornecidas pelo usuário, o arquivo .jar deve estar no CLASSPATH para GRAT e GRE.
A figura abaixo mostra como essa função apareceria no desenvolvimento de regras do GRAT.
Exemplo 3: Usar um Objeto JSON
Os desenvolvedores de modelos podem criar modelos que permitem que aplicativos clientes transmitam Fatos para GRE como objetos JSON sem precisar mapear cada campo para o modelo de fatos explicitamente.
Este exemplo mostra como criar um modelo que contém uma classe (chamada MyJson) para transmitir um objeto JSON.
Início
- Crie a seguinte classe e importe-a para um modelo de regra:
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) { } } } - Crie um fato de demonstração com o mesmo nome (MyJson) no modelo.
- Adicione a MyJson.class ao caminho da classe do GRAT e do GRE.
- Crie a seguinte condição e ação:
Is JSON string "{key}" equal "{value}" eval($MyJson.getString("{key}").equals("{value}")) Set JSON string "{key}" to "{value}" $MyJson.put("{key}", "{value}"); - Use esta condição e ação em uma regra no pacote json.test. Com isso, o seguinte será gerado:
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 - Implante o pacote json.test no GRE.
- Execute a seguinte solicitação de execução do RESTClient:
{"knowledgebase-request":{ "inOutFacts":{"anon-fact":{"fact":{"@class":"simple.MyJson", "jsonObject": {"map":{"entry":[{"string":["category","test"]},{"string":["anotherKey","anotherValue"]}]}}}}}}} - A seguinte resposta é gerada:
{"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"]}}}}}
Fim
Exemplo 4: Desenvolver modelos para habilitar cenários de teste
Para obter mais informações sobre este tópico, consulte Desenvolver modelos para habilitar cenários de teste na Ajuda do GRDT 8.1.3.
Mapeamento de diversas instâncias de um parâmetro de regra para uma única definição de parâmetro
No momento da criação dos parâmetros, em vez de criar os parâmetros ageLow e ageHigh, o desenvolvedor do modelo de regra pode criar um único parâmetro {age} e usar a notação de caractere sublinhado mostrada no exemplo abaixo para criar índices do parâmetro para cenários nos quais várias instâncias de parâmetro com o mesmo tipo (idade) são necessárias (mais comumente usadas com intervalos). Por exemplo: {age_1}, {age_2}....{age_n} Esses campos serão editáveis. Esse recurso é normalmente usado para definir intervalos com mais eficiência.
Fato/condição
Os fatos podem ser referenciados em condições e ações prefixando o nome do fato com um sinal $. Por exemplo, o fato Caller pode ser referenciado pelo nome $Caller. O GRS gerará implicitamente uma condição que associa a variável $Caller ao fato Caller (ou seja, $Caller:Caller()).
A condição $Caller:Caller() exige um objeto Caller como entrada na execução de regras para que essa condição seja avaliada como verdadeira.