|
Home > Archive > BizTalk Server General > April 2005 > Rules engine questions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Rules engine questions
|
|
|
| I have the following questions regarding the rules engine and framework that
I hope someone can help answer:
1. When you are calling a policy from within an orchestration I assume at
this point the policy 'loads'. When a policy loads, does it first read
through all of the rules and then based on ones that are valid (given the
current facts), set an agenda?
2. What is the duration of a policy execution cycle? I mean is it dumped as
soon as the orchestration is finished?
3. How do you limit the number of times the rules engine will cycle through
the rules...forward chaining etc?
4. When you are setting up your rules within the Rules Composer, you have to
select a Fact Retriever. Do the components that show up in this list have to
have implemented the IFactRetriever interface?
5. I have seen samples of fact retriever components. What I can't understand
is that there is an 'object' paramenter coming into to fact retriever
component. Does the fact retriever component have to somehow know the
structure of this object to get data out of it? So for example if I pass
this component an XML document do I then have to cast the object back to
XMLDocument?
Thanks for any help.
STom
| |
| Matt Milner 2005-04-28, 2:47 am |
| Comments inline:
"STom" <stombiztalker@hotmail.com> wrote in message
news:uK1v2rzSFHA.228@TK2MSFTNGP12.phx.gbl...
>I have the following questions regarding the rules engine and framework
>that I hope someone can help answer:
>
> 1. When you are calling a policy from within an orchestration I assume at
> this point the policy 'loads'. When a policy loads, does it first read
> through all of the rules and then based on ones that are valid (given the
> current facts), set an agenda?
Essentially, I think you have it. The conditions are all evaluated and
those that evalutate to true are added to the agenda. Rules are then fired
in order of priority. If the rules update or assert new facts, those
conditions that were evaluated may need to be reevaluated.
> 2. What is the duration of a policy execution cycle? I mean is it dumped
> as soon as the orchestration is finished?
I'm not sure what you are asking here, but the policy object will be
disposed when the policy is done being executed.
> 3. How do you limit the number of times the rules engine will cycle
> through the rules...forward chaining etc?
The cycling will depend on the way you structure your rules. You need to set
them up so you don't cycle, but the policy has a property on it that lets
you set the maximum number of iterations. I believe you'll get an exception
if you hit this limit (you definitely do when testing in the composer).
> 4. When you are setting up your rules within the Rules Composer, you have
> to select a Fact Retriever. Do the components that show up in this list
> have to have implemented the IFactRetriever interface?
You don't have to set a fact retriever unless you need one. The fact
retriever asserts long term facts into the engine at execution time and can
update them as needed. If you have short term facts like .Net components,
or xml documents, those generally get passed in as parameters from the
orchestration or your .net code. And yes, you have ot implement
IFactRetriever if you want to perform this function.
> 5. I have seen samples of fact retriever components. What I can't
> understand is that there is an 'object' paramenter coming into to fact
> retriever component. Does the fact retriever component have to somehow
> know the structure of this object to get data out of it? So for example if
> I pass this component an XML document do I then have to cast the object
> back to XMLDocument?
>
The object is poorly named in my opinion, but is essentially your state
object that you can use to determine if you should update your facts. The
handle will always be null the first time your fact retriever is called.
After that, it will be whatever you handed back from this method. So you
will know what the object is because you create it in the fact retriever and
hand it back. This could be a date time, for example, that you then check
and update as needed.
HTH,
Matt
> Thanks for any help.
>
> STom
>
| |
|
| Thanks Matt...thats what I needed to know!
"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:ufFMXi5SFHA.1384@TK2MSFTNGP09.phx.gbl...
> Comments inline:
>
>
> "STom" <stombiztalker@hotmail.com> wrote in message
> news:uK1v2rzSFHA.228@TK2MSFTNGP12.phx.gbl...
>
> Essentially, I think you have it. The conditions are all evaluated and
> those that evalutate to true are added to the agenda. Rules are then
> fired in order of priority. If the rules update or assert new facts,
> those conditions that were evaluated may need to be reevaluated.
>
>
> I'm not sure what you are asking here, but the policy object will be
> disposed when the policy is done being executed.
>
>
> The cycling will depend on the way you structure your rules. You need to
> set them up so you don't cycle, but the policy has a property on it that
> lets you set the maximum number of iterations. I believe you'll get an
> exception if you hit this limit (you definitely do when testing in the
> composer).
>
>
> You don't have to set a fact retriever unless you need one. The fact
> retriever asserts long term facts into the engine at execution time and
> can update them as needed. If you have short term facts like .Net
> components, or xml documents, those generally get passed in as parameters
> from the orchestration or your .net code. And yes, you have ot implement
> IFactRetriever if you want to perform this function.
>
> The object is poorly named in my opinion, but is essentially your state
> object that you can use to determine if you should update your facts. The
> handle will always be null the first time your fact retriever is called.
> After that, it will be whatever you handed back from this method. So you
> will know what the object is because you create it in the fact retriever
> and hand it back. This could be a date time, for example, that you then
> check and update as needed.
>
> HTH,
> Matt
>
>
>
>
|
|
|
|
|