Альтернатива выполнению функтоида DB Lookup через цикл?

Question

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

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

РЕДАКТИРОВАТЬ: У меня была идея, но я хотел бы, чтобы кто-то из SO сообщества сказал мне, если это плохо, и, если так, почему. Вот оно:

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

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

Answer 1

В прошлом я занимался двумя функциями.

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

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

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

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

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

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

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

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 с функцией кэширования

Answer 3

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

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

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

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

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

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

Answer 4

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

Скажите, что ваши столы: Значения (TypeId, Value) TypeLookup (TypeId, TypeName)

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

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

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

НТН