BizTalk: XSLT против картографического инструмента - PullRequest
3 голосов
/ 21 июня 2011

Мы выполняем процесс сопоставления файла XML, созданного устаревшей системой, с файлами EDI 834/837.У нас есть BizTalk 2010 и мы используем встроенные схемы Microsoft EDI.

Файлы EDI довольно сложны, и файл XML, который мы получаем, также сложен, с множеством частей.Я начал изучать инструмент отображения, но мне показалось, что существует много повторений, которые я мог бы устранить, пропустив файл XML через XSLT.

Я нашел следующую ссылку, но меня не устраивает только один источник.http://blog.eliasen.dk/2009/07/08/CustomXSLTScriptingFunctoidOrBuiltinFunctoidsAQuestionAboutReligion.aspx

Итак, есть ли другие преимущества использования инструмента отображения по сравнению с созданием собственного XSLT?

Ответы [ 5 ]

4 голосов
/ 22 июня 2011

Мой опыт работы с картами BizTalk заключается в том, что вещи, которые очень просто сделать с помощью XSLT, могут быть очень сложными с картами.

Хорошие контрпримеры карт BizTalk можно найти в книге «Pro Mapping в BizTalk Server 2009». В книге есть несколько примеров очень сложных вещей, которых вы можете достичь с помощью карт BizTalk, но недостатком этого является то, что на самом деле они скрыли всю сложность в скриптообразных функтоидах. Следовательно, карты больше не являются визуальными (у них даже нет связей между узлами, чтобы обеспечить хотя бы подсказки для вывода, что делает карта).

XSLT может быть более наглядным, чем карта, поскольку вы можете увидеть полученный XML в XSLT (имейте в виду, что «текст» не подразумевает «не визуальный» - если вы выполняете преобразование между текстовыми форматами, то естественным образом визуализировать трансформацию можно, посмотрев на текст)

Карты BizTalk можно использовать для очень простых сопоставлений, когда вы по сути копируете набор свойств из одной структуры в другую структуру с такими же свойствами. Однако, как только вам нужно сопоставить структуру с другой структурой, вы быстро получаете что-то, что трудно написать И трудно прочитать / понять.

3 голосов
/ 22 июня 2011

Не совсем, я тоже предпочитаю XSLT. Проще документировать (используя комментарии в источнике) и, следовательно, поддерживать. Однако имейте в виду, что в BizTalk 2006 R2 вы не можете импортировать внешние XSLT , что снижает ваши возможности для повторного использования. Я понятия не имею, изменилось ли это в последующих версиях BizTalk, это вы должны выяснить и, возможно, сообщить нам всем ...

1 голос
/ 24 сентября 2014

Не совсем ответ, больше обмена опытом;

В моей команде у нас было обсуждение этого вопроса. Аргументом для карт было то, что его понимают большинство коллег (как это касается каждого базового тренинга по BizTalk), а XSLT нет.

Я лично работал с XSLT в течение долгого времени, прежде чем начал работать с BizTalk, и нашел инструмент картографирования очень ... неинтуитивным. Каждое соединение, которое я устанавливаю, вызывает больше вопросов, чем дает мне утешение, зная, каков результат. Что происходит, когда исходный узел имеет значение ноль, отсутствует или повторяется? Что происходит, когда целевой узел определяется как minOccurs = 2? Что именно делает функтоид табличного отображения? Что делает Functoid для извлечения табличных значений, когда значение не найдено? Как создать узел с последовательностью автонумерации и как связать другие созданные узлы, которые могут относиться к этим узлам, используя сгенерированный номер?

Работа с XSLT возвращает мне контроль, я точно знаю, что происходит.

XSLT-карты имеют дополнительную ценность, заключающуюся в том, что они основаны на тексте, что хорошо работает с разветвлением и меррингом в управлении исходным кодом, и позволяет нам добавлять комментарии в исходные тексты. Вы когда-нибудь пытались объединить изменения из карты из двух разных ветвей?

Конечным результатом является то, что теперь мы предпочитаем XSLT для отображения, но не каждый разработчик свободно владеет XSLT. Это требует некоторой подготовки.

Последний совет: инвестируйте средства в инструменты модульного тестирования для ваших карт. Найдите набор инструментов с открытым исходным кодом или напишите несколько строк, чтобы самостоятельно проверить свои карты. Большинство артефактов BizTalk отлично тестируются, даже если это не так, с возможным исключением для оркестровок (которые в любом случае следует использовать в качестве крайней меры).

0 голосов
/ 19 августа 2015

Как человек, имеющий опыт работы как в BizTalk, так и в другом инструменте отображения на основе графического интерфейса (BridgeGate), я могу сказать, что для непрограммистов эти приложения содержат решения в виде интерфейса отображения для решения большинства проблем.Когда они терпят неудачу, они предлагают заднюю дверь, чтобы выйти к более основанному на коде решению в форме скриптообразного функтоида.Так что, хотя XSLT, безусловно, является альтернативой, я считаю, что те, кто предпочитает его, чаще всего те, кто пишет код с большим комфортом, чем те, кто этого не делает.

Мой опыт работы с файлами 837P и 837I был связан с предыдущим инструментом картирования (BridgeGate), и он был трудным, но в основном это была ошибка сложности файла.Что я могу сказать, и что не упомянуто, так это то, что изменения в процессе для удовлетворения запросов клиентов на изменение были намного проще в картах на основе GUI;Я могу только представить, как это было бы, если бы пришлось погрузиться в достаточно большой XSLT, чтобы обрабатывать преобразования 837 и вносить изменения, чтобы затронуть каждый узел, связанный с запросом на изменение.Вы знаете, насколько большой 837, и насколько сложной может быть петля.Имейте это в виду при выборе.

Я не завидую вашей задаче, но знаю, что удовлетворение, когда вы ее выполните, сделает все это стоящим.Удачи!

0 голосов
/ 05 июня 2013

IMO:

Преимущества XSLT

  • Вы улучшаете DRY, повторно используя функциональность сопоставления, используя XSLT apply + шаблоны вызовов и пользовательские функции сценария (например, C #сценарий) в той же карте.К сожалению, AFAIK <xsl:include> не работает, поэтому вам потребуется скопировать и вставить для повторного использования в нескольких файлах xslt карты.
  • Собственные шаблоны вызовов XSLT, как правило, более производительны, чем сценарии C # (что наиболее Функтоиды реализованы так или иначе )
  • Вы можете использовать отладчик XSLT в Visual Studio.
  • И подчеркнуть точку ckarras, что для сложныхкарты, XSLT на самом деле проще для понимания, чем визуальная паутина.

Преимущества Visual Map

  • Производительность длятривиальные карты, например, где все элементы имеют одинаковое имя и тип и могут быть отображены на корневом уровне, или если вам нужна фиктивная карта с жестко закодированными значениями выходных элементов.
  • И я предполагаю, что уровень препятствий дляXSLT может быть довольно высоким.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...