Rules depending on changing facts

[ruwentos]

I try to figure out what is expected behavior from the engine. The explanation says this:

NRules is an inference engine. It means there is no predefined order in which rules are executed, and it runs a match/resolve/act cycle to figure it out. It first matches facts (instances of domain entities) with the rules and determines which rules can fire. The rules that matched facts are said to be activated. It then resolves the conflict by choosing a single rule that will actually fire. And, finally, it fires the chosen rule by executing its actions. The cycle is repeated until there are no more rules to fire.

What 'conflict' does it mean here?

In my case I have two rules.
Rule 1 can fire immediately. Rule 2 cannot fire after init.
Rule 1 changes a fact. This change would make Rule 2 fire. It does not.

I then put .Do(ctx => ctx.Update(fact)) to the action of Rule 1. This makes Rule 2 fire.

Question: I expect from the above text that the engine notices a change of a fact and activates all rules again. I never read about an explicit 'Update'. How does it work correct?

[snikolayev]

@ruwentos first regarding the "conflict" resolution. The conflict occurs if multiple rules are able to fire at the same time. The engine has to choose one, and that is what's called conflict resolution. In your case there is no conflict.
The situation you are describing is what's called "forward chaining" - that is, inserting new facts or updating existing facts in the action of one rule, such that it activates another rule.
You DO need to tell the engine that you modified a fact, so you guessed it correctly, that you can use IContext.Update for that.
I recommend you read the wiki page about forward chaining if you haven't yet: https://github.com/NRules/NRules/wiki/Forward-Chaining
Also, this SO article might be helpful: https://stackoverflow.com/questions/49946688/best-way-to-achieve-forward-chaining-in-nrules

I hope this helps, please lmk if anything is unclear.

[ruwentos]

Thank you very much for your quick answer. It seems that I read it good the first time and did build my code according to that.

Big problem is, it really does not work like expected. One Rule alone works and produces the right output. As soon as the 2nd Rule joins in, it looks like it cancels out the first Rule. There is no logic to that.

I decided to bother you with my code as it is really not very complicated and finally my last chance with this library. I hope it's somehow my mistake.

Rule1:

[Name("Rule1")]
public class MatchIbanRule : Rule
{
    public override void Define()
    {
        RulesResult result = default;
        BankAccount bankAccount = default;
        Entry entry = default;

        When()
            .Match(() => result)
            .Match(() => entry)
            .Match(() => bankAccount,
                //bank account has same iban as entry 
                ba => ba.Iban == entry.Iban,
                //bank account is not iban matched already
                ba => !result.GetIbanMatchedBankAccounts(entry).Contains(ba));
        Then()
            .Do(ctx => result.AddIbanMatch(entry, bankAccount))
            .Do(ctx => ctx.Update(result));
    }
}

Rule2:

[Name("Rule2")]
public class MatchBankBankAccountNameRule : Rule
{
    public override void Define()
    {
        RulesResult result = default;
        BankAccount bankAccount = default;
        Entry entry = default;

        When()
            .Match(() => result)
            .Match(() => entry,
                //entry iban match had more then one bank account
                e => result.GetIbanMatchedBankAccounts(e).Count > 1)

            .Match(() => bankAccount,
                //entry should have iban matched this bank account
                ba => result.GetIbanMatchedBankAccounts(entry).Contains(ba),
                //bank account should not be name matched already
                ba => !result.IsNameMatched(entry, ba),
                //match the bank account name with the entry
                ba => entry.RelatedPartyAccount.Contains(ba.Name));
        Then()
            .Do(ctx => result.AddNameMatch(entry, bankAccount));
    }
}

The fact classes:

public class RulesResult
{
    private readonly Dictionary<Guid, List<BankAccount>> _ibanMatches;
    private readonly Dictionary<Guid, BankAccount> _nameMatches;

    public RulesResult()
    {
        _ibanMatches = new Dictionary<Guid, List<BankAccount>>();
        _nameMatches = new Dictionary<Guid, BankAccount>();
    }

    public List<BankAccount> GetIbanMatchedBankAccounts(Entry entry)
    {
        return !_ibanMatches.ContainsKey(entry.Id) ? new List<BankAccount>() : _ibanMatches[entry.Id];
    }

    public void AddIbanMatch(Entry entry, BankAccount bankAccount)
    {
        if (!_ibanMatches.ContainsKey(entry.Id))
        {
            _ibanMatches.Add(entry.Id, new List<BankAccount>{bankAccount});
        }
        else
        {
            _ibanMatches[entry.Id].Add(bankAccount);
        }
    }

    public bool IsNameMatched(Entry entry, BankAccount bankAccount)
    {
        return _nameMatches[entry.Id].Id == bankAccount.Id;
    }

    public void AddNameMatch(Entry entry, BankAccount bankAccount)
    {
        _nameMatches.Add(entry.Id, bankAccount);
    }
}

public class BankAccount
{
    public Guid Id { get; set; }
    public string Iban { get; set; }
    public string Name { get; set; }    
}

public class Entry
{
    public Guid Id { get; set; }
    public string Iban { get; set; }    
    public string RelatedPartyAccount { get; set; }    
}

and finally the test:

[Fact]
public void RunSimpleTest()
{
    //fixture
    var fixture = new AutoFixture.Fixture();

    //Load rules
    var repository = new RuleRepository();
    repository.Load(x => x.From(Assembly.GetAssembly(typeof(Payment_MS.Program))));
    //repository.Load(x => x.From(typeof(MatchIbanRule).Assembly));
    //repository.Load(x => x.From(typeof(MatchBankBankAccountNameRule).Assembly));
    var rules = repository.GetRuleSets().Select(rs=>rs.Rules.Select(r=>r.Name)).ToList();

    //Compile rules
    var factory = repository.Compile();
    
    //Create a working session
    var session = factory.CreateSession();
    
    //Load domain model
    const string iban1 = "DE12500101170648489890";
    const string iban2 = "NL12500101170648489890";
    const string name1 = "man";
    const string name2 = "vrouw";
    const string name3 = "iemand";
    const string relatedParty1 = "dit is een man account";
    const string relatedParty2 = "dit is een vrouw account";

    var bankAccounts = new List<BankAccount>
    {
        fixture.Build<BankAccount>()
            .With(ba => ba.Iban, iban1)
            .With(ba => ba.Name, name1)
            .Create(),
        fixture.Build<BankAccount>()
            .With(ba => ba.Iban, iban1)
            .With(ba => ba.Name, name2)
            .Create(),
        fixture.Build<BankAccount>()
            .With(ba => ba.Iban, iban2)
            .With(ba => ba.Name, name3)
            .Create(),
        fixture.Create<BankAccount>()
    };

    var entries = new List<Entry>
    {
        fixture.Build<Entry>()
            .With(en => en.Iban, iban1)
            .With(en => en.RelatedPartyAccount, relatedParty1)
            .Create(),
        fixture.Build<Entry>()
            .With(en => en.Iban, iban1)
            .With(en => en.RelatedPartyAccount, relatedParty2)
            .Create(),
        fixture.Build<Entry>()
            .With(en => en.Iban, iban2)
            .Create(),
    };

    var result = new RulesResult();

    //Insert facts into rules engine's memory
    session.InsertAll(bankAccounts);
    session.InsertAll(entries);
    session.Insert(result);

    //Start match/resolve/act cycle
    var fired = session.Fire();

    //Assert
    //Assert.True(result.IsTrue);
    //Assert.True(entry.Allocated);
}

Rule1 alone fires as expected 5 times. Rule2 alone fires never as expected. Rule1 and Rule2 together never fire either unexpected.

By the way. Debugger Visualizer does not compile. I uses VS 2019, DGML editor enabled.

C:\Program Files\dotnet\sdk\5.0.402\Microsoft.Common.CurrentVersion.targets(2203,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.DebuggerVisualizers". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionObjectSource.cs(2,17): error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionPerformanceObjectSource.cs(2,17): error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionPerformanceObjectSource.cs(7,51): error CS0246: The type or namespace name 'VisualizerObjectSource' could not be found (are you missing a using directive or an assembly reference?) [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionObjectSource.cs(8,40): error CS0246: The type or namespace name 'VisualizerObjectSource' could not be found (are you missing a using directive or an assembly reference?) [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionObjectSource.cs(10,30): error CS0115: 'SessionObjectSource.GetData(object, Stream)': no suitable method found to override [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]
C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\SessionPerformanceObjectSource.cs(9,30): error CS0115: 'SessionPerformanceObjectSource.GetData(object, Stream)': no suitable method found to override [C:\Data\Versiebeheer\NRules\src\NRules.Debugger.Visualizer\NRules.Debugger.Visualizer.DebuggeeSide\NRules.Debugger.Visualizer.DebuggeeSide.csproj]

[a046]

I haven't looked into your example in detail, so can't answer your problem sorry. But using dictionaries and lists in rule actions and conditions like this might be counterproductive in NRules as the Rete network isn't aware of your data structures and any updates to them.

It would be preferable to move this type of logic into the patterns in a way that can be represented in the Rete network, with joined facts for example. Otherwise any update to your result object/dictionary is possibly activating the rules dependent on it and might regress overall performance to sequential processing.

[snikolayev]

@ruwentos it's a bit hard for me to figure out from this code what exactly is the desired behavior, but simply looking at it mechanically, it seems the implementation of IsNameMatched does not account for a case where the dictionary does not contain a key. Because of this it just blows up. Changing it to the following fixed it for me, and the second rule fired twice.

public bool IsNameMatched(Entry entry, BankAccount bankAccount)
{
    return _nameMatches.TryGetValue(entry.Id, out var entryBankAccount) && entryBankAccount.Id == bankAccount.Id;
}

But I'm totally with @a046 regarding these elaborate internal data structures that you created, to keep track of which rules fired. Seems overly complex, potentially misusing the engine.
I took a guess at what you are trying to do with these rules. Looks like you are looking for cases where there are multiple bank accounts associated with a given entry, and out of those bank accounts selecting the one where the name is contained within the RelatedPartyAccount field. Here is my take at writing a rule for this:

    public class SearchResult
    {
        public BankAccount BankAccount { get; }

        public SearchResult(BankAccount bankAccount)
        {
            BankAccount = bankAccount;
        }
    }


    public class FindAccountsWithMatchingNamesRule : Rule
    {
        public override void Define()
        {
            BankAccount bankAccount = default;
            Entry entry = default;

            When()
                .Match(() => entry)
                .Query(() => bankAccount, q => q
                    .Match<BankAccount>(
                        ba => ba.Iban == entry.Iban)
                    .Collect()
                    .Where(c => c.Count() > 1)
                    .Select(c => c.First(x => entry.RelatedPartyAccount.Contains(x.Name)))
                );

            Then()
                .Yield(x => new SearchResult(bankAccount));
        }
    }

Then in the test code after calling Fire you can query the session and get your search results:

            var fired = session.Fire();
            var results = session.Query<SearchResult>().ToArray();

I hope this helps

[ruwentos]

Thank you very much both @a046 and @snikolayev.

First about my bug in the 'IsNameMatched' function.
It worries me a bit that such a violation does not crash into my face. Instead the code just runs and says nothing. Even the error events of the session did not fire.
Then I changed the function (like @snikolayev did) but still it is not running.

Anyway I learned from your responses that my approach was a bit 'unorthodox'.
In the suggestion of @snikolayev everything would be in one rule.

When()
      .Match(() => entry)
      .Query(() => bankAccount, q => q
          .Match<BankAccount>(
              ba => ba.Iban == entry.Iban)
          .Collect()
          .Where(c => c.Count() > 1)
          .Select(c => c.First(x => entry.RelatedPartyAccount.Contains(x.Name)))
      );

Obviously we have a different definition of 'not complicated'.
What I'm looking for is a set of easy to understand rules.
First rule matches entry ibans with bank account ibans.
2nd rule fixes all cases where an entry iban matches more than one bank account ibans by matching those cases with the name.

The example code of @snikolayev gave me a hint how to do it better (hopefully).

[Name("Rule1")]
public class MatchIbanRule : Rule
{
    public override void Define()
    {
        BankAccount bankAccount = default;
        Entry entry = default;

        When()
            .Match(() => entry)
            .Match(() => bankAccount,
                //bank account has same iban as entry 
                ba => ba.Iban == entry.Iban);
        Then()
            //add a result to engine memory
            .Do(ctx => ctx.Insert(new RulesResult(bankAccount, entry)));
    }
}

[Name("Rule2")]
public class MatchBankBankAccountNameRule : Rule
{
    public override void Define()
    {            
        RulesResult result = default;
        RulesResult doubleResult = default;            

        When()
            .Match(() => result)
            .Match(() => doubleResult,
            //entries are the same
            dr => dr.Entry.Id == result.Entry.Id,
            //bank accounts are not the same
            dr => dr.BankAccount.Id != result.BankAccount.Id,
            //related party account does not contain bank account name
            dr => !dr.Entry.RelatedPartyAccount.Contains(dr.BankAccount.Name));
            
        Then()
            //delete this result from engine memory
            .Do(ctx => ctx.Retract(doubleResult));
    }
}

public class RulesResult
{
    public BankAccount BankAccount { get; set; }
    public Entry Entry { get; set; }

    public RulesResult(BankAccount bankAccount, Entry entry)
    {
        BankAccount = bankAccount;
        Entry = entry;
    }
}

This gives the expected outcome although Rule2 already gets a bit to complicated again for my taste.
Perhaps there is a more easy way for Rule2. But I must admit that I have a hard time to get familiar with the 'Query' option .

Other thing what worries me a bit is that I do not have a decent understanding what inserting and retracting facts does to the engine. Apparently the 'insert' made Rule2 run. But why did not the 'retract' made Rule1 run again?

[snikolayev]

@ruwentos first, I have to amend what I said yesterday about the IsNameMatched. Apparently, as I was copying your code and then playing with it to debug, I changed the string constants you defined, and so I was getting an exception. It was loud and clear - both, popping up in the corresponding error event handler and eventually bubbling up and crashing the program. I just updated the constants back to the values you had, and it's not throwing. So, IsNameMatched was a red herring. And you don't need to be worried about exception handling - that part works as expected.

But given the new rule structure, I don't think we need to spend more time talking about those original rules, and instead look at this new approach.

This is definitely closer to what a more canonical implementation should be like. It's fine if you want to break the logic up into multiple rules that are "composed" together via forward chaining.
The reason you are finding the second rule so complicated is exactly because you are not using the Query construct. The logic you are trying to define, naturally operates on a collection of values (i.e. "more than one matching account"), and Query is the right tool for that. I think you should use the rule I gave above as a model to write your rule 2.

Think of the Query as a Linq pipeline. Match a fact -> Collect facts into a collection -> Filter to only have collections with more than 1 element -> select the first element of the collection. And bind the result to a variable.

I'm also not sure why you are trying to retract the RulesResult fact at the end of rule 2.

As far as understanding how the rules engine works, I strongly recommend reading the wiki. Also consider reading about the Rete algorithm (wikipedia is a good start).
In short, think of engine's working memory as a giant collection of facts. And rules define patterns that match objects in working memory. If a rule matches a set of facts, it's activated (i.e. ready to fire), then one of the active rules actually runs (fires) potentially updating the working memory, changing which rules are active. And so on.
A rule is activated ONLY if its inputs change. So, naturally, when you insert a new RulesResult fact, it alters inputs for rule 2 and activates it. When you retract this fact, it does nothing, because RulesResult is not in the inputs of rule 1. And in general, retraction "removes" the fact from memory, and firing rules for "absent" facts is a totally different story (see Not pattern), so I wouldn't worry about it at this point.

[ruwentos]

Hoi @snikolayev,
many thanks for your reply.

I think I'm on track now.

Just one thing I do not quite understand. Why should I not retract the RulesResult fact in rule 2?

I'm sure you understand that rule1 matches entries and bank accounts by IBAN. Where rule2 takes the wrong matches out by looking for a match in a name string. The match of the IBAN is vital. The name match is just an opportunity to solve a non exact IBAN match.

I wonder what you had in mind.

[snikolayev]

@ruwentos in general, there is nothing wrong with your approach and you can keep going down that path. But my point is that instead of building a state machine using rules, where rules add and then remove facts (or worse, manage external data structures like dictionaries in your first attempt), I would rather create a logical flow. So, the first rule creates iban/entry matches. The second rules would select the valid ones and create new facts (e.g. ValidResult). This way the flow of logic through rules is unidirectional, producing immutable facts. Easier to reason about it.
But as I said, both approaches are fine.

[ruwentos]

Thank you @snikolayev,
I understand. So when a rule produces facts, then this facts should be of a different type than the rule produced that ran before. This would produce a traceable flow of rule processing.