Partilhar via

Otimização para execução do Mecanismo de Regras de Aplicativos Lógicos do Azure (Visualização)

  • Artigo

Aplica-se a: Aplicativos Lógicos do Azure (Padrão)

Importante

Esta funcionalidade está em pré-visualização e está sujeita aos Termos de Utilização Suplementares para Pré-visualizações 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 Microsoft Rules Composer. 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 centrais

  • Executor do conjunto de regras

    Este componente implementa o algoritmo responsável pela avaliação da condição da regra e 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.

  • Tradutor de conjunto de regras

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

  • Intercetor de rastreamento de conjunto de regras

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

Avaliação da condição e execução da ação

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

  • Correspondência

    No estágio de correspondência, o mecanismo de regras faz a correspondência entre fatos e os 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 da regra. Para eficiência, a correspondência de padrões ocorre em todas as regras no conjunto de regras, e as condições que são compartilhadas entre regras são correspondidas apenas uma vez. O mecanismo de regras pode armazenar correspondências parciais de condições na memória de trabalho para agilizar as operações subsequentes de correspondência de padrões. A saída da fase de correspondência de padrões contém atualizações para a 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 regras a serem executadas, 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 é baseado em prioridades de regras dentro de um conjunto de regras. A prioridade é uma propriedade de regra que você pode configurar no Microsoft Rules Composer. Quanto maior o número, maior a prioridade. Se várias regras forem acionadas, 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 afirmar novos fatos no mecanismo de regras, o que faz com que o ciclo continue e também é conhecido como encadeamento para frente.

    Importante

    O algoritmo nunca antecipa a regra em execução no momento. O mecanismo de regras executa todas as ações na regra em execução 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 jogos 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 o rendimento

  • Representação declarativa

    Obter a notação de crédito de um requerente apenas se o seu rácio rendimento/empréstimo for inferior a 0,2.

  • SE—THEN representação usando objetos de negócios

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

Regra 2: Avaliar a notação de crédito

  • Representação declarativa

    Aprovar um candidato apenas se a sua notação de crédito for superior a 725.

  • SE—THEN Representação usando objetos de negócios:

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

O quadro seguinte resume os factos:

Facto Description Campos
Aplicação Um documento XML que representa um pedido de crédito à habitação. - Rendimento: $65.000
- SSN: XXX-XX-XXXX
Propriedade Um documento XML que representa a propriedade a ser comprada. - Preço: $225,000
Notação de Crédito Um documento XML que contém a classificação de crédito do requerente do empréstimo. - Valor: 0-800
- SSN: XXX-XX-XXXX

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

Inicialmente, a memória de trabalho e a agenda do mecanismo de regras estão vazias. Depois que seu aplicativo adiciona os fatos de Aplicativo e Propriedade , o mecanismo de regras atualiza sua memória de trabalho e agenda, conforme mostrado:

Memória de trabalho Agenda
- Aplicação
- 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 partida.

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

  • A regra 1 é a única regra na agenda, de modo que a regra é executada e depois desaparece da agenda.

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

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

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

    Memória de trabalho Agenda
    - Aplicação
    - Propriedade
    - CreditRating    		 Regra 2

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

  • Após a conclusão da Regra 2, o controle retorna à fase de correspondência. No entanto, não há mais fatos novos disponíveis para corresponder, e a agenda está vazia, então o encadeamento para frente termina e a execução do conjunto de regras é concluída.

Agenda e prioridades

Para entender como o Mecanismo de Regras de 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 cronograma que enfileira regras para execução. A agenda existe para uma instância de motor e atua de acordo com um único conjunto de regras, não com uma série de conjuntos de regras. Quando um fato é afirmado 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 da prioridade superior para a inferior e, em seguida, executa as ações para a 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 passe 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 asserção, consulte Otimizar seu mecanismo de regras com funções de controle .

O exemplo a seguir mostra como funciona a agenda:

Regra 1

IF
Fact1 == 1
THEN
Action1
Action2

Regra 2

IF
Fact1 > 0
THEN
Action3
Action4

Quando o facto Facto1 , que tem um valor de 1, é afirmado no motor, tanto a Regra 1 como a Regra 2 têm as suas condições satisfeitas. Assim, o motor move ambas as regras para a agenda para executar suas ações.

Memória de trabalho Agenda
Facto 1 (valor=1) Regra 1:
- Ação1
- Ação2

Regra n.º 2:
- Ação3
- Ação4

Prioridade

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

O exemplo a seguir mostra como a prioridade afeta a execução de ordens para 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 cumpridas, a Regra 2 é executada primeiro devido à sua maior prioridade. O desconto final é de 10% devido ao resultado da ação executada para a Regra 1, conforme mostrado na tabela a seguir:

Memória de trabalho Agenda
Facto1 (valor=1) Regra n.º 2:
Desconto: 15%

Regra 1:
Desconto: 10%

Efeitos colaterais de ação

Se a execução de uma ação afeta o estado de um objeto ou um termo usado em condições, diz-se que essa ação tem um "efeito colateral" sobre esse objeto ou termo. Esta 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, o que significa que OrderForm.Status é potencialmente afetado por uma ou mais ações.

