Índice
Visão geral do desenvolvimento do modelo de regra
Modelos de regras permitem que o desenvolvedor de regras de negócios crie modelos de regras que definem as condições e ações que serão usadas pelo autor de regras de negócios. O desenvolvedor cria as instruções em linguagem simples que o autor de negócios observa e as mapeia para as instruções em linguagem da regra que o mecanismo de regras executará. Para cada condição e ação da regra, o desenvolvedor decide que tipo de dados o autor de regras fornecerá. Alguns exemplos incluem se a entrada deve ser um valor inteiro, um valor numérico não inteiro, uma cadeia de caracteres, uma seleção de uma lista predefinida ou uma seleção a partir de uma lista dinâmica. Os modelos de regras são usados pelos autores de regras para criar regras para classificação e priorização de tarefas aos níveis global, departamental e processual da estrutura de negócios da solução Genesys.
Links rápidos—Trabalhar com modelos
Links rápidos—Trabalhar com editores
Conteúdo do modelo
Modelos de regra são compostos de vários elementos:
- Ações
- Condições
- Enumerações
- Modelos de fatos
- Eventos
- Funções
- Parâmetros
Ações e condições
Ações e condições definem cenários QUANDO/ENTÃO, como QUANDO um cliente é um cliente Gold, ENTÃO o destino é o GoldAgentGroup. A instrução QUANDO é a condição e a instrução ENTÃO é a ação. Uma regra pode ter zero ou mais condições e uma ou mais ações. Esse exemplo também inclui parâmetros: o status do cliente (Gold) e o nome do Grupo de agentes (GoldAgentGroup).
Sempre que uma condição contiver um mapeamento da linguagem da regra que comece com eval(...), você deve colocar toda a expressão entre parênteses, da seguinte maneira:
( eval(.... ) )
Isso garantirá que ela seja compilada corretamente quando usada com o operador NÃO.
Consulte Editor de ações e Editor de condições.
Enumerações
As enumerações são usadas para definir listas de opções possíveis que serão exibidas ao autor de regras de negócios, quando o autor estiver criando regras baseadas no modelo de regra. Em alguns casos, a lista de opções possíveis será selecionada dinamicamente dos objetos do Genesys Configuration Server ou de fontes de dados externas. Para atividades WFM e atividades multissite, a lista de opções possíveis é recuperada dinamicamente no Genesys WFM Server. Assim, as enumerações são usadas durante a definição de uma lista discreta de opções que não serão alteradas dinamicamente.
Consulte o Editor de enumerações
Modelos de fatos
Todos os modelos de regras incluem um modelo de fatos com um ou mais fatos. Um modelo de fato estrutura o conhecimento básico sobre operações de negócios a partir de uma perspectiva de negócios. Um modelo de fatos se concentra em conexões lógicas (chamadas de fatos) entre os principais conceitos do negócio. Indica o que você precisa saber sobre as operações de negócios para poder oferecer suporte (ou realmente realizar) a essas operações.
Um bom modelo de fatos o informa como estruturar seu pensamento (ou conhecimento) básico sobre o processo de negócios com base em um vocabulário padrão. Ao usar o vocabulário padrão, focado nos negócios, garantimos que as próprias regras de negócios possam ser bem compreendidas pelas principais partes interessadas, como analistas de negócios. Por exemplo, em sua empresa, você pode ter um Fato que representa um Cliente e outro Fato que representa um Pedido.
O Cliente pode ter campos como nome, idade, local, classificação de crédito e idioma preferido. O Pedido pode ter campos como valor e data do pedido. Uma regra pode ser construída usando esses valores, como:
Quando o Cliente tiver pelo menos 21 anos e o pedido for > 100,00, convide o cliente a participar de uma pesquisa.
Consulte Editor de modelos de fatos
Eventos
Para oferecer suporte ao Processamento de eventos complexos, os desenvolvedores de modelos precisam poder designar certos fatos como eventos e os autores de regras precisam alterar a maneira como o DRL é gerado quando um fato é designado como um evento.
Portanto, o modelo de fatos foi melhorado para incluir eventos e a caixa de diálogo do modelo de fato agora inclui um botão Criar evento. Um evento possui os seguintes campos:
- Nome
- Descrição
- Uma lista opcional de Propriedades.
- Metadados de expiração definidos pelo usuário para o evento
No GRAT, a tag de metadados @role determina se estamos lidando com um fato ou evento. A tag metadados @role pode aceitar dois valores possíveis:
- fato — Atribuir a função de fato declara que o tipo deve ser tratado como um fato regular. Fato é a função padrão.
- evento— Atribuir a função de evento declara que o tipo deve ser tratado como um evento.
Funções
Funções são usadas para definir outros elementos além de Condições e Ações, por exemplo, quando a análise de registros de data e hora é necessária. O Editor de funções permite gravar funções Java específicas para diferentes propósitos, para uso em modelos de regras. As funções especificadas podem ser usadas nos mapeamentos da linguagem da regra (consulte Mapeamento da linguagem da regra).
Quando os modelos de regra são criados, o desenvolvedor da regra os publica no Repositório de regras, disponibilizando-os no GRAT para os usuários comerciais criarem regras.
Ações e condições podem conter parâmetros. Há suporte para vários tipos de parâmetros.
Certos tipos de parâmetros dinâmicos que se referem a fontes de dados externas exigem que um Perfil seja selecionado. O Perfil é definido como um objeto de Script do tipo Coleta de dados e fornece informações de conexão que permitem ao GRAT recuperar esses dados dinâmicos da fonte de dados externa. As próximas seções descrevem como configurar Perfis para parâmetros de banco de dados, serviço Web e Workforce Management.
Consulte Editor de funções.
Parâmetros
Os parâmetros banco de dados, serviço Web e Workforce Management são usados nas ações e condições.
Parâmetros de banco de dados
|
Propriedade |
Obrigatório/opcional |
Descrição |
|---|---|---|
| driver | Obrigatório | O nome do driver JDBC a ser usado. Por exemplo, com.mysql.jdbc.Driver |
| url | Obrigatório | A URL do banco de dados no formato correto para o driver JDBC a ser usado. |
| username | Obrigatório | Um nome de usuário válido para conectar-se ao banco de dados. |
| password | Obrigatório | A senha necessária para o usuário conectar-se ao banco de dados. |
| initSize | Opcional | O tamanho inicial do conjunto de conexões. O padrão é 5. |
| maxSize | Opcional | O tamanho máximo do conjunto de conexões. O padrão é 30. |
| waitTime | Opcional | O tempo máximo (em milissegundos) para aguardar a obtenção de uma conexão. O padrão é 5000. |
Em geral, os valores opcionais não precisam ser definidos ou alterados.
É possível configurar apenas os parâmetros do banco de dados com uma instrução SQL SELECT. Qualquer outro tipo de instrução falhará quando configurada.
Parâmetros do serviço Web
No Configuration Server, os scripts de Serviço Web devem ter uma seção chamada webservice. A tabela abaixo lista as propriedades que podem ser especificadas para os parâmetros de serviço Web.
|
Propriedade |
Obrigatório/opcional |
Descrição |
|---|---|---|
| host | Obrigatório | O host para o serviço. |
| base-path | Obrigatório | O caminho base para acessar o serviço. |
| protocol | Opcional | O padrão é http. |
| port | Opcional | O padrão é 80. |
| headers | Opcional | Quaisquer cabeçalhos HTTP personalizados necessários para o serviço. |
| parameters | Opcional | Quaisquer configurações HTTP personalizadas necessárias para ajustar a conexão. |
Em geral, os valores de parâmetros não precisam ser definidos ou alterados. Cabeçalhos e parâmetros são listas no seguinte formato:
key:value[,key:value]
| Aviso: | Você não pode especificar cabeçalhos ou parâmetros que contenham ',' no valor.
Aviso: Caso esteja enviando uma mensagem para o serviço, será esperado que Tipo de conteúdo seja especificado no cabeçalho, pois define a interação geral da mensagem com o servidor. Um conjunto de caracteres opcional pode ser incluído. Por exemplo, Content-Type:applicaton/json;charset=UTF-8. |
É necessário definir completamente a mensagem a ser enviada e ela deve ser constante. Nenhuma substituição de variável é realizada. A Consulta de XPath é usada para extrair valores da resposta do servidor. A resposta deve estar em XML ou JSON, caso contrário, isso não funcionará. Uma consulta de XPath válida deve ser especificada para a resposta. Isso depende inteiramente do serviço com o qual você faz interface.
| Observação: | A mensagem é enviada para o servidor somente uma vez por sessão. Isso é feito por razões de desempenho e porque espera-se que os valores na resposta sejam relativamente constantes. |
O caminho para o parâmetro é adicionado ao base_path no script.
Por exemplo:
Se o script conter:
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
e o Desenvolvimento de modelos especificar:
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
então a mensagem enviada é:
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
Isso retornará as máximas da semana em Fahrenheit:
81 77 81 81 83 85
Parâmetros de Workforce Management
No Configuration Server, os scripts do Workforce Management devem ter uma seção chamada wfm. A tabela 4 lista as propriedades que você pode especificar para os parâmetros Workforce Management.
|
Propriedade |
Obrigatório/opcional |
Descrição |
|---|---|---|
| wfmCfgServerApplName | Obrigatório | Nome do aplicativo do Configuration Server para o servidor WFM. |
| wfmCfgServerUserName | Obrigatório | Nome de usuário do Configuration Server. |
| wfmCfgServerPassword | Obrigatório | Senha do Configuration Server. |
| wfmServerUrl | Obrigatório | URL do WFM Server. |
Ao configurar um novo parâmetro do tipo 'Workforce Management', basta nomear o parâmetro e escolher o perfil WFM (objeto de script recém-criado) na lista suspensa. Quando o autor estiver usando esse parâmetro, o GRAT buscará a lista atual de Atividades WFM no WFM Server e as exibirá para o autor de regras.
Suporte para tipos de modelo definidos pelo usuário
O GRAT exibe automaticamente a lista de tipos de modelo publicados e os designers de modelos podem selecionar esses tipos de modelos definidos pelo usuário ou definir novos, de acordo com as suas próprias necessidades.
Versões de modelo
Cada vez que um modelo de regra é publicado, uma nova versão é criada no repositório. O autor de regras poderá selecionar qualquer versão do modelo na caixa de diálogo Seleção de modelo ao criar um pacote de regras. Essa caixa de diálogo mostra as últimas N versões de um modelo, em que N é um valor configurado usando a opção de configuração display-n-template-versions no Genesys Administrator.
Ao publicar versões mais recentes do modelo de regra, esteja ciente de que determinadas alterações podem afetar as regras que já foram criadas usando a versão anterior do modelo. Cuidado para não fazer alterações que possam anular regras existentes, a menos que essas alterações sejam comunicadas ao autor de regras.
Por exemplo, se o Modelo de regra versão 1 tiver uma condição removida posteriormente na versão 2 e se uma regra já tiver sido criada usando essa condição, ela não será mais compilada se o autor de regras atualizar para o Modelo de regra versão 2.
Por exemplo, se a configuração foi definida para mostrar as últimas 3 versões de um modelo, o modelo atualmente selecionado é GRS Template versão 2 e existem 5 versões no repositório, mostraria as versões GRS Template 5, 4 e 3, bem como GRS Template versão 2. Os usuários podem escolher entre as versões 3, 4 ou 5.
Comentários da versão
Para fornecer detalhes sobre as diferenças entre as versões do modelo, os desenvolvedores de modelo de regras podem publicar um comentário da versão que descreva as alterações específicas feitas nas versões individuais do modelo. Esse comentário de versão aparece no GRAT na tabela Seleção de modelo e pode ser editado pelo autor de regras no GRAT.