Microsoft 규칙 작성기를 사용하여 규칙 실행을 최적화하는 작업에 컨트롤 함수 추가(미리 보기)

아티클
06/13/2024

적용 대상: Azure Logic Apps(표준)

Important

이 기능은 미리 보기로 제공되고 Microsoft Azure 미리 보기의 추가 사용 약관이 적용됩니다.

이 가이드에서는 Microsoft 규칙 작성기를 사용하여 규칙의 작업에 제어 함수를 추가하여 규칙 실행을 최적화하는 방법을 설명합니다. 제어 함수는 애플리케이션 또는 규칙 집합이 규칙 엔진의 작업 메모리에 있는 사실을 제어하는 데 도움이 됩니다. 이러한 함수에는 팩트로 사용할 수 있는 .NET 개체 및 TypedXmlDocument 엔터티에 대한 Assert, Clear, Halt, Retract, RetractByType, Reassert 및 Update 함수가 포함됩니다. 작업 메모리에 팩트의 존재는 엔진이 평가하는 조건과 실행되는 작업을 구동합니다.

필수 조건

Microsoft 규칙 작성기를 다운로드하여 설치합니다.
작업하려는 규칙 집합이 포함된 XML 파일입니다.

팩트를 추가하려면 RuleSet 탐색기 창에서 가리키는 XML 문서에서 해당 값을 지정합니다. 또는 팩트 작성자를 사용하여 .NET 개체를 팩트로 포함하는 배열을 규칙 엔진에 제공할 수 있습니다. 자세한 내용은 빌드 팩트 작성자 및 검색기를 참조 하세요.

Assert 함수

규칙 엔진의 작업 메모리에 개체 인스턴스를 추가하려면 Microsoft 규칙 작성기 에서 Assert 함수를 사용합니다. 엔진은 일치 충돌 해결 작업 단계를 사용하여 인스턴스 유형에 대해 작성된 조건 및 작업에 따라 각 개체 인스턴스를 처리합니다.

다음 표에서는 각 어설션된 엔터티에 대해 엔진에서 생성된 결과 인스턴스 수와 식별을 위해 각 인스턴스에 적용된 형식을 포함하여 지원되는 어설션된 엔터티 및 인스턴스 형식에 대한 Assert 함수 동작을 요약합니다.

Entity	어설션된 인스턴스 수	인스턴스 유형
.NET 개체	1(개체 자체)	정규화된 .NET 클래스
TypedXmlDocument	1-N TypedXmlDocument: 만든 선택기 바인딩 및 문서 콘텐츠 기반	DocumentType.Selector

.NET 개체 어설션

규칙 엔진은 기본적으로 참조 형식에 대한 기본 .NET 스칼라 형식 및 개체를 지원합니다. 어설션된 .NET 개체 처리는 가장 간단한 처리 형식입니다.

Microsoft 규칙 작성기에서 규칙 내에서 .NET 개체를 어설션할 수 있습니다.

Microsoft 규칙 작성기에서 작업하려는 규칙 저장소가 포함된 XML 파일을 로드합니다.
RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 Assert 기본 제공 함수를 작업으로 추가 합니다.
팩트 탐색기 창에서 .NET 클래스를 선택합니다.
.NET 클래스 탭에서 어설션 작업의 인수로 원하는 개체의 생성자 메서드를 끕니다.

Microsoft 규칙 작성기는 생성자 메서드를 규칙 정의의 CreateObject 호출로 변환합니다.

참고 항목

규칙 엔진에 CreateObject 함수가 있지만 이 함수는 Microsoft 규칙 작성기에서 별도의 함수로 표시되지 않습니다.

각 개체는 별도의 개체 인스턴스로 작업 메모리에 어설션됩니다. 즉, 개체의 형식 IF Object.Property = 1을 참조하는 각 조건자가 인스턴스를 분석합니다. 인스턴스는 규칙 조건의 결과에 따라 형식을 참조하는 규칙 작업에도 사용할 수 있습니다.

예를 들어 다음과 같은 규칙이 있다고 가정합니다.

