Использование XML в бизнес-приложениях

© Владимир Некрасов
Oпубликовано на сайте www.pcweek.ru

Применение XML (eXtensible Markup Language) становится все более широким

Замечательная технология XML позволяет решать многие застарелые проблемы автоматизации на современном уровне и открывает пути к совершенно новым возможностям.

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

В настоящее время применение XML (eXtensible Markup Language) становится все более широким. Основные задачи, решаемые при помощи этой технологии в бизнес-приложениях, таковы:

обмен данными между системами разных производителей;
сбор данных из удаленных подразделений;
обмен коммерческими документами между предприятиями (B2B);
сбор отчетности государственными организациями;
поставка данных и метаданных тонким Интернет-клиентам;
хранение и дистрибуция метаданных хранилищ и других систем.

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

Проблемы использования XML. Преимущества XML при обмене данными между приложениями

XML обладает рядом преимуществ перед другими языками/форматами описания данных при обмене данными между приложениями:

1. Независимость от платформ. Язык XML позволяет обмениваться данными системам, базирующимся на разных платформах. XML-документ может быть создан и разобран как текстовый файл с помощью устаревших или встроенных языков программирования, в состав которых не входят специальные библиотеки для работы с XML.

2. Поддержка производителями. Библиотеки для работы с XML созданы для всех ведущих языков программирования и популярных СУБД. Использование этих библиотек позволяет существенно уменьшить объем кодирования при разработке "шлюзов" между приложениями.

3. Самодокументированность. XML-документ "читабелен" для человека. Кроме того, наличие внутри него описания данных позволяет создавать автоматические программы их обработки, например универсальные модули загрузки данных, поступающих из разных систем в единое хранилище.

4. Иерархичность. Это ключевое свойство языка. В отличие от формата CSV (текстового файла с разделителем ""), XML позволяет легко описывать сложные структуры данных с неограниченной вложенностью объектов.

5. Объектность. Структура данных XML отлично сочетается с объектно-ориентированной моделью программирования. Каждый тег XML-документа может быть поставлен в соответствие классу или свойству класса обрабатывающей программы. С другой стороны, есть возможность описать в XML-формате каждый прикладной объект предметной области как отдельный тег.

6. Расширяемость. В процессе эксплуатации XML-формата в него можно добавлять новые теги. Это не приведет к фатальному изменению структуры данных, просто читающие и пишущие программы нужно будет дополнить классами или функциями, распознающими эти теги.

Анализ перечисленных выше преимуществ показывает эффективность и долгосрочную перспективность применения XML в качестве формата обмена данными между приложениями вместо устаревших "тяжелых" решений или примитивных текстовых файлов с разделителями. Однако гибкость языка XML позволяет совершенно по-разному подойти к описанию одних и тех же данных, к организации их обмена.

Подробнее с языком XML можно познакомиться, например, обратившись к электронному журналу Клуба знатоков технологий DWH, OLAP, XML на сайте.

Различные подходы к созданию форматов обмена данными

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

Описание физических таблиц. Такой подход очень легко реализовать, например, используя продукты Borland. При сохранении таблицы (ClientDataSet) в XML создается документ, содержащий "пакет данных", в который вложены метаданные таблицы - тег и записи таблицы - тег. Внутри тега находятся поля с описанием их физических наименований и типов данных, а внутри тега - записи таблицы - теги. Запись есть минимальный элемент данных:

Такой же простой подход предлагается и в СУБД MS SQL Server 2000. Обычное выражение Select, дополненное ключевыми словами For XML, возвращает XML-документ, состоящий из записей вида:

где имя тега равно имени таблицы, а его свойства - именам полей таблицы.

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

Более сложный запрос к базе данных MS SQL 2000, когда таблицам и ее полям присвоены псевдонимы, а в запросе содержатся вложенные запросы, возвращает XML-документ, имеющий объектную иерархическую структуру:

…

