Гибкость прикладного решения

Создание расширяемых конфигураций в Microsoft BizTalk Server 2004

Гибкость разрабатываемого прикладного решения всегда является его большим преимуществом, особенно в условиях динамично развивающейся информационной системы предприятия. Недостаточная расширяемость системы может вызвать проблемы при внесении даже небольших изменений. Добавление новых возможностей и вовсе может поставить вопрос о переработке системы «с нуля», что потребует значительных инвестиций. Таким образом, риски, связанные с ростом потребностей пользователей, при проектировании системы обязательно должны учитываться. В этой статье речь пойдет о некоторых подходах, которые могут использоваться при разработке гибкого решения на платформе Microsoft BizTalk Server 2004. Сразу отмечу, что она ориентирована на системных архитекторов и разработчиков систем на платформе Microsoft и подразумевает некоторый опыт работы с BizTalk Server 2004.

Сценариев, где может понадобиться гибкость прикладного решения, множество. Например, системы с часто меняющимися структурами документов; системы, импортирующие данные из ненадежных источников (ручной ввод), да и просто системы, в которых требуется свести к минимуму вмешательство в исполняемый код или настройки. Кратко рассмотрим пример, когда все перечисленное присутствовало в проекте, выполненном специалистами компании IBS для одной из крупных российских финансовых структур.

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

На начальном этапе разработки системы был проведен анализ интегрируемых систем и источников справочных данных. В ходе анализа выяснилось, что, помимо систем SAP R/3, имеющих развитую поддержку импорта/экспорта данных, в том числе с помощью собственных интеграционных средств, имеются и другие системы, у которых такие возможности отсутствуют. Часть источников данных представляли собой периодически обновляемые файлы программы Microsoft Excel. На основании полученных сведений была поставлена задача построить отказоустойчивую систему импорта/экспорта данных, которая могла бы одинаково успешно работать как со стандартизированными форматами (IDOC), так и с документами, создаваемыми вручную. Кроме того, было необходимо обеспечить подстройку интеграционной среды при внесении изменений в структуру документов системы без участия специалиста по Biztalk Server.

Для решения этой задачи было разработано комплексное решение, использующее следующие базовые методики:

• поздняя верификация входящих документов внутри оркестровки;
• использование карт преобразований вне BizTalk Server;
• работа с плоскими форматами (CSV, DBF) без использования адаптеров и без описания схемы документов.

Рассмотрим каждый из подходов подробнее.

Поздняя верификация входящих документов внутри оркестровки

Инициализация обработки входящего документа в оркестровке начинается с опознания и сопоставления документа с имеющимися XSD-схемами. При несоответствии документа ни одной из схем или нарушении его структуры оркестровка не запустится, а все ошибки попадут в журнал приложений Application Log, причем с таким скудным описанием, что быстро установить точную причину неполадки будет невозможно. Это не вызовет особых проблем, если связь между BizTalk и интегрируемой системой четко регламентирована и отлажена, но что делать, когда ежедневно поступают документы, создаваемые пользователями вручную? В этом случае очень важно не просто зафиксировать факт ошибки, но и установить, в каком файле и в каком конкретно месте этого файла допущена ошибка. Причем возникновение такой ошибки не должно повлиять на обработку другой информации из файла.

Экран 1. Настройка типа сообщения

Для того чтобы обеспечить возможность такой обработки, необходимо отключить первичную верификацию входящих документов, указав в качестве типа сообщения (Message Type) не одну из имеющихся XSD-схем, а стандартный класс System.Xml.XmlDocument (см. экран 1).

Таким образом, одна проблема решена — в оркестровку будут попадать любые XML-файлы, но как же быть с файлами, структура которых нарушена? Для того чтобы заставить BizTalk не обращать на это внимания, необходимо в настройках документа Receive Location выбрать Receive Pipeline = PassThruReceive (см. экран 2).

Экран 2. Настройка Receive Pipeline

