Альтернатива запуску DB Lookup functoid через цикл?

Question

Я действительно не уверен, как это сделать, так что вот мой лучший снимок. У меня есть таблица, в которой хранятся значения с помощью «TypeId» и фактического значения. «TypeId» отображает строку в справочной таблице, в которой содержится фактическое текстовое описание. При вставке данных в мою базу данных через BizTalk Server 2009 мне нужно выполнить поиск по каждому значению, предоставленному из входящего файла, чтобы получить его правильный TypeId, а затем заполнить исходную таблицу.

Единственный способ, которым я вижу это, - это функционировать с помощью функции Look Look functoid, но поскольку эту функцию можно назвать буквально сотни раз для каждого входного файла, я не ожидаю удара по производительности, который я бы взял из этого , Кто-нибудь знает о другом способе выполнения этого поиска во время выполнения или, возможно, в том, как выполнить поиск из SQL только один раз, а затем BizTalk ссылается на некоторое представление таблицы в памяти?

EDIT: У меня была идея, но мне хотелось бы, чтобы кто-то из сообщества SO сказал мне, что это плохой, и если да, то почему. Вот он:

Я мог взять входящий документ и преобразовать прямо в XML, а затем передать полученный XMLDocument на внешнюю сборку .NET. Затем эта сборка может вставить таблицу поиска в виде словаря (или другого типа IEnumerable) и изменить исходный документ, добавив правильные значения TypeId вместо исходного дескриптора типа в исходном документе. Это теоретически позволило бы мне избежать накладных расходов большого количества поисков БД, заменив (теоретически) намного более низкие издержки на вызов внешней сборки.

Может ли кто-нибудь подумать о причине не использовать этот подход?

Answer 1

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

Произнесите таблицы: Values ​​(TypeID, Value) TypeLookup (TypeID, TypeName)

Тогда вы можете сделать:

SELECT Values.Value, TypeLookup.TypeId, TypeLookup.TypeName 
FROM Values 
LEFT JOIN TypeLookup ON TypeLookup.TypeId = Values.TypeId 

Это дает Вам результат для каждой записи значений. Если значение Values.TypeId не равно null, вы также получите TypeId и TypeName для этого значения.

НТН

Answer 2

Вы можете написать собственный статический класс, который имеет метод в нем, который принимает идентификатор в качестве параметра. Затем этот метод можно было бы вызвать из функционала скриптов.

Класс может выглядеть следующим образом (Внимание: Это просто затушил пример):

public class Values 
{ 
public static Dictionary<Int, String> LookupDictionary; 

public static string GetDictionaryValue(Int idIn) 
{ 
    if (LookupDictionary is null) -> go out to the database and populate; 

    return LookupDictionary[idIn].Value; 
} 

} 

Вот некоторые соображения.

1. Если вы хотите вызвать свой метод из функционала скриптинга, класс должен быть нестатическим.
2. Это решение может работать не очень хорошо на нескольких серверах biztalk, поскольку статические переменные будут храниться на сервере по серверу.

Другой альтернативой является улучшенный функционал базы данных от Blogical. Я не пробовал этот функционал лично, но это может быть именно то, что вы ищете.

BizTalk Database lookup functoid with caching feature

Answer 3

подхода вы предлагаете, где вы преобразование, а затем использовать сборки .NET, чтобы заменить идентификаторы с описаниями, должны работать на относительно небольших сообщений, но вы будете иметь проблемы с большими сообщениями.

Другой вариант - создать сообщение с несколькими частями, которое содержит ваш оригинальный тип, а также новый тип. Новый тип - это тот, который вы создаете, который вы загружаете с помощью пар имя-значение перед преобразованием. Итак, теперь у вас есть два сообщения - Y (ваше сообщение) и X (сообщение, содержащее пары имя-значение).

Возьмите копию существующей карты в случае ее разрыва, а затем измените форму преобразования так, чтобы она принимала оба типа (тип Y и тип X) - порядок не важен.

На вашей карте - в тех местах, где вам нужно выполнить поиск, добавьте скриптовый функционал и установите его в Inline XSLT.

В встроенном XSLT добавьте свое имя узла, а затем xsl: значение-select ... элемент. Поместите выражение xpath в оператор select, который ищет идентификатор и выбирает значение. Простым выражением может быть что-то вроде /Root/Lookups [@ id = "12345"]/ - но, конечно, ваше выражение будет другим. Вы можете получить представление о том, как адресовать часть сообщения, щелкнув узел, который содержит пары имя-значение, и выберите свойства Instance XPath в свойствах.

Это займет некоторую практику, если вы не знакомы с XPath или пространствами имен и т. Д., Но когда это будет работать, оно будет быстрым и будет работать без проблем, и у вас будет меньше кода для поддержки.

Answer 4

То, что я делал в прошлом, было работать с двумя функциями.

Первый functiod будет иметь код, похожий на то, что предложил Майк. Но вместо того, чтобы загрузить его на статическое свойство, я просто возвращает файл XML (который имел ключевые ценности пары, как:

<Types> 
    <Type id="a" description="b" /> 
    <Type id="c" description="c" /> 
</Types> 

Второй functiod будет иметь этот XML-строку в качестве входного и значение, которое вам необходимо отобразить в другой вход Затем в коде вы можете узнать Идентификаторы требуемую либо:.

• Использование XPath
• Использование регулярных выражений (я использовал регулярные как выражения, так что у меня не было, чтобы загрузить xml в любой тип DOM).

Мои карты тогда будут иметь результат первого функционала, подающего столько копий второй функции при необходимости (в моем случае у меня было 10 или около того поисков для выполнения).

Вам нужно было бы прочитать базу данных один раз для каждого упражнения отображения, но это было бы так.

Надеюсь, это поможет.