Результатом применения XML, встроенного в SQL, может быть "правильный" XML-документ, состоящий из описаний объектов предметной области, но только в том случае, если структура базы достаточно проста, чтобы можно было описать соответствие таблиц и их полей предметным объектам XML-документа таким лаконичным средством, как язык SQL. А это не всегда возможно для старых систем и не всегда оправданно с точки зрения внутренней логики БД. Кроме того, прямое чтение (запись) XML в базе данных также означает отсутствие в системе промежуточного слоя, выполняющего правила бизнес-логики.

Описание отчетных форм. Этот подход часто применяется на практике, когда головной офис собирает с филиалов отчеты, например о прибылях и убытках. Существует стандарт XBRL, в котором регламентируется создание "топономий" - словарей отчетных форм для отраслей.

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

Описание бизнес-объектов. В этом случае выполняется классификация объектов предметной области и для каждого объекта создается XML-документ, который содержит теги, описывающие свойства этих и, возможно, дочерних объектов. Структура базы данных информационной системы, участвующей в обмене такими документами, может соответствовать структуре документа или совершенно не походить на нее. Для каждой системы создаются уникальные процедуры импорта и экспорта, обрабатывающие ее стандартные документы. Такой формат действительно универсален и может быть правильно интерпретирован разными информационными системами, независимо от их реализации.

Обмен данными внутри одной организации

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

Однако в рамках одного предприятия более разумным и экономичным представляется "диктаторский" подход с принудительным введением единого формата. Это позволит отказаться от дополнительного ПО для преобразования форматов и соответствующих регламентных и административных работ.

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

Обмен данными между организациями

Для систем класса B2B, позволяющих независимым и равноправным партнерам обмениваться деловыми документами, взаимное преобразование нескольких корпоративных XML-форматов неизбежно. Несмотря на большие усилия, предпринимаемые инициативными группами по созданию отраслевых или даже всеобщих деловых форматов обмена данными, судя по всему, всегда будет существовать множество независимых XML-схем внутри отраслей. Для решения этой проблемы существуют специальные XML-серверы, например BiZTalk корпорации Microsoft, XMLSphere IBM и др.

Сбор отчетности государственными органами

В том случае, когда данными обмениваются вышестоящие организации с нижестоящими, например, Центральный банк с коммерческими банками, МНС с предприятиями, - возникает другая ситуация. Административные возможности государственных организаций могут сыграть положительную роль в создании стандартных XML-схем.

Так, принудительное введение XML-формата для передачи в Центральный банк банковских платежей приведет к тому, что все разработчики АБС и бухгалтерских систем предприятий встроят в свои системы модули обмена платежными документами в едином формате. Это не только ускорит прохождение платежей, но и даст импульс развитию систем B2B.

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

Предоставление данных Интернет-клиентам

Формальное решение проблемы находится на поверхности. Поскольку изначально предполагалось, что технология XML всего лишь должна была отделить данные от их представления, то XML-документ, поставляемый бизнес-приложениями Интернет-клиентам, легче всего представить себе как перечень колонок и строк таблицы, содержащей данные и XSL-файл с описанием отображения этой таблицы на экране.

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

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

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

Опыт применения XML в системе “Контур Корпорация”

Итак, можно привести множество примеров подходов к применению XML в бизнес-системах, но не все они служат залогом желаемых результатов. За кажущейся простотой языка, как всегда, скрывается бездна тонких нюансов и подводных камней. Наш опыт встраивания XML в информационную систему и создания приемлемых форматов для описания предметной области показал, насколько это непростая задача.

Система “Контур Корпорация” компании Intersoft Lab. предназначена для сбора деловых данных в корпоративном хранилище многофилиальной организации, их консолидации и дальнейшего использования для анализа, формирования внутренних и внешних отчетов, бюджетирования и выполнения других управленческих функций.

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

Первоначально для обмена данными и дистрибуции метаданных применялся текстовый формат. Структурно он объединял INI-файлы и файлы с разделителем. Разработка процедур импорта-экспорта была одной из наиболее трудоемких задач, которая осложнялась еще и тем, что система рассчитана на сбор первичных данных многофилиальных организаций, т. е. огромных объемов информации, требующей проверки и очистки во время загрузки в хранилище.

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

