BizTalk Server и Xml

 На днях мне на глаза попалась инструкция по формированию файла данных. Эти данные нужны для передачи информации от 1С партнера в фирму 1С, небезызвестную российскому IT народу. Инструкция занимала четыре листа, на которых подробно описывались форматы различных полей данных.

[

Кодировка текстового файла — WINDOWS;

Строка отчета соответствует одной строке текста;

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

Строковые значения заключаются в кавычки. Например: «ООО».

Кавычки внутри текста удваиваются. Например: «ООО «»ПоларисКуб»»»;

Числовые значения представляются «как есть»;

Дата представляется в фиксированном строковом формате «ДД.ММ.ГГГГ»

Например: «30.04.2007» — правильно, «30.04.07», 30.04.2007, «04.30.2007» — неправильно.

]

У меня сразу зачесались руки, как это всегда случается при виде какого-то старого кода, который можно сильно усовершенствовать, не затрачивая при этом много времени и труда.

Ну конечно, все эти словесные описания должны быть заменены Xml схемой! Какая разница? Было описание данных, получится тоже описание данных.

Но разница есть. Xml схема используется готовыми Xml парсерами, входящими в операционную систему Windows [MSXML http://msdn.microsoft.com/en-us/xml/bb291077.aspx]. Парсер проверит данные на соответствие предложенной схеме. Теперь нам не надо писать свою программу, чтобы проверить данные на соответствие формату. Порядок данных, форматы сложных и простых типов данных, соответствие набору кодов и т.п.

Старая модель верификации данных:

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

[…

Например: «30.04.2007» — правильно, «30.04.07», 30.04.2007, «04.30.2007» — неправильно.

]

К примеру, чтобы обработать вышеприведенное описание даты, понадобится написать хороший кусок кода, в котором надо будет проверять «правильные» даты, с учетом високосных годов и т.п.

Xml модель верификации данных

Поставщик данных решает использовать формат данных Xml [http://www.w3.org/TR/xml11/ ]. Он описывает данные в формате Xml схемы (Xsd формат [http://www.w3.org/TR/xmlschema-1/, http://www.w3.org/TR/xmlschema-2/ ]). Потребитель данных использует эту схему для ввода данных в свою систему. Он использует один из существующих парсеров для верификации данных.

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

Использовать ли стандарт Xml для передачи данных?

Есть случаи, когда его использование все равно, что стрельба из пушки по воробьям. Есть случаи, когда его НЕиспользование все равно, что использование пуль для стрельбы из рогатки.

Пример: передача данных за пределы своей организации.

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

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

Пример: передача данных между разными программами.

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

Уверены? А что будет, если пользователь через пару лет соберется заменять одну из программ на программу другого производителя? Вам придется переписывать программку верификации заново. Не факт, что в это время вы будете работать рядом. Не факт, что к тому времени не будет утеряно описание формата. Простая задача выльется в долгие и утомительные согласования, чреватые ошибками.

Пример: передача данных в рамках одной сетевой программы.

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

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

Если при этом удается избежать сериализации данных, то использование Xml может привесит к неоправданному усложнению. К примеру, программы, написанные на .NET Framework могут использовать множество технологий для обмена данными: MSMQ, named pipes, COM+ и т.д. Не факт, что использование Xml приведет к нужным результатам.

BizTak Server и использование Xml

Вы спросите, какое отношение все эти рассуждения имеют к BizTalk?

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

BizTalk работает с данными в форме сообщений. При этому внутри BizTalk все сообщения представлены в формате Xml. Точка.

На входе и выходе BizTalk данные могут быть во множестве форматов: текстовых, SQL, Xml, форматов определенных программ, таких как SAP/R3, C:Предприятие… Но все эти форматы на входе/выходе BizTalk преобразуются в формат Xml.

Это приводит к замечательным последствиям.

Представим себе систему, состоящую из N программ, которые надо связать друг с другом. Если мы будем связывать каждую из этих программ напрямую с другой, нам понадобиться написать для каждой программы (N-1)*2 преобразований форматов. (Коэффициент 2, так как одна связь действует только в одну сторону. Чтобы обеспечить связь в другую сторону, понадобится другое преобразование.) В пределе понадобится написать N*(N-1)*2 преобразований форматов.

Имея промежуточный слой в виде BizTalk, нам придется обеспечить только N * 2 преобразований.

При этом неправильные данные не попадут в систему. Они будут отсеяны парсером Xml на этапе ввода в систему.

Заключение

Как там… «партия и Ленин — близнецы-братья»? А у нас «BizTalk Server и Xml — близнецы-братья.🙂

1 комментарий

Filed under BizTalk

One response to “BizTalk Server и Xml

  1. I bookmarked this link . Thank you for good job !

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s