После этого в оркестровку могут попадать любые документы, даже невзирая на то, что мы указали тип сообщения System.Xml.XmlDocument. Возникает резонный вопрос, как загрузить документ, который не обязательно является XML, проверить его и затем обработать?

В оркестровку документ попадает в виде сообщения, имеющего тип Microsoft.XLANGs.BaseTypes.XLANGMessage. Один из способов получить из него XML-документ — это открыть сообщение как поток данных System.IO.Stream и затем подгружать из него данные, одновременно проверяя их на соответствие формату XML и используемым XSD-схемам c помощью класса System.Xml.XmlValidatingReader, как показано в листинге 1.

Эту функцию можно вызвать в оркестровке из блока Expression, передав в качестве параметра сообщение, полученное в блоке Receive. При возникновении несоответствия поступающих данных формату XML или используемой XSD-схеме сообщения об ошибках можно перехватывать, анализировать и затем отправлять обратно в систему-источник в удобном виде, например: «Не заполнено обязательное поле NAME в такой-то строке в таком-то файле».

Использование карт преобразований вне BizTalk Server

Специалисты, имевшие опыт преобразования XML-файлов с помощью технологии XSLT и знающие, что для создания карт преобразования визуальная среда Biztalk является довольно удобным средством, справедливо заметят: «Как воспользоваться этими картами в своем приложении, не устанавливая и не настраивая Biztalk Server?» Сначала XSL-файлы необходимо получить из Biztalk Server, так как Biztalk хранит описание карты в своем внутреннем формате (.btm). Для этого надо открыть Visual Studio 2003, где в Solution Explorer нажать правой кнопкой мыши на нужный файл (.btm) и выбрать в контекстном меню Validate Map. После успешной верификации карты в окне Output появятся ссылки на сгенерированный XSL-файл и соответствующий ему файл Extension Object XML.

Задействовать сгенерированный XSL-файл можно с помощью классов System.Xml.Xsl.XslTransform и System.Xml.Xsl.XsltArgumentList. Воспользуемся следующим классом, описанным в листинге 2.

Применение класса BizTalkMap проиллюстрировано на примере листинга 3. Пути к файлам должны быть определены в переменных:

• xsltPath - путь к карте преобразования XSL;
• extensionPath - путь к файлу с Extension Object XML (необязательный параметр);
• instancePath - путь к исходному файлу;
• destPath - путь к файлу с результатами преобразования.

Работа с плоскими форматами (CSV) без использования адаптеров и описания схем документов

При выстраивании взаимодействия с унаследованными системами предприятия возникает необходимость настройки преобразования из форматов с уже реализованной поддержкой. Как правило, это CSV, DBF и т. д. Если действовать стандартно, то нужно сначала установить соответствующий адаптер, затем полностью описать схему документа (какое поле за каким следует, каким разделителем разбиты поля и строки и т. д.) Однако такая последовательность действий не нужна, если требуется просто преобразовать CSV в XML и передать его в оркестровку для дальнейшей обработки (верификации, преобразований и т. д.) Рассмотрим эти два формата (см. экран 3). В первой строке CSV-файла содержатся наименования столбцов, запомнив которые мы можем формировать названия атрибутов в XML-файле. А по имени исходного файла можно формировать название содержащего эти атрибуты элемента.

Экран 3. Преобразование CSV в XML

По такому же принципу можно читать XML-данные из других форматов. Например, из DBF-файла названия атрибутов можно получить, считав метаданные из объекта System.Data.OleDB.OleDbDataReader, открыв DBF-файл с помощью System.Data.OleDb.OleDbConnection. Пример чтения одной записи из DBF-файла в виде XML показан в листинге 4. Параметры dirName и tableName в данном примере сформированы вместе:

Путь к файлу DBF =
 dirName+tableName+».dbf»

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

Ярослав Помазков - Эксперт ПО-департамента интеграционных решений компании IBS.