The pre-registration of rules is what we're currently trying to get away from.
We basically want our rules to be found and loaded as needed. The problem is
the rules are executed at the OpenMRS level (created by the Arden translator).
We can't directly register rules to our provider from there since the provider
is down in a module. We need something to call before we call eval on a rule
to make sure it's loaded (or it won't be found):
Rule 1:
///////////////////////////////////////////////////////////////////////////////////////
Result result = context.eval(patient.getPatientId(), "ChicaAgeRule",
parameters);
///////////////////////////////////////////////////////////////////////////////////////
Rule 1 is calling the "ChicaAgeRule" from within it. We need some mechanism to
ensure the "ChicaAgeRule" is loaded (and load it if it's not) before we call
eval. Since we're trying to avoid pre-registering all the rules, there isn't a
good way to get them loaded.
One possibility is to have the "getRule" method in a rule provider be dual
purpose. It can load and possibly register the rule if it's not currently
registered. The rule provider would then have to be passed in parameters of
the eval method. The Arden translator could create something like this:
Rule 1:
///////////////////////////////////////////////////////////////////////////////////////
RuleProvider ruleProvider = (RuleProvider)parameters.get("ruleProvider");
If (ruleProvider != null) {
ruleProvider.getRule("ChicaAgeRule");
}
Result result = context.eval(patient.getPatientId(), "ChicaAgeRule",
parameters);
///////////////////////////////////////////////////////////////////////////////////////
This doesn't seem the best way to do it, but I'm not sure of another way since
we're trying to avoid pre-registration. This is basically why we were
proposing to add a new "loadRule" method to the logicService interface so we
could AOP around it and load our rules:
Rule 1:
///////////////////////////////////////////////////////////////////////////////////////
logService.loadRule("ChicaAgeRule", false);
Result result = context.eval(patient.getPatientId(), "ChicaAgeRule",
parameters);
///////////////////////////////////////////////////////////////////////////////////////
Thanks,
Steve
From: Darius Jazayeri [mailto:[email protected]]
Sent: Thursday, September 01, 2011 10:22 AM
To: McKee, Steven Jay
Cc: dev; Dugan, Tammy Marie
Subject: Re: New LogicService method
Yes, you could register your static rules in the afterStartup method on a
RuleProvider. (That's exactly what that method is for.)
E.g. the handler in the logic module that handles dynamically-defined rules in
groovy or java does:
/**
* @see org.openmrs.logic.rule.provider.AbstractRuleProvider#afterStartup()
*/
@Override
public void afterStartup() {
TokenService tokenService = Context.getService(TokenService.class);
RuleDefinitionService service =
Context.getService(RuleDefinitionService.class);
for (RuleDefinition rd : service.getAllRuleDefinitions()) {
tokenService.registerToken(rd.getName(), this, rd.getId().toString());
}
}
Also, do make sure you extend AbstractRuleProvider rather than just
implementing RuleProvider, in case that interface ends up getting methods added
later.
-Darius
On Thu, Sep 1, 2011 at 8:15 AM, McKee, Steven Jay
<[email protected]<mailto:[email protected]>> wrote:
I can see this approach working well for our dynamic class loading:
1. The class loader task looks for new classes.
2. Once found, the rules get registered to our DSS rule provider.
3. The DSS rule provider would use our compiling classloader to locate
the file in the "getRule" method.
We still, however, have the issue of our static rules in some of our modules.
We want to be able to use these on the fly, so how would be initially get these
rules registered? Would be have to write some sort of task to do this on
startup? Is there anything in logic that provides us a way of doing this? I
noticed there's an "afterStartup" method in the RuleProvider interface. What
exactly is this used for?
Thanks,
Steve
From: Darius Jazayeri [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, August 31, 2011 5:34 PM
To: McKee, Steven Jay; dev
Cc: Dugan, Tammy Marie
Subject: Re: New LogicService method
Moving this to the developers list.
The way this is supposed to work is that if you have a rule (YourRule.java) and
you want it to be accessible as the token "Your Rule", then you need to do
something like this:
TokenService.registerToken("Your Rule", chicaRuleProvider,
"InternalUniqueIdOfYourRule");
Then when LogicService.getRule("Your Rule") is called, that will delegate to:
chicaRuleProvider.getRule("InternalUniqueIdOfYourRule");
Presumably you have a RuleProvider in your module already? (Even if you're
bypassing LanguageHandler, I think RuleProvider is necessary...)
The logic infrastructure will cache these rules (since they may be expensive to
compile) so if you want it to forget a cached value, you'd do:
TokenService.notifyRuleDefinitionChanged("Your Rule");
It seems like these methods should be sufficient for what you're trying to do.
(Adding a method to LogicService is pretty significant to do, because that's a
change to the core api, which requires simultaneous releases of new versions of
1.6.x, 1.7.x, and 1.8.x, to support the new logic module. It's possible that we
end up doing this, but it can't happen quickly.)
-Darius
On Tue, Aug 30, 2011 at 2:42 PM, McKee, Steven Jay
<[email protected]<mailto:[email protected]>> wrote:
We are currently bypassing the dynamic rule code and language handlers. We
need the ability to load rules on the fly instead of pre-loading them. It just
gives us a lot of flexibility and the benefit of not loading rules we may not
use.
Thanks, Darius.
Steve
From: Darius Jazayeri [mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, August 30, 2011 2:04 PM
To: McKee, Steven Jay
Cc: Dugan, Tammy Marie
Subject: Re: New LogicService method
Hi steve
I'm out and about at the moment, but will try to reply on the dev list today
out tomorrow.
Isn't there already a workflow so your rule provider can update loaded rules
though? Or have you ended up bypassing the dynamic rule code and language
handlers I put in?
-Darius (by phone)
On Aug 30, 2011 1:17 PM, "McKee, Steven Jay"
<[email protected]<mailto:[email protected]>> wrote:
Darius,
CHICA is very close to finishing the upgrade to OpenMRS 1.7.x, but we're
needing an additional method added to the LogicService interface:
/**
* Loads a rule into memory so it can be used. It will also update the
rule metadata if
* required.
*
* @param token the lookup key ("token") for the rule to be loaded.
* @param updateRule Whether or not the rule metadata needs to be updated
once loaded.
* @throws LogicException if an error occurs loading a rule.
*/
public void loadRule(String token, boolean updateRule) throws
LogicException;
CHICA currently has the same method in its DSS module which looks in various
places to load a rule into memory. We currently have hardcoded places in our
code to load specific rules before any other rules are executed. We want to be
able to remove the hardcoded loading of the rules so we can be more dynamic
about it.
Here's what we are proposing to do:
1. Add the new LogicService method.
2. Update the Arden parser to create Java calls that execute the loadRule
method on an inner rule before calling "eval".
logicService.loadRule("LocationAttributeLookup", false);
Result result = context.eval(patient.getPatientId(),
"LocationAttributeLookup",parameters);
3. For the time being the implementation of the loadRule method in the
logic module will do nothing.
4. We will set up an AOP call for the method in our DSS module so we can
call our own loadRule to get the correct rule into memory.
5. The AOP call is a temporary fix until we can eventually get some of
our DSS code moved into logic in the future. But we're very close to our
upgrade deadline at the moment.
The "updateRule" parameter for the method is used to tell the code whether or
not the metadata about the rule should be updated. Most of the time in normal
operating conditions this will be false. The case where we would supply true
is when are class loading scheduled task is looking for new rules. Once it
finds a new rule, we want the newest metadata (and registration) for it.
Thanks,
Steve McKee
Children's Health Services Research
Indiana University School of Medicine
Phone: 317-278-9660<tel:317-278-9660>
Email: [email protected]<mailto:[email protected]>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