A propriedade SideEffects para membros da classe .NET é definida como true 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 toda vez que o mecanismo avalia a Regra 1. Se o valor da propriedade SideEffects for false, 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 futuro, o mecanismo usa o valor armazenado em cache.

O Microsoft Rules Composer atualmente 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 do Business Rules Framework, que é um Microsoft . Biblioteca de classes compatível com NET. Você define esse valor na vinculação usando a classe ClassMemberBinding para especificar métodos de objeto, propriedades e campos usados em condições e ações de regra. A classe ClassMemberBinding tem uma propriedade chamada SideEffects, que contém um valor booleano que indica se o acesso ao membro altera seu valor.

Considerações de desempenho

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

Tipos de factos

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

Prioridade da regra

A definição de prioridade para uma regra pode variar para ambos os lados de 0 com números maiores com prioridade mais alta. As ações são executadas em ordem, começando da prioridade mais alta para a prioridade mais baixa. Quando o conjunto de regras implementa o comportamento de encadeamento de encaminhamento usando chamadas Assert ou Update , você pode otimizar o encadeamento usando a propriedade Priority .

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 depois que a Regra 1 for acionada e atualizar o valor. Por outro lado, se a Regra 2 tiver uma prioridade mais elevada, a regra pode disparar uma vez e, em seguida, disparar novamente depois que a Regra 1 for acionada e atualizar o fato na condição da Regra 2. Este cenário pode ou não produzir os resultados corretos, mas claramente, disparar duas vezes tem um impacto no desempenho versus disparar apenas uma vez.

Para obter mais informações, consulte Criar regras usando o Microsoft Rules Composer.

Operadores lógicos de RUP

O mecanismo de regras é otimizado para executar operadores lógicos E e reconstrói a regra que o mecanismo analisou em uma forma normal disjuntiva para que o operador OR lógico seja usado apenas no nível superior.

Se você usar operadores OR mais 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 esse problema:

  • Altere a regra para uma forma normal disjuntiva para que o operador OR esteja apenas no nível superior.

    Considere criar a regra programaticamente porque você pode achar que criar uma regra na forma normal disjuntiva no Microsoft Rules Composer pode ser complicado.

  • Desenvolva um componente auxiliar que execute as operações OR e retorne um valor booleano 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 afirmou, por exemplo:

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

      Regra n.º 2: IF (b == true) THEN …

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

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

Atualizar chamadas

A função Update atualiza um fato que existe na memória de trabalho do mecanismo de regras, o que causa reavaliação para todas as regras que usam o fato atualizado em condições. Esse comportamento significa que as chamadas de função de atualização podem ser caras, especialmente se muitas regras exigirem reavaliação devido a fatos atualizados. Em algumas situações, você pode evitar ter que 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 Update no objeto StatusObj , todas as regras são reavaliadas. Seja qual for o valor no campo Valor, todas as regras, exceto a Regra 1 e a Regra 2, são avaliadas duas vezes: uma antes da chamada Atualizar e outra após a chamada Atualizar.

Em vez disso, você pode definir o valor Flag como false antes de invocar o conjunto de regras e, em seguida, usar apenas a Regra 1 no conjunto de regras para definir o sinalizador. Nesse caso, a função Update é chamada somente se o valor Amount for maior que 5. A função Update não é chamada se o valor for menor ou igual a 5. Desta forma, todas as regras, exceto a Regra 1 e a Regra 2, são avaliadas duas vezes apenas se o valor do Valor for superior a 5.

Comportamento da propriedade SideEffects

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

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

Assim, se o mecanismo acessa um campo em um documento XML pela segunda vez ou mais tarde dentro do conjunto de regras, o mecanismo obtém 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 .NET ClassMemberBinding como false, poderá melhorar o desempenho porque o mecanismo obtém o valor do membro do cache a partir da segunda vez. No entanto, você só pode definir programaticamente o valor da propriedade porque o Microsoft Rules Composer não expõe a propriedade SideEffects .

Instâncias e seletividade

As classes XmlDocumentBinding e ClassBinding têm as seguintes propriedades, que o mecanismo de regras usa seus valores para otimizar a avaliação de condições. 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 de antemão, poderá definir a propriedade Instances como esse número para melhorar o desempenho.

  • Seletividade: a porcentagem de instâncias de classe que passam com êxito as condições da regra.

    Se você souber a porcentagem de instâncias de objeto que passam as condições de antemão, poderá definir a propriedade Seletividade como essa porcentagem para melhorar o desempenho.

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

Suporte para herança de classe

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 nas linguagens OOP (Object Oriented Programming).

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

  • Herança de implementação: a capacidade de usar 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 chamadas 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
}

Para este exemplo, suponha que você tenha 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 asserção, o mecanismo reavalia todas as regras que contêm o tipo Employee ou o tipo ContractEmployee em suas condições. Mesmo que apenas a classe derivada seja afirmada, a classe base também é afirmada se as regras forem escritas usando métodos na classe base, em vez de na classe derivada.

Conteúdos relacionados