Compartilhar via

Otimização para execução do Mecanismo de Regras de Aplicativos Lógicos do Azure (versão prévia)

  • Artigo

Aplica-se a: Aplicativos Lógicos do Azure (Standard)

Importante

Esse recurso está em versão prévia e está sujeito aos Termos de uso suplementares para versões prévias do Microsoft Azure.

O Mecanismo de Regras de Aplicativos Lógicos do Azure fornece o contexto de execução para um conjunto de regras, que você pode criar com o Criador de Regras da Microsoft. Este guia explica os principais conceitos sobre como o mecanismo de regras funciona e fornece recomendações de otimização para operações e execução.

Componentes principais

  • Executor do conjunto de regras

    Esse componente implementa o algoritmo responsável pela avaliação da condição da regra e pela execução da ação. O executor de conjunto de regras padrão é um mecanismo de inferência de encadeamento de encaminhamento baseado em rede de discriminação projetado para otimizar a operação na memória.

  • Conversor do conjunto de regras

    Esse componente usa um objeto RuleSet como entrada e produz uma representação executável do conjunto de regras. O conversor padrão na memória cria uma rede de discriminação compilada a partir da definição do conjunto de regras.

  • Interceptor de acompanhamento do conjunto de regras

    Esse componente recebe a saída do executor do conjunto de regras e encaminha essa saída para as ferramentas de acompanhamento e monitoramento do conjunto de regras.

Execução da ação e avaliação de condição

O Mecanismo de Regras dos Aplicativos Lógicos do Azure é um mecanismo de inferência altamente eficiente que pode vincular regras a objetos .NET ou a documentos XML. O mecanismo de regras usa um algoritmo de três estágios para execução do conjunto de regras com os seguintes estágios:

  • Correspondência

    No estágio de correspondência, o mecanismo de regras corresponde os fatos em relação aos predicados que usam o tipo de fato, que são referências de objeto mantidas na memória de trabalho do mecanismo de regras, usando os predicados definidos nas condições de regra. Para eficiência, os padrões correspondentes ocorre em todas as regras no conjunto de regras e as condições compartilhadas entre regras são correspondidas apenas uma vez. O mecanismo de regras pode armazenar correspondências de condição parciais na memória de trabalho para agilizar as operações subsequentes de padrões correspondentes. A saída da fase de padrões correspondentes contém atualizações na agenda do mecanismo de regras.

  • Resolução de conflitos

    No estágio de resolução de conflitos, o mecanismo de regras examina as regras que são candidatas à execução para determinar o próximo conjunto de ações de regra a ser executado, com base em um esquema de resolução predeterminado. O mecanismo de regras adiciona todas as regras candidatas encontradas durante o estágio de correspondência à agenda do mecanismo de regras.

    O esquema de resolução de conflitos padrão se baseia em prioridades de regra dentro de um conjunto de regras. A prioridade é uma propriedade de regra que você pode configurar no Criador de Regras da Microsoft. Quanto maior for o número, maior é prioridade. Se várias regras forem disparadas, o mecanismo de regras executará as ações de prioridade mais alta primeiro.

  • Ação

    No estágio de ação, o mecanismo de regras executa as ações na regra resolvida. As ações de regra podem declarar novos fatos no mecanismo de regras, o que faz com que o ciclo continue e também seja conhecido como encadeamento de encaminhamento.

    Importante

    O algoritmo nunca faz preempção da regra em execução no momento. O mecanismo de regras executa todas as ações na regra em execução no momento antes que a fase de correspondência se repita. No entanto, outras regras na agenda do mecanismo de regras não serão executadas antes que a fase de correspondência comece novamente. A fase de correspondência pode fazer com que o mecanismo de regras remova essas regras da agenda antes que elas sejam executadas.

Exemplo

O exemplo a seguir mostra como funciona o algoritmo de três estágios de correspondência, resolução de conflitos e ação:

Regra 1: avaliar a renda

  • Representação declarativa

    Obtém a classificação de crédito de um requerente somente se a proporção de renda para empréstimo do requerente for menor que 0,2.

  • Representação SE—ENTÃO usando objetos de negócios

    IF Application.Income / Property.Price < 0.2
THEN Assert new CreditRating( Application)

Regra 2: avaliar a classificação de crédito

  • Representação declarativa

    Aprovar um requerente somente se a classificação de crédito do requerente for superior a 725.

  • Representação SE—ENTÃO usando objetos de negócios:

    IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
THEN SendApprovalLetter(Application)

A tabela a seguir resume os fatos:

Fato Descrição Fields
Aplicativo Um documento XML que representa um aplicativo de crédito imobiliário. – Renda: $ 65.000
– SSN: XXX-XX-XXXX
Propriedade Um documento XML que representa a propriedade a ser comprada. – Preço: $ 225.000
CreditRating Um documento XML que contém a classificação de crédito do requerente de empréstimo. – Valor: 0-800
– SSN: XXX-XX-XXXX

