Re: IFactRetirever -- can we parameterize on already asserted fact

Shadow,

Hope i understand your question :)

As far as i know, UpdateFacts method will be called before your Current
rule is being executed, so i dont think it possible in a single roundtrip to
rule engine from orchestration. If you call two different ruleset from
orchestration one after the other,

the first one could mark your xmldocument parameter in global location such
as config column in databae table as follows

Table Name : TBL_config
1. Column Name: Col_Key
Value : (your xmldocument value ) say for ex 30.
2. Coulm Name : UpdatedDatetime
Value : <CurrentDateTime>

second call rules will use your longterm facts (needs to be refreshed every
time you change "Col_key" , hope you know well about the use of
"factsHandleIn" parameter).

instead of doing default (factHadleIn=null) check you have to check for

IF (TBL_CONFIG.UPDATETIME IS CHANGED WITH IN LAST EXECUTEION)

Follow

then your longterm fact SQL query would go as

SELECT NAME,AGE FROM TBL_EMP WHERE AGE IN (SELECT COL_KEY FROM TBL_CONFIG).

Got it?.

Seems not looks like a simple soultion, Just thought of suggesting you ..

Cheers,
Selvan
http://biztek.blogspot.com/



"shadow123" wrote:

Thank you for your response Leonid.

I am sorry, but I don't quite understand the question. I would like to use
long term facts, but not through the use of DataConnection. The reason I
would like to assert them in a fact retriever is that I would like to use a
caching block, which would expire on a SQL 2005 dependency. The problem is
that the query I would need to generate is dependent upon the XMLDocument
currently processed by the rules engine. If I can not gain access to that
document I can not parameterize my query, and thus have to retrieve the
entire table which I would live to avoid.

To simplify I would like to gain access to the XMLDocument from the
UpdateFacts method so that I can run the SQL query and populate my cache.
Then whenever UpdateFacts is invoked in the future I can determine if that
data has been cached and assert it into the BRE without going to the database.

Please let me know if this makes more sense.

Eugene Tsimberg

"Leonid Ganeline" wrote:

Why don't use the long-term facts?
Please, explain, which point do you want to access the asserted facts from ?

--
Regards

Leonid Ganeline
BizTalk Solution Developer

Microsoft Certified Technology Specialist: BizTalk Server 2006
http://geekswithblogs.com/leonidganeline
================================


"shadow123" <shadow123@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:31809B8F-1EA6-4FFA-88CD-560AEC2ACDB4@xxxxxxxxxxxxxxxx
Hello all,

I am implementing a BRE policy which has a custom fact retriever. I have
some long term data which needs to be pulled from the database and used as
facts in some of the rules. Unfortunately the database table in question
has
millions of records and thus I don't wan to get and then assert the entire
table as a fact. I planned to parameterize my SQL query based on some of
the
facts asserted into the Rule Engine by the orchestration, but I can not
figure out how to access already existing facts from the UpdateFacts
method.
My suspicion is that I have to go though the engine variable, but I can't
figure out how to get to the already asserted facts.

Any thoughts on the subject are welcome. I am about ready to give up, and
to generate my facts inside the orchestation as .NET objects, which may be
the right thing to do anyway.

Thank you so much.

.