규칙 1

IF A.Value = 1
THEN A.Status = "good"

규칙 2

IF B.Value = 1
THEN A.Status = "good"

규칙 1에서는 값이 1인 A 인스턴스만 상태 속성을 업데이트합니다. 그러나 규칙 2에서 조건이 true로 평가되면 모든 A 인스턴스의 상태가 업데이트됩니다. 실제로 B 인스턴스가 여러 개 있는 경우 B 인스턴스에 대해 조건이 true로 평가 될 때마다 A 인스턴스가 업데이트됩니다.

TypedXmlDocument 엔터티 어설션

Microsoft 규칙 작성기에서 규칙 내에서 TypedXmlDocument 엔터티를 어설션할 수 있습니다.

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 Assert 기본 제공 함수를 작업으로 추가 합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 어설션 작업의 인수로 원하는 노드를 끕니다.

XML 문서는 기본적으로 텍스트이지만 필드 값은 규칙이 작성될 때 지정된 형식을 기반으로 하는 모든 형식일 수 있습니다. 필드는 XPath 식이므로 노드 집합을 반환할 수 있습니다. 즉, 집합의 첫 번째 항목이 값으로 사용됩니다.

TypedXmlDocument 엔터티가 팩트로 어설션되면 규칙 엔진은 규칙에 정의된 선택기를 기반으로 TypedXmlDocument 자식 인스턴스를 만듭니다. 선택기는 XML 문서의 노드를 격리하는 방법으로 간주하고 필드를 선택기 내의 특정 항목을 식별하는 것으로 간주할 수 있습니다. 규칙 엔진은 한 선택기 내의 모든 필드를 개체로 그룹화합니다.

선택기는 XPath 식이기도 합니다. 팩트 탐색기에서 XML 스키마 탭에서 노드를 선택하면 Microsoft 규칙 작성기가 모든 노드의 XPath 선택기 속성과 자식 노드를 포함하지 않는 노드의 XPath 필드 속성을 자동으로 채웁니다. 또는 필요한 경우 XPath 선택기 및 XPath 필드에 대한 고유한 XPath 식을 입력할 수 있습니다. 선택기가 XML 문서의 여러 부분과 일치하는 경우 이 유형의 여러 개체가 규칙 엔진의 작업 메모리에서 어설션되거나 철회됩니다.

동일한 문서 내에서 여러 선택기를 사용할 수 있습니다. 이렇게 하면 문서의 여러 부분을 볼 수 있습니다. 예를 들어 한 섹션이 주문이고 다른 섹션에 배송 주소가 포함되어 있다고 가정합니다. 그러나 생성된 개체는 만든 XPath 문자열에 의해 정의됩니다. 다른 XPath 식을 사용하는 경우 식이 동일한 노드로 확인되더라도 결과는 고유한 TypedXmlDocument 엔터티입니다.

예를 들어 다음과 같은 XML이 있다고 가정합니다.

<root>
    <order customer="Joe">
        <item name="router" quantity="10" cost="550" />
        <item name="switch" quantity="3" cost="300" />
    </order>
    <order customer="Jane">
        <item name="switch" quantity="1" cost="300" />
        <item name="cable" quantity="23" cost="9.99" />
    </order>
</root>

선택기 /root/order 또는 순서를 사용하는 경우 다음 개체가 엔진의 작업 메모리에 추가됩니다.

개체 1

<order customer="Joe">
    <item name="router" quantity="10" cost="550" />
    <item name="switch" quantity="3" cost="300" />
</order>

개체 2

<order customer="Jane">
    <item name="switch" quantity="1" cost="300" />
    <item name="cable" quantity="23" cost="9.99" />
</order>

각 선택기 내에서 XPath는 개별 필드를 참조합니다. 따라서 선택기 /root/order/item, order/item 또는 항목을 사용하는 경우 다음 개체는 Joe에 대한 두 개의 항목과 Jane의 두 항목을 사용하여 엔진의 작업 메모리에 추가됩니다.

<root>
    <order customer="Joe">
    </order>
    <order customer="Jane">
    </order>