Atualizações para agenda e memória de trabalho

Inicialmente, a agenda e a memória de trabalho do mecanismo de regras estão vazias. Depois que o aplicativo adicionar os fatos Aplicação e Propriedade, o mecanismo de regras atualizará sua agenda e memória de trabalho, conforme demonstrado:

Memória de trabalho Agenda
– Aplicativo
– Propriedade		 Regra 1

  • O mecanismo de regras adiciona a Regra 1 à sua agenda porque a condição Application.Income / Property.Price < 0.2 é avaliada como verdadeira durante a fase de correspondência.

  • Nenhum fato CreditRating existe na memória de trabalho, portanto, a condição da Regra 2 não é avaliada.

  • A Regra 1 é a única regra na agenda, portanto, a regra é executada e, em seguida, desaparece da agenda.

  • A Regra 1 define uma única ação que resulta em um novo fato, que é o documento CreditRating do requerente que é adicionado à memória de trabalho.

  • Depois que a Regra 1 concluir a execução, o controle retornará à fase de correspondência.

    O único objeto novo a corresponder é o fato CreditRating, portanto, os resultados da fase de correspondência são os seguintes:

    Memória de trabalho Agenda
    – Aplicativo
    – Propriedade
    – CreditRating    		 Regra 2

  • A Regra 2 agora é executada, que chama uma função que envia uma carta de aprovação ao requerente.

  • Depois que a Regra 2 for concluída, o controle retornará à fase de correspondência. No entanto, não há mais fatos novos disponíveis para correspondência e a agenda está vazia, portanto, o encadeamento de encaminhamento termina e a execução do conjunto de regras é concluída.

Agenda e prioridade

Para entender como o Mecanismo de Regras dos Aplicativos Lógicos do Azure avalia regras e executa ações, você também deve aprender sobre os conceitos de agenda e prioridade.

Agenda

A agenda do mecanismo de regras é um agendamento que enfileira regras para execução. A agenda existe para uma instância do mecanismo e atua em um único conjunto de regras, não em uma série de conjuntos de regras. Quando um fato é declarado na memória de trabalho e as condições de uma regra são atendidas, o mecanismo coloca a regra na agenda e executa essa regra com base na prioridade. O mecanismo executa as ações de uma regra de prioridade de cima para baixo e, em seguida, executa as ações da próxima regra na agenda.

O mecanismo de regras trata as ações em uma regra como um bloco, portanto, todas as ações são executadas antes que o mecanismo se mova para a próxima regra. Todas as ações em um bloco de regra são executadas independentemente de outras ações no bloco. Para obter mais informações sobre declaração, consulte Otimizar o mecanismo de regras com funções de controle.

O seguinte exemplo mostra como a agenda funciona:

Regra 1

IF
Fact1 == 1
THEN
Action1
Action2

Regra 2

IF
Fact1 > 0
THEN
Action3
Action4

Quando o fato Fact1, que tem um valor de 1, é declarado no mecanismo, tanto a Regra 1 quanto a Regra 2 têm suas condições atendidas. Portanto, o mecanismo move ambas as regras para a agenda para executar suas ações.

Memória de trabalho Agenda
Fato 1 (valor=1) Regra 1:
– Action1
– Action2

Regra 2:
– Action3
– Action4

Prioridade

Por padrão, todas as regras são definidas como 0 como a prioridade para execução. No entanto, você pode alterar essa prioridade em cada regra. A prioridade pode variar para ambos os lados de 0 com números maiores com prioridade maior. O mecanismo executa ações da prioridade mais alta à prioridade mais baixa.

O exemplo a seguir mostra como a prioridade afeta a execução da ordem das regras:

