BizTalk业务规则，用于检查.csv，xml等中包含的值列表

Question

I'm new to BRE and fairly new to BizTalk as a whole, so this may be quite simple and just evading me...

What I'd like to do is this: create a business rule in BRE that takes as an input the incoming message and checks to see if a value contained in message matches any of the values within a specified set of values. A sample message is as follows. The <isFound> field would then be updated accordingly.

<n1:DocumentTemplate xmlns:n1="mynamespace">
    <rootOid>2.16.840.1.113883.3.51.60.2.5</rootOid>
    <isFound>false</isFound>
</n1:DocumentTemplate>

Basically I'd like to match the <rootOid> node against a list of values. I've already created a business that will match the <rootOid> against a hardcoded value in the Conditions of the business rule...just as a proof of concept to learn the basics of how to use the BRE and call a rule in an orchestration.

I'm failing to find a way to match against a list of values beyond doing a giant list of hard-coded ORs in the "Conditions" of the Business Rule. The list of accepted values is large enough that doing a bunch of ORs is not going to work.

Ideally, I'd like to have a maintainable XML file full of acceptable <rootOid> values to check against from within the business rule.

I also realize that there is a way to call a database and read the values from a table/column for matching, but I'd rather keep SQL out of the equation so that this can be a little more self-contained.

Answer 1

One "Equal" expression is enough. Your RHS fact should be another vocabulary item. In case of XML type a proper path will pull all values one by one and cause multiple evaluations and respectively firing an action if there's a match. The key to remember: BRE is a pattern matching engine.

The vocabulary is just a convenient alias for the fact definition. Let's say you create an XML file with the following structure:

<options>
  <value>A</value>
  <value>B</value>
  <value>C</value>
</options>

Define a vocabulary for this fact as Name: PossibleValues XPath Selector: /options/value XPath Field: .

Then defining a rule as IF currentValue == PossibleValues will cause three condition evaluations as the RHS yields three facts into the working memory. Consequently, only those that were true will fire a rule (Action). Compare this to the default definition BRE creates when you pick a node from the XML schema which will only assert one (first) fact:

XPath Selector: /options/ XPath Field: value

(namespaces omitted for brevity)

At runtime pass this XML document as an argument to the BRE (whether in the orchestration or in .Net component depending on BRE invocation context). At design time for testing you have to implement Fact Creator component (implements IFactCreator) to provide an instance of required arguments.

Long-term facts (like the one in the question) are better managed using custom fact retrievers. Fact retriever is a .Net component that implements IFactRetriever. See the documentation for details. Inside fact retriever implementation load XML (from disk) and assert it into the working memory as TypedXmlDocument.