</root>

각 개체는 @name, @quantity 및 @cost 세 개의 필드에 액세스할 수 있습니다. 개체가 원본 문서(예 : .)에 대한 참조이므로 부모 필드를 참조할 수 있습니다. /@customer.

백그라운드에서 규칙 엔진은 XmlConvert 함수를 통해 텍스트 필드 값을 지원되는 형식 중 하나로 변환할 수 있습니다. Microsoft 규칙 작성기에서 유형을 설정하여 이 옵션을 지정할 수 있습니다. 변환이 가능하지 않으면 엔진에서 예외를 throw합니다. 부울 및 이중 형식은 해당 형식(문자열 또는 개체)으로만 검색할 수 있습니다.

Clear 함수

규칙 엔진 인스턴스에 대한 작업 메모리 및 안건을 다시 설정하려면 Microsoft 규칙 작성기 에서 Clear 함수를 사용합니다. 작업 메모리 및 의제에 대한 자세한 내용은 규칙 엔진 최적화를 참조 하세요.

규칙 엔진에 대한 작업 메모리 및 안건 다시 설정

RuleSet 탐색기 창에서 규칙 엔진에 대한 작업 메모리 및 안건을 지울 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 기본 제공 Clear 함수를 작업으로 추가합니다.

Clear 함수는 인수를 사용하지 않습니다.

Halt 함수

규칙 엔진에서 현재 실행을 중지하려면 Microsoft 규칙 작성기 에서 Halt 함수를 사용합니다.

규칙 집합 실행 중지

RuleSet 탐색기 창에서 규칙 집합 실행을 중지할 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 기본 제공 중지 함수를 작업으로 추가합니다.

Halt 함수는 단일 부울 인수를 사용합니다. 값을 true로 지정하면 규칙 엔진이 보류 중인 후보 규칙이 포함된 안건을 지웁니다.

Ruleset.Execute 메서드는 RuleEngine.Execute 메서드에 대한 래퍼이며 다음 코드와 유사한 코드를 사용합니다.

RuleEngine.Assert(facts);
RuleEngine.Execute();
RuleEngine.Retract(facts);

Ruleset.Execute 메서드를 사용하여 규칙 집합을 실행하는 경우 규칙 엔진은 Halt 함수가 실행되면 Ruleset.Execute 메서드에 컨트롤을 반환합니다. Ruleset.Execute 메서드는 팩트를 철회하고 호출자에게 컨트롤을 반환합니다. 이 경우 중지된 규칙 집합 실행을 다시 시작할 수 없습니다.

그러나 RuleEngine.Execute 메서드를 직접 사용하여 규칙 집합을 실행하는 경우 두 호출 사이에 필요한 개체를 철회하지 않은 경우 RuleEngine.Execute를 다시 호출하여 다음 보류 중인 규칙이 실행되고 중단된 규칙 집합 실행을 다시 시작할 수 있습니다.

참고 항목

Ruleset.Execute 메서드는 성능 향상을 위해 규칙 엔진 인스턴스를 캐시합니다. RuleEngine.Execute 메서드를 직접 사용하는 경우 규칙 엔진 인스턴스는 캐시되지 않습니다.

다음 샘플 코드에서는 중지된 규칙 집합 실행을 다시 시작하는 방법을 보여 줍니다.

// Assert facts into working memory of the rules engine instance.
RuleEngine.Assert(facts);

// Execute the ruleset.
RuleEngine.Execute();

// The ruleset invokes the Halt method when executing actions.
// Control returns here when the Halt function is called. 
// When engine halts, do the following tasks.

// Add your code here.

// Resume the halted rules engine execution.
RuleEngine.Execute();

// Retract or remove facts from working memory in the rules engine.
RuleEngine.Retract(facts);

Retract 함수

규칙 집합 및 규칙 엔진의 작업 메모리에서 개체를 제거하려면 Microsoft 규칙 작성기에서 Retract 함수를 사용합니다.

.NET 개체 철회

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업에서 Retract 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 .NET 클래스를 선택합니다.
.NET 클래스 탭에서 어셈블리나 메서드가 아닌 원하는 클래스를 Retract 매개 변수의 인수로 끕니다.

메서드를 Retract 함수로 끌면 엔진이 메서드에서 반환된 개체를 취소하려고 시도합니다.

.NET 개체를 취소하면 다음과 같은 영향이 있습니다.

개체를 사용하는 안건에 대한 작업은 의제에서 제거됩니다.

참고 항목

Retract 함수를 사용하기 전에 의제에서 상위에 있는 다른 작업이 이미 실행되었을 수 있습니다.
조건자의 개체를 사용하는 규칙은 의제에 작업이 있는 경우 해당 작업이 의제에서 제거됩니다.
엔진은 더 이상 개체를 평가하지 않습니다.

TypedXmlDocument 엔터티 또는 엔터티 철회

규칙 엔진에 어설션된 원래 TypedXmlDocument 엔터티를 취소하거나 부모 XmlDocument 엔터티에서 만든 TypedXmlDocument 자식 엔터티 중 하나를 취소할 수 있습니다.

다음 예제 XML이 있다고 가정합니다.

<order>
    <orderline customer="Joe" linenumber="001">
        <product name="router" quantity="10" cost="550" />
    </orderline>
    <orderline customer="Jane" linenumber="002">
        <product name="switch" quantity="1" cost="300" />
    </orderline>
</order>

Order 개체와 연결된 TypedXmlDocument 엔터티를 철회하거나 Orderline 개체와 연결된 TypedXmlDocument 엔터티 중 하나 또는 둘 다를 취소할 수 있습니다. 모든 TypedXmlDocument 엔터티는 XML 트리 계층 구조의 최상위 TypedXmlDocument 노드 위에 표시되는 TypedXmlDocument 엔터티가 아니라 원래 어설션된 최상위 TypedXmlDocument 엔터티와 연결됩니다.

예를 들어 제품은 Orderline 개체 아래의 TypedXmlDocument 엔터티이며 Orderline의 TypedXmlDocument 엔터티가 아닌 순서대로 TypedXmlDocument 엔터티와 연결됩니다. 대부분의 경우 이러한 구분은 중요하지 않습니다. 그러나 주문 개체를 철회하면 순서선 및 제품 개체도 철회됩니다. orderline 개체를 취소하면 제품 개체가 아니라 해당 개체만 철회됩니다.

엔진은 TypedXmlDocument 엔터티가 처음 어설션되었을 때 엔진이 만든 TypedXmlDocument 인스턴스인 개체 인스턴스에서만 작동하고 추적합니다. 규칙 집합의 선택기를 통해 선택한 노드에 대한 형제 노드와 같은 추가 노드를 만드는 경우 TypedXmlDocument 엔터티를 만들고 어설션하지 않는 한 이러한 노드는 규칙에서 평가되지 않습니다. 이러한 새 하위 수준 TypedXmlDocument 인스턴스를 어설션하는 경우 엔진은 규칙의 인스턴스를 평가하지만 최상위 TypedXmlDocument 엔터티에는 해당 인스턴스에 대한 지식이 없습니다. 최상위 TypedXmlDocument 가 철회되면 독립적으로 어설션된 TypedXmlDocument 엔터티가 자동으로 철회되지 않습니다. 따라서 새 노드가 만들어지면 전체 XmlDocument에서 Retract 및 Reassert를 수행합니다. 이는 일반적인 가장 간단한 단계입니다.

TypedXmlDocument 클래스는 작업의 일부로 사용자 지정 .NET 멤버 내에서 호출할 수 있는 유용한 메서드를 제공합니다. 이러한 메서드에는 TypedXmlDocument 또는 부모 TypedXmlDocument와 연결된 XmlNode를 가져오는 기능이 포함됩니다.

최상위 TypedXmlDocument 엔터티 철회

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업에서 Retract 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 스키마의 최상위 노드를 Retract 함수의 인수로 끕니다.

이 최상위 노드는 .xsd 확장에서 끝나고 문서 요소 노드가 아닌 문서 루트 노드를 나타냅니다. 노드에는 / 초기 TypedXmlDocument를 참조하는 선택기가 있습니다. 부모 TypedXmlDocument를 철회하면 규칙 집합에 사용되는 선택기를 기반으로 Assert 함수를 호출하여 만든 모든 TypedXmlDocument 엔터티를 포함하여 TypedXmlDocument와 연결된 모든 TypedXmlDocument 자식 엔터티가 작업 메모리에서 제거됩니다.

자식 TypedXmlDocument 엔터티 철회

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업에서 Retract 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 자식 노드를 Retract 함수의 인수로 끕니다.

RetractByType 함수

규칙 엔진의 작업 메모리에서 지정된 형식의 모든 개체를 제거하려면 Microsoft 규칙 작성기에서 RetractByType 함수를 사용합니다. 이 함수는 특정 형식의 특정 항목만 제거하는 Retract 함수와 다릅니다.

특정 형식의 모든 .NET 개체 철회

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 RetractByType 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 .NET 클래스를 선택합니다.
.NET 클래스 탭에서 클래스를 RetractByType 함수의 인수로 끕니다.

특정 형식의 모든 TypedXmlDocument 엔터티 철회

RetractByType은 동일한 DocumentType.Selector를 사용하여 모든 TypedXmlDocument 엔터티를 제거합니다.

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 RetractByType 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 적절한 노드를 RetractByType 함수로 끕니다.

Retract 함수와 일치하며, 문서 루트 노드에서 RetractByType 함수를 사용하는 경우 이 작업은 해당 DocumentType으로 어설션된 모든 TypedXmlDocument 엔터티뿐만 아니라 트리 계층 구조의 모든 자식 TypedXmlDocument 엔터티 또는 XmlNode 노드를 해당 부모 TypedXmlDocument 엔터티와 연결합니다.

Reassert 함수

엔진의 작업 메모리에 이미 있는 개체에서 Assert 함수를 호출하려면 Microsoft 규칙 작성기에서 Reassert 함수를 사용합니다. 동작은 개체에 대해 Retract 명령을 실행한 다음 Assert 명령을 실행하는 것과 같습니다.

예를 들어 .NET 개체에서 Reassert 함수를 사용하는 경우 규칙 엔진은 다음 단계를 수행합니다.

.NET 개체의 작업 메모리를 취소합니다.
조건자 또는 작업에서 개체를 사용하는 규칙에 대한 안건에 대한 작업을 제거합니다.
.NET 개체를 다시 작업 메모리로 어설션하고 새로 어설션된 개체로 평가합니다.
조건자의 개체를 사용하는 규칙을 다시 평가하고 해당 규칙의 작업을 적절하게 의제에 추가합니다.
이전에 true로 평가한 규칙의 안건에 대한 작업을 읽고 해당 작업에만 개체를 사용했습니다.

.NET 개체 다시 어셈블리

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 Reassert 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 .NET 클래스를 선택합니다.
.NET 클래스 탭에서 클래스를 Reassert 함수의 인수로 끕니다.

TypedXmlDocument 엔터티 재주문

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 Reassert 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 원하는 엔터티 노드를 Reassert 함수의 인수로 끕니다.

최상위 TypedXmlDocument 엔터티를 다시 어설션하는 경우 최상위 TypedXmlDocument 엔터티가 처음 어설션될 때 생성된 TypedXmlDocument 자식 엔터티는 각 TypedXmlDocument 자식 엔터티의 상태에 따라 다르게 동작할 수 있습니다.

예를 들어 새 엔터티나 기존 자식 엔터티가 "더티"인 경우 동작을 사용하여 규칙 집합에서 하나 이상의 필드가 변경된 경우 해당 자식에 대해 Assert 함수 또는 Reassert 함수가 수행됩니다. 더티가 아닌 기존 자식은 작업 메모리에 유지됩니다.

참고 항목

예를 들어 외부 애플리케이션이 해당 노드를 프로그래밍 방식으로 추가, 삭제 또는 업데이트하는 경우처럼 엔진에서 알지 못하는 외부 작업에서 노드가 더럽게 표시되지 않습니다.

다음 예제에서는 부모 엔터티가 다시 어설션될 때 자식 엔터티 동작을 설명하는 간소화된 시나리오를 보여 줍니다. 작업 메모리에 TypedXmlDocument 엔터티가 있다고 가정합니다. Parent, Child1, Child2 및 Child3.

상위 항목은 최상위 TypedXmlDocument 엔터티입니다.
각 자식에는 값이 1로 설정된 ExampleField 필드(예 Child1.ExampleField : = 1')가 포함됩니다.

규칙 동작이 자식 엔터티에 대해 다음 작업을 수행한다고 가정합니다.

Child2의 ExampleField 값이 1에서 0으로 업데이트됩니다.
사용자 코드는 Child3을 삭제합니다.
사용자 코드는 NewChild라는 새 TypedXmlDocument 자식 엔터티를 부모에 추가합니다.

다음 예제에서는 작업 중인 메모리에 있는 개체의 새 표현을 보여줍니다.

Parent
Child1 // Where Child1.ExampleField = 1
Child2 // Where Child2.ExampleField = 0
NewChild

이제 다음과 같은 자식 엔터티 동작이 발생하는 부모 엔터티를 다시 확인한다고 가정합니다.

자식2 는 필드가 업데이트된 후 더러워졌기 때문에 재주장됩니다.
Child3 이 작업 중인 메모리에서 취소됩니다.
NewChild 는 작업 메모리로 어설션됩니다.
Child1은 부모가 재주장되기 전에 업데이트되지 않았기 때문에 작업 메모리에서 변경되지 않은 상태로 유지됩니다.

Update 함수

새 데이터 및 상태에 따라 재평가를 위해 규칙 엔진에 개체를 재주장하려면 Microsoft 규칙 작성기 에서 업데이트 함수를 사용합니다. 개체에는 .NET 클래스 형식 또는 TypedXmlDocument 형식이 있을 수 있습니다. Update 함수를 사용하여 엔진 성능을 개선하고 무한 루프 시나리오를 방지할 수도 있습니다.

Important

규칙 다시 평가의 기본 최대 루프 수는 2^32이므로 특정 규칙의 경우 규칙 집합 실행이 오래 지속될 수 있습니다. 루프 수를 줄이려면 규칙 집합 버전에서 최대 실행 루프 깊이 속성을 변경합니다.

.NET 개체 업데이트

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 업데이트 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 .NET 클래스를 선택합니다.
.NET 클래스 탭에서 Update 함수의 인수로 클래스를 끕니다.

일반적으로 Assert를 사용하여 규칙 엔진의 작업 메모리에 새 개체를 배치하고 Update를 사용하여 작업 중인 메모리에 이미 있는 개체를 업데이트합니다. 새 개체를 팩트로 어설션하면 엔진이 모든 규칙의 조건을 다시 평가합니다. 그러나 기존 개체를 업데이트할 때 엔진은 업데이트된 팩트를 사용하는 조건만 다시 평가하고 이러한 조건이 true로 평가되는 경우 작업을 의제에 추가합니다.

예를 들어 다음 규칙이 있고 ItemA 및 ItemB라는 개체가 작업 메모리에 이미 있다고 가정합니다.

규칙 1은 ItemA에서 Id 속성을 평가하고 ItemB에서 ID 속성을 설정한 다음 변경 후 ItemB를 다시 하여 설정합니다. ItemB가 다시 어설션되면 엔진은 ItemB를 새 개체로 처리하고 엔진은 조건자 또는 작업에서 ItemB를 사용하는 모든 규칙을 다시 평가합니다. 이 동작은 엔진이 규칙 1에 설정된 대로 ItemB.Id 새 값에 대해 규칙 2를 다시 평가하도록 합니다.

규칙 1
```
IF ItemA.Id == 1
THEN ItemB.Id = 2
Assert(ItemB)
```
규칙 2는 첫 번째 평가에 실패할 수 있지만 두 번째 평가 중에 true로 평가됩니다.

규칙 2
```
IF ItemB.Id == 2
THEN ItemB.Value = 100
```

개체를 작업 메모리에 다시 추가하는 기능을 사용하면 전방 연결 시나리오의 동작을 명시적으로 제어할 수 있습니다. 그러나 이 예제에서는 규칙 1도 다시 평가되는 재어셈블리의 부작용을 보여줍니다. ItemA.Id 변경되지 않으면 규칙 1이 다시 true로 평가되고 Assert(ItemB) 작업이 다시 실행됩니다. 결과적으로 규칙은 무한 루프 상황을 만듭니다.

무한 루프 방지

무한 루프를 만들지 않고 개체를 재주장할 수 있어야 합니다. 이러한 시나리오를 방지하려면 Update 함수를 사용할 수 있습니다. Reassert 함수와 마찬가지로 Update 함수는 규칙 동작에 의해 변경되는 연결된 개체 인스턴스에서 Retract 및 Assert 함수를 수행하지만 다음과 같은 주요 차이점이 있습니다.

어젠다에서 인스턴스 유형이 조건자가 아닌 작업에서만 사용되는 경우 규칙에 대한 작업은 의제에 유지됩니다.
작업에서 인스턴스 형식만 사용하는 규칙은 다시 평가되지 않습니다.

따라서 조건자 또는 조건자 및 작업 모두에서 인스턴스 형식을 사용하는 규칙이 재평가되고 규칙의 작업이 적절하게 의제에 추가됩니다.

업데이트 함수를 사용하도록 앞의 예제를 변경하면 규칙 2의 조건이 ItemB를 사용하기 때문에 엔진이 규칙 2만 다시 평가하도록 할 수 있습니다. ItemB는 규칙 1*에 대한 작업에서만 사용되므로 엔진이 규칙 1을 다시 평가하지 않으므로 반복 시나리오가 제거됩니다.

규칙 1

IF ItemA.Id == 1
THEN ItemB.Id = 2
Update(ItemB)

규칙 2

IF ItemB.Id == 2
THEN ItemB.Value = 100

이런 방식으로 Update 함수를 사용하더라도 루프 시나리오를 만들 수 있는 가능성은 여전히 존재합니다. 예를 들어 다음 규칙을 고려합니다.

IF ItemA.Id == 1
THEN ItemA.Value = 20
Update(ItemA)

조건자는 ItemA를 사용하므로 ItemA에서 업데이트가 호출되면 엔진이 규칙을 다시 평가합니다. ItemA.Id 값이 다른 곳에서 변경되지 않으면 규칙 1은 계속 true로 평가되어 ItemA에서 업데이트를 다시 호출합니다.

규칙 디자이너는 이러한 루핑 시나리오를 만들지 않도록 해야 합니다. 이 문제를 해결하는 적절한 방법은 규칙의 특성에 따라 다릅니다.

다음 예제에서는 규칙의 작업이 처음 실행된 후 규칙이 다시 true로 평가되지 않도록 하는 ItemA.Value에 대한 검사를 추가하여 앞의 예제에서 문제를 해결하는 간단한 방법을 보여 줍니다.

IF ItemA.Id == 1 and ItemA.Value != 20
THEN ItemA.Value = 20
Update(ItemA)

TypedXmlDocument 엔터티 업데이트

RuleSet 탐색기 창에서 원하는 규칙을 찾아 선택합니다.
THEN 창의 작업 아래에서 업데이트 기본 제공 함수를 작업으로 추가합니다.
팩트 탐색기 창에서 XML 스키마를 선택합니다.
XML 스키마 탭에서 업데이트 함수의 인수로 원하는 엔터티 노드를 끕니다.

예를 들어 다음과 같은 규칙이 있다고 가정합니다.

규칙 1 은 구매 주문 메시지의 총 항목 수를 평가합니다.

IF 1 == 1
THEN ProcessPO.Order:/Order/Items/TotalCount = (ProcessPO.Order:/Order/Items/TotalCount + ProcessPO:/Order/Items/Item/Count)

규칙 2는 총 수가 10보다 크거나 같은 경우 상태를 "승인 필요"로 설정합니다.

규칙 2
```
IF ProcessPO.Order:/Order/Items/TotalCount >= 10
THEN ProcessPO.Order:/Order/Status = "Needs approval"
```

다음 구매 주문 메시지를 이 규칙 집합에 입력으로 전달하면 TotalCount가 14임에도 불구하고 상태가 "승인 필요"로 설정되지 않은 것을 알 수 있습니다. 이 동작은 TotalCount 값이 0인 경우에만 규칙 2가 시작 시 평가되기 때문에 발생합니다. TotalCount가 업데이트될 때마다 규칙이 평가되지 않습니다.

<ns0:Order xmlns:ns0="http://ProcessPO.Order">
    <Items>
        <Item>
            <Id>ITM1</Id>
            <Count>2</Count>
        </Item>
        <Item>
            <Id>ITM2</Id>
            <Count>5</Count>
        </Item>
        <Item>
            <Id>ITM3</Id>
            <Count>7</Count>
        </Item>
        <TotalCount>0</TotalCount>
    </Items>
    <Status>No approval needed</Status>
</ns0:Order>

TotalCount가 업데이트될 때마다 엔진이 조건을 다시 평가하도록 하려면 업데이트된 노드(TotalCount)에 대한 부모 노드(항목)에서 Update 함수를 호출해야 합니다. 다음과 같이 규칙 1을 변경하고 규칙을 한 번 더 테스트하면 상태 필드가 "승인 필요"로 설정됩니다.

규칙 1 (업데이트됨)

IF 1 == 1
THEN ProcessPO.Order:/Order/Items/TotalCount = (ProcessPO.Order:/Order/Items/TotalCount + ProcessPO:/Order/Items/Item/Count) AND
Update(ProcessPO.Order:/Order/Items)

다음을 통해 공유

Microsoft 규칙 작성기를 사용하여 규칙 실행을 최적화하는 작업에 컨트롤 함수 추가(미리 보기)

필수 조건

Assert 함수

.NET 개체 어설션

TypedXmlDocument 엔터티 어설션

Clear 함수

규칙 엔진에 대한 작업 메모리 및 안건 다시 설정

Halt 함수

규칙 집합 실행 중지

Retract 함수

.NET 개체 철회

TypedXmlDocument 엔터티 또는 엔터티 철회

최상위 TypedXmlDocument 엔터티 철회

자식 TypedXmlDocument 엔터티 철회

RetractByType 함수

특정 형식의 모든 .NET 개체 철회

특정 형식의 모든 TypedXmlDocument 엔터티 철회

Reassert 함수

.NET 개체 다시 어셈블리

TypedXmlDocument 엔터티 재주문

Update 함수

.NET 개체 업데이트

무한 루프 방지

TypedXmlDocument 엔터티 업데이트

피드백

추가 리소스

다음을 통해 공유

Microsoft 규칙 작성기를 사용하여 규칙 실행을 최적화하는 작업에 컨트롤 함수 추가(미리 보기)

필수 조건

Assert 함수

.NET 개체 어설션

TypedXmlDocument 엔터티 어설션

Clear 함수

규칙 엔진에 대한 작업 메모리 및 안건 다시 설정

Halt 함수

규칙 집합 실행 중지

Retract 함수

.NET 개체 철회

TypedXmlDocument 엔터티 또는 엔터티 철회

최상위 TypedXmlDocument 엔터티 철회

자식 TypedXmlDocument 엔터티 철회

RetractByType 함수

특정 형식의 모든 .NET 개체 철회

특정 형식의 모든 TypedXmlDocument 엔터티 철회

Reassert 함수

.NET 개체 다시 어셈블리

TypedXmlDocument 엔터티 재주문

Update 함수

.NET 개체 업데이트

무한 루프 방지

TypedXmlDocument 엔터티 업데이트

관련 콘텐츠

피드백

추가 리소스