Результат оказался впечатляющим: кроме значительного уменьшения трудоемкости разработки процедур обмена данными были получены многие дополнительные возможности. Рассмотрим основные подходы к применению XML в системе “Контур Корпорация”.

Дистрибуцию метаданных в формате XML, автоматизацию создания конкретных XML-форматов при изменении структуры хранилища данных и исключение программирования процедур загрузки данных обеспечивает объектная организация системы “Контур Корпорация”:

Каждому объекту предметной области соответствует совокупность таблиц в базе данных, класс в библиотеке прикладных классов и базовый объект в XML-формате.

Каждый прикладной объект представлен в виде двух классов в библиотеке и двух объектов в XML — списка и экземпляра, например “Счета” и “Счет”.

Каждому атрибуту объекта предметной области соответствует поле в таблице базы данных, свойство в классе прикладной библиотеки и тег в XML-формате.

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

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

Объект может иметь тип, что меняет состав его дополнительных атрибутов и соответственно тегов. Например, объект “Документ” может иметь тип “Платежное поручение” или “Договор поставки”, каждый из этих документов имеет собственный состав атрибутов.

Каждый класс библиотеки прикладных классов имеет стандартные и, возможно, специфические методы. Например, обязательный метод put помещает данные объекта в базу данных, а метод get выгружает объект в оперативную память или в XML-файл.

Ведение хранилища и дистрибуция метаданных

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

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

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

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

Для создания адекватного по гибкости механизма создания форматов была разработана специальная технология — Dynamic XML. Ее суть состоит в том, что XML-форматы не описываются вручную, а генерируются в момент изменения настроек хранилища по заранее определенным правилам. После этого система готова к сбору данных в новом формате. Сразу же после поступления новых XML-документов они будут автоматически загружаться в систему.

Важнейшее преимущество, которое дает объединение объектной прикладной библиотеки и объектного XML-формата, состоит в том, что при этом не требуется разрабатывать или модифицировать процедуры загрузки.

После описания в системе новых бизнес-объектов эти процедуры адаптируются к ним автоматически. Принцип их (процедур) работы следующий: по имени тега XML-документа определяется класс библиотеки, которому он соответствует, создается объект этого класса, свойства объекта заполняются из вложенных тегов и вызывается метод “загрузить”, имеющийся у каждого класса.

Так же автоматически адаптируются процедуры выгрузки данных из хранилища. В этом случае на вход подаются списки объектов и параметры выгрузки, параметры превращаются в свойства объектов и для каждого объекта вызывается метод “выгрузить”.

Контроль и очистка данных реализуются как выполнение внешних, подключаемых функций, выполняющихся по событию. Например, событие “Ошибка загрузки” класса “Показатель” вызывает пользовательскую функцию, которая получает доступ ко всем свойствам показателя. Эта функция может остановить загрузку, исправить ошибку, например перекодировать валюту, а также послать почтовое сообщение администратору или выполнить другие действия.

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

Так, например, популярная система “1С:Предприятие” имеет закрытую базу данных, легальный доступ к которой можно получить, только если воспользоваться встроенным языком программирования или вызовом функций COM-объекта, а никак не универсальными утилитами извлечения данных.

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

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

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

Web-интерфейс системы позволяет передавать команды на выполнение операций над объектами и получать результаты этих операций в виде XML-документов. Этот механизм обеспечивает возможность разработки динамических Интернет-интерфейсов.

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

Для нее создается внешний модуль, интерпретирующий этот формат в специфический API системы. Это позволяет показывать в Win-клиенте и в Интернет-браузере один и тот же отчет, разработанный для отображения, например, через Excel.

За дополнительной информацией обращайтесь в Interface Ltd.

Interface Ltd. Тel/Fax: +7(095) 105-0049 (многоканальный) Отправить E-Mail http://www.interface.ru
	Ваши замечания и предложения отправляйте автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 21.02.02