BizTalk Business Rule для проверки списка значений, содержащихся в .csv, xml и т. Д.

Question

Я новичок в BRE и довольно новичок в BizTalk в целом, поэтому это может быть довольно просто и просто уклоняться от меня ...

Я хотел бы сделать следующее: создать бизнес-правило в BRE, которое принимает в качестве входного входящего сообщения и проверяет, соответствует ли значение, содержащееся в сообщении, любому из значений в указанном наборе значений. Образец сообщения выглядит следующим образом. Затем поле <isFound> будет соответствующим образом обновляться.

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

В основном я хотел бы, чтобы соответствовать <rootOid> узел со списком значений. Я уже создал бизнес, который будет соответствовать <rootOid> в отношении жестко заданного значения в Условиях бизнес-правила ... как доказательство концепции, чтобы изучить основы использования BRE и вызвать правило в оркестровке.

Я не могу найти способ сопоставления со списком значений за пределами гигантского списка жестко закодированных ОР в «Условиях» бизнес-правила. Список принятых значений достаточно велик, что выполнение группы ORs не будет работать.

В идеале, я хотел бы иметь поддерживаемый XML-файл, полный допустимых значений <rootOid>, чтобы проверять его в рамках бизнес-правила.

Я также понимаю, что существует способ вызова базы данных и считывания значений из таблицы/столбца для сопоставления, но я бы предпочел оставить SQL из уравнения, чтобы это могло быть немного более самодостаточным ,

Answer 1

Одно выражение «Равное» достаточно. Ваш факт RHS должен быть другим элементом словаря. В случае типа XML правильный путь будет вытаскивать все значения один за другим и вызывать множественные оценки и, соответственно, активировать действие, если есть совпадение. Ключ для запоминания: BRE - это шаблонный механизм.

Словарь - просто удобный псевдоним для определения факта. Допустим, вы создаете файл XML со следующей структурой:

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

Определить словарь этого факта, как Имя: PossibleValues ​​ XPath Selector:/опции/значение XPath Область:.

Затем определение правила как IF currentValue == Возможные значения вызовет три условия оценки, так как RHS выдает три факта в рабочую память. Следовательно, только те, которые были правдой, увидят правило (действие). Сравните это определение по умолчанию создает BRE, когда вы выбираете узел из схемы XML, который будет только утверждать один (первый) факт:

XPath Выбор:/опции/ XPath поля: значение

(Пространства имен опущена для кратность)

Во время выполнения передайте этот XML-документ в качестве аргумента для BRE (будь то в оркестровке или в компоненте .Net в зависимости от контекста вызова BRE). Во время разработки для тестирования вам необходимо реализовать компонент Fact Creator (реализует IFactCreator), чтобы предоставить экземпляр необходимых аргументов.

Долгосрочные факты (как в вопросе) лучше управляются с использованием пользовательских ретрансляторов фактов. Факт-ретривер - это .Net-компонент, который реализует IFactRetriever. Подробности см. На странице documentation. Внутри реализатора реализации ретривера загружают XML (с диска) и утверждают его в рабочую память как TypedXmlDocument.