Regra 1 (prioridade = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Regra 2 (prioridade = 10)

IF
Fact1 > 0
THEN
Discount = 15%

Embora as condições para ambas as regras sejam atendidas, a Regra 2 é executada primeiro devido à sua prioridade mais alta. O desconto final é de 10% devido ao resultado da ação executada da Regra 1, conforme mostrado na tabela a seguir:

Memória de trabalho Agenda
Fact1 (valor=1) Regra 2:
Desconto: 15%

Regra 1:
Desconto: 10%

Efeitos colaterais da ação

Se a execução de uma ação afetar o estado de um objeto ou um termo usado em condições, essa ação terá um "efeito colateral" nesse objeto ou termo. Essa frase não significa que a ação tenha efeitos colaterais, mas sim, o objeto ou termo é potencialmente afetado por uma ou mais ações.

Por exemplo, suponha que você tenha as seguintes regras:

Regra 1

IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"

Regra 2

IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")

Neste exemplo, OrderForm.UpdateStatus tem um "efeito colateral" em OrderForm.Status, significando que OrderForm.Status é potencialmente afetado por uma ou mais ações.

A propriedade SideEffects para membros da classe .NET é definida como verdadeiro como o valor padrão, o que impede que o mecanismo de regras armazene em cache um membro com efeitos colaterais. Neste exemplo, o mecanismo de regras não armazena em cache OrderForm.Status na memória de trabalho. Em vez disso, o mecanismo obtém o valor mais recente de OrderForm.Status sempre que o mecanismo avalia a Regra 1. Se o valor da propriedade SideEffects for falso, o mecanismo de regras armazenará em cache o valor quando o mecanismo avaliar OrderForm.Status pela primeira vez. No entanto, para avaliações posteriores em cenários de encadeamento de encaminhamento, o mecanismo usa o valor armazenado em cache.

Atualmente, o Criador de Regras da Microsoft não fornece uma maneira de modificar o valor da propriedade SideEffects. No entanto, você pode definir programaticamente o valor da propriedade SideEffects por meio da Estrutura de Regras de Negócios, que é uma biblioteca de classes compatível com Microsoft .NET. Você define esse valor na associação usando a classe ClassMemberBinding para especificar métodos, propriedades e campos de objeto usados em condições e ações de regra. A classe ClassMemberBinding tem uma propriedade chamada SideEffects, que contém um valor booliano que indica se o acesso ao membro altera seu valor.

Considerações sobre o desempenho

Esta seção discute como o Mecanismo de Regras dos Aplicativos Lógicos do Azure é executado em vários cenários e com valores diferentes para parâmetros de configuração e ajuste.

Tipos de fatos

O mecanismo de regras leva menos tempo para acessar fatos do .NET do que para acessar fatos XML. Se você tiver uma opção entre usar fatos do .NET ou fatos XML em um conjunto de regras, considere usar fatos do .NET para melhorar o desempenho.

Prioridade da regra

A configuração da prioridade de uma regra pode variar para ambos os lados de 0 com números maiores com prioridade maior. As ações são executadas na ordem da prioridade mais alta à prioridade mais baixa. Quando o conjunto de regras implementa o comportamento de encadeamento de encaminhamento usando chamadas de Declaração ou Atualização, você pode otimizar o encadeamento usando a propriedade Prioridade.

Por exemplo, suponha que a Regra 2 tenha uma dependência de um valor definido pela Regra 1. Se a Regra 1 tiver prioridade mais alta, a Regra 2 só será executada após a Regra 1 disparar e atualizar o valor. Por outro lado, se Regra 2 tiver uma prioridade maior, a regra poderá ser acionada uma vez e, em seguida, disparar novamente após Regra 1 disparar e atualizar o fato na condição da Regra 2. Esse cenário pode ou não produzir os resultados corretos, mas, claramente, disparar duas vezes afeta o desempenho em vez de disparar apenas uma vez.

Para obter mais informações, consulte Criar regras usando o Criador de Regras da Microsoft.

Operadores OU lógicos

O mecanismo de regras é otimizado para executar operadores AND lógicos e reconstrói a regra que o mecanismo analisou em um formulário normal disjuntivo para que o operador OU lógico seja usado apenas no nível superior.

Se você usar mais operadores OU lógicos em condições, o aumento criará mais permutações que expandem a rede de análise do mecanismo de regras. Como resultado, o mecanismo de regras pode levar muito tempo para normalizar a regra.

A lista a seguir fornece possíveis soluções alternativas para este problema:

  • Altere a regra para um formulário normal disjuntivo para que o operador OR esteja apenas no nível superior.

    Considere criar a regra programaticamente porque você pode achar complicado criar uma regra na forma normal disjuntiva no Criador de Regras da Microsoft.

  • Desenvolva um componente auxiliar que executa as operações OU e retorna um valor booliano e, em seguida, use o componente na regra.

  • Divida a regra em várias regras e faça com que as regras verifiquem se há um sinalizador definido por uma regra executada anteriormente ou use um objeto que uma regra executada anteriormente declarou, por exemplo:

    • Regra 1: IF (a == 1 OR a == 3) THEN b = true

      Regra 2: IF (b == true) THEN …

    • Regra 1: IF (a == 1 OR a == 3) THEN Assert(new c())

      Regra 2: IF (c.flag == true) THEN …

Chamadas de atualização

A função Atualizar atualiza um fato que existe na memória de trabalho do mecanismo de regras, o que causa reavaliação de todas as regras que usam o fato atualizado nas condições. Esse comportamento significa que as chamadas de função Atualizar podem ser caras, especialmente se muitas regras exigirem reavaliação devido a fatos atualizados. Em algumas situações, você pode evitar a necessidade de reavaliar as regras.

Por exemplo, considere as seguintes regras:

Regra 1

IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)

Regra 2

IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)

Todas as regras restantes no conjunto de regras usam StatusObj.Flag em suas condições. Quando você chama a função Atualização no objeto StatusObj, todas as regras são reavaliadas. Seja qual for o valor no campo Quantidade, todas as regras, exceto Regra 1 e Regra 2 são avaliadas duas vezes: uma vez antes da chamada de Atualização e uma vez após a chamada de Atualização.

Em vez disso, você pode definir o valor do Sinalizador para falso antes de invocar o conjunto de regras e, em seguida, usar apenas Regra 1 no conjunto de regras para definir o sinalizador. Nesse caso, a função Atualizar será chamada somente se o valor Quantidade for maior que 5. A função Atualizar não será chamada se o valor for menor ou igual a 5. Dessa forma, todas as regras, exceto Regra 1 e Regra 2 são avaliadas duas vezes somente se o valor Quantidade for maior que 5.

Comportamento da propriedade SideEffects

Nas classes XmlDocumentFieldBinding eClassMemberBinding, a propriedade SideEffects determina se o valor do campo associado, membro ou coluna deve ser armazenado em cache.

Na classe XmlDocumentFieldBinding, o valor padrão da propriedade SideEffects é falso. No entanto, na classe ClassMemberBinding, o valor padrão da propriedade SideEffects é verdadeiro.

Portanto, se o mecanismo acessar um campo em um documento XML pela segunda vez ou posterior dentro do conjunto de regras, o mecanismo obterá o valor do campo do cache. No entanto, se o mecanismo acessar um membro de um objeto .NET pela segunda vez ou posteriormente dentro do conjunto de regras, o mecanismo obterá o valor do objeto .NET, não do cache.

Esse comportamento significa que, se você definir a propriedade SideEffects em um ClassMemberBinding do .NET para falso, você poderá melhorar o desempenho porque o mecanismo obtém o valor do membro do cache começando pela segunda vez e em diante. No entanto, você só pode definir programaticamente o valor da propriedade porque o Criador de Regras da Microsoft não expõe a propriedade SideEffects.

Instâncias e seletividade

As classes XmlDocumentBinding e ClassBinding têm cada uma as propriedades a seguir, que o mecanismo de regras usa seus valores para otimizar a avaliação da condição. Esses valores de propriedade permitem que o mecanismo use o menor número possível de instâncias primeiro em avaliações de condição e, em seguida, use as instâncias restantes.

  • Instâncias: o número esperado de instâncias de classe na memória de trabalho.

    Se você souber o número de instâncias de objeto com antecedência, poderá definir a propriedade Instâncias para esse número para melhorar o desempenho.

  • Seletividade: o percentual de instâncias de classe que passam com sucesso as condições da regra.

    Se você souber o percentual de instâncias de objeto que passam as condições com antecedência, poderá definir a propriedade Seletividade para esse percentual para melhorar o desempenho.

Você só pode definir programaticamente esses valores de propriedade porque o Criador de Regras da Microsoft não os expõe.

Suporte para herança de classe

A herança é a capacidade de usar todas as funcionalidades de uma classe existente e estender esses recursos sem reescrever a classe original, que é um recurso fundamental em linguagens POO (Programação Orientada a Objetos).

O Mecanismo de Regras dos Aplicativos Lógicos do Azure dá suporte aos seguintes tipos de herança de classe:

  • Herança de implementação: a capacidade de usar as propriedades e métodos de uma classe base sem outra codificação.

  • Herança de interface: a capacidade de usar apenas nomes de propriedade e nomes de método, mas a classe filho deve fornecer a implementação.

Com o mecanismo de regras, você pode escrever regras em termos de uma classe base comum, mas os objetos declarados no mecanismo de regras podem vir de classes derivadas.

O exemplo a seguir tem uma classe base chamada Employee, enquanto as classes derivadas são nomeadas RegularEmployee e ContractEmployee:

class Employee
{
    public string Status()
    {
        // member definition
    }
    public string TimeInMonths()
    {
        // member definition
    }
}

class ContractEmployee : Employee
{
   // class definition
}
class RegularEmployee : Employee
{
   // class definition
}

Por exemplo, pressuponha que você tem as seguintes regras:

Regra 1

IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"


At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.

You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:

**Rule 2**

```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())

Após a declaração, o mecanismo reavalia todas as regras que contêm o tipo Employee ou o tipo ContractEmployee em suas condições. Embora apenas a classe derivada seja declarada, a classe base também será declarada se as regras forem escritas usando métodos na classe base, em vez de na classe derivada.

Conteúdo relacionado