...
When the rules engine reads a ruleset from the URL where it is located, the rules engine parses it, optimizes it, and caches the result. The next time the ruleset engine needs the ruleset it uses the cached copy, saving time in getting, parsing, and optimizing. This presents a challenge to the developer since changing the KRL in the ruleset doesn't tell the rules engine that new code is available.
| Info |
|---|
One frustrating part of using Github for a rule repository is that changes that are checked in can sometimes take several minutes to be seen in the raw URL. Even if you have flushed the ruleset from the rules engine, if Github returns the old content, you'll see the old behavior. You can't really do anything but wait this out. |
You can use the KRL Developer Tools to flush any ruleset you've registered, Click on "Registered Rulesets" and then on the ruleset you want to flush.
Clicking "Flush" will flush the selected ruleset.
The rules engine has an API for flushing rulesets so you can tell it that the code has changed. The The Tips for Developers gives gives instructions on how to use the API to flush rulesets. I usually take the time to set up a post-commit hook in Github when I use the Github repository for my rulesets so that a soon as I check them in, they have been flushed from the rules engine. This saves countless frustrating moments trying to figure out why your changes are being seen in the rules engine when in fact you just forgot to flush the ruleset from the rules engine.
...
Debugging the Ruleset
See Debugging KRL Rulesets for detailed information.
...