Интеграция приложений для электронной коммерции с использованием Microsoft BizTalk Server 2000 : Новейшие технологии

н о в е й ш и е

т е х н о л о г и и А. В. Ложечкин

интеграция для Microsoft*

трбйУэй коммерции •s* \ f c ^(Пользованием

Server 2000 РУССКИ РЕЦПЦП

Ложечкин А. В.

Интеграция приложений для электронной коммерции с использованием

icrosoft BizTalk Server 2000 Новейшие технологии

Москва 2002

УДК 004 ББК 32.973.26-018.2 Л40

Ложечкин А. В.

Л40

Интеграция приложений для электронной коммерции с использованием Microsoft BizTalk Server 2000. Новейшие технологии — М.: Издательско-торговый дом «Русская Редакция», 2002. — 368 с.: ил

ISBN 5-7S02-0204-6 Книга посвящена средствам инте!*рации приложений, применяемым как внутри корпораций, так и при решении задач электронной коммерции. Рассказано о создании интеграционного решения на базе нового продукта, предназначенного специально для интеграции приложений, — Microsoft BizTalk Server 2000. Описаны все этапы процесса создания интеграционного решения с подробным анализом постановочных задач. Дополнительно рассмотрены возможности интеграции таких серверных приложений, как Microsoft SQL Server 2000 и Microsoft Host Integration Server 2000. Эта книга предназначена разработчикам корпоративных информационных систем, сотрудникам IT-служб организаций, а также всем тем, кому интересны современные технологии разработки информационных систем. К н и г а состоит из 15 глав, словаря терминов и предметного указателя. К книге прилагается компакт-диск с Microsoft BizTalk Server 2000 и примерами приложений.

УДК 004 ББК 32.973.26-018.2 Macintosh — охраняемый товарный знак компании Apple Computer Inc. ActiveX, BackOffice, JScript, Microsoft, Microsoft BizTalk Server, Microsoft Press, MSDN. NetShow, Outlook, PowerPoint, Visual Basic, Visual C++, Visual InterDcv, Visual J ++, Visual SourceSafe. Visual Studio, Win32, Windows и Windows NT являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствуюших фирм. Все названия компаний, организаций и продуктов, а также имена лиц, используемые в примерах, вымышлены и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам.

© ©

ISBN 5-7502-0204-6

А. В. Ложечкин, 2002 Оформление и подготовка к изданию,

издательско-торговый дом «Русская Редакция». 002 2

Оглавление Введение О чем эта книга Для кого эта книга Структура книги Содержание компакт-диска

Об авторе Благодарности

XI XI XIV XIV XVII

XIX XIX

ЧАСТЬ I Электронная коммерция и интеграция приложений Глава 1 Задачи электронной коммерции

1 3

Новейшая история Ситуации

3 6

Глава 2 Технологии электронной коммерции

9

XML Появление X M L Структура ХМ L-документа Доступ к ХМ L-документу Операции с документом Транспортные протоколы Синхронно или асинхронно Доступ к данным Файловое хранилище Реляционные базы данных Иерархические хранилища

ЧАСТЬ II Microsoft BizTalk Server 2000 Глава 3 Обзор Microsoft BizTalk Server 2000 Назначение BizTalk Server История BizTalk Server

9 10 10 11 12 14 16 16 16 17 17

19 21 21 24

BizTalk Framework Концепции BizTalk Framework Структура BizTalk Framework -документа Гарантированная доставка сообщений Обеспечение безопасности обмена сообщениями Транспортировка сообщений Библиотека схем BizTalk Лицензирование BizTalk Server 2000

27 27 28 30 31 31 31 32

Глава 4 Архитектура BizTalk Server 2000

33

Подсистемы BizTalk Server Архитектура BizTalk Server Логическая архитектура Системная архитектура Инфраструктура BizTalk Server 2000 Компоненты BizTaik Приложения BizTalk Server Общая архитектура Microsoft BizTalk Server 2000

33 36 36 38 38 39 42 44

Глава 5

Установка и администрирование BizTalk Server 2000

Установка BizTalk Server 2000 Версии BizTalk Server 2000 и варианты установки Требования для установки Требования к аппаратной конфигурации Требования к программной конфигурации Мастер установки BizTalk Server 2000 Создание баз данных Автоматическая установка Администрирование BizTalk Server 2000 Приложение BizTalk Server Administration Администрирование баз данных Работа с группой серверов Администрирование сервера Администрирование очереди Функции получения Обработка ошибок и сбоев Освобождение сервера Автоматизированное администрирование Технология WMI Использование WM1 в BizTalk Server .

45 45 45 46 46 47 47 49 50 51 51 52 55 56 57 58 58 58 59 59 . 60

Пример использования W M I Производительность и масштабируемость Масштабируемость BizTalk Server Оптимизация Bi/Talk Server

Глава 6

BizTalk Server Orchestration

61 62 62 63

65

Архитектура подсистемы BizTalk Server Orchestration Назначение BizTalk Server Orchestration Особенности архитектуры BizTalk Orchestration Создание бизнес-процесса Проектирование бизнес-процесса Реализация бизнес-процесса Конструктор сценариев BizTalk Orchestration Designer Блоки процесса Блоки начала и конца сценария Блок действия Блок условия Блок цикла Блоки разветвления и соединения Блоки транзакций Блоки реализации Блок MSMQ Блоки компонентов Блок BizTalk Messaging Блоки связи Порт Данные Исполнение сценариев XLANG и сервис выполнения сценариев Библиотека доступа к выполняющимся сценариям

65 65 67 68 68 70 72 73 73 75 75 77 77 79 83 84 87 91 93 93 96 97 97 99

Описание документов и преобразований в BizTalk Server 2000

101

Глава 7

Описание документа BizTalk Editor Создание спецификации документа Логическая структура документа Физическая структура документа Формат хранения Escape-символ Wrap-символ

102 104 106 106 107 107 108 108

Выравнивание Pad-символ Использование BizTalk Editor Вкладка Declaration Вкладка Reference Вкладка Parse Вкладка Namespace Вкладка Dictionary Вкладка Code List Работа с документами Работа со схемами Преобразование документов BizTalk Mapper Функтоиды Использование функтоидов

Глава 8

BizTalk Server Messaging

Назначение подсистемы BizTalk Server Messaging Схема соединения BizTalk Messaging Комбинации каналов и портов Стадии обработки документа Описание документа Критерий выбора схемы Поля для трекинга Канал Поля трекинга Критерий выбора канала Настройка квитанций Настройка параметров зашиты Регистрация документов Расширенные свойства Открытый канал Канал отправки квитанций Порт Пункт назначения Свойства транспорта Конверт документа Настройка параметров зашиты Открытый порт Список рассылки

109 109 110 110 112 114 114 114 115 1.16 116 117 118 124 128

135 336 137 140 141 142 144 144 144 146 146 146 147 147 148 148 148 148 149 149 150 150 150 .151

Организация Идентификаторы организаций Домашняя организация Приложение Конверт BizTalk Messaging Manager Настройка BizTalk Messaging Manager Объектная модель конфигурирования подсистемы BizTalk Messaging Архитектура библиотеки конфигурирования Объекты библиотеки Объекты конфигурирования Общие объекты BizTaikChanne! BizTalkDocument BizTalkEnvelope BizTalkOrganization BizTalkPortGroup BizTalkPort Вспомогательные объекты Целостность модели Внедрение решения Использование объектной модели Создание схемы взаимодействия Использование BizTalk Messaging Manager Создание описания документа в BizTalk Messaging Manager . . Создание организации и приложения Создание конверта Создание порта Создание списка рассылки Создание канала Использование объектной модели Пример схемы взаимодействия

151 152 152 153 153 155 155 156 157 158 158 160 164 167 167 168 169 170 171 176 177 180 180 181 181 183 185 185 189 190 197 197

Глава 9 Взаимодействие приложений с BizTalk Server 2000

203

Способы получения и отправки сообщений Получение сообщений Интерфейс I Interchange Submit SubmitSvnc .

204 205 205 206 . 206

CheckSuspendedQueue GetSuspendedQueue Item Details Delete FromSuspendedQueue Использование llnterchange Интерфейс IBizTalkTrackData Функции получения Файловая функция получения Функция получения MSMQ Получение по протоколам HTTP и SMTP Маршрутизация Получение сообщений BizTalk Orchestration Интерфейсы доступа к сценарию BizTalk Orchestration Отправка сообщений Транспорты BizTafk Messaging Файловый транспорт Транспорты HTTP и HTTPS Транспорт SMTP Транспорт MSMQ Loopback Компоненты интеграции Компонент BTSAppIntegration Pipeline — компонент Создание страниц настройки pipeline-компонентов Регистрация компонентов интеграции Отправка из BizTalk Orchestration Связь подсистем BizTalk Orchestration и BizTalk Messaging Корреляция сценариев Гарантированная доставка сообщений Использование каналов квитанций Использование BizTalk Framework

Глава 10

Трекинг документов

Архитектура трекинга документов Конфигурирование трекинга документов Конфигурирование трекинга группы серверов Конфигурирование трекинга в схеме соединения Использование информации трекинга BizTalk Document Tracking Обычные запросы Расширенный поиск

210 210 211 211 212 212 212 215 216 216 217 217 220 220 221 222 223 224 225 226 226 226 228 229 229 230 230 231 232 233

235 236 237 237 238 239 239 241 . 243

Программный доступ к базе данных трекинга Настройка BizTalk Tracking для работы с Orchestration XLANG Event Monitor

Глава 11

Безопасный обмен информацией

Безопасность коммуникаций Основные технологии несимметричного шифрования Симметричное шифрование Несимметричное шифрование Электронная цифровая подпись Сертификация ключей Технология несимметричного шифрования в Windows 2000 Certificate Sen-ices Защита передачи сообщений Пример HTTP и HTTPS SMTP MSMQ Файловый транспортный протокол Обеспечение контроля доступа Защита компонентов BizTalk Server Зашита программных интерфейсов Роли Группы BizTalk Server

244 244 246

249 250 250 250 251 253 254 256 256 259 260 262 263 263 263 263 264 264 266 267

Глава 12 Расширение возможностей BizTalk Server 2000 .. 269 Компоненты работы с сообщениями Компонент входного преобразования Компонент выходного преобразования Компонент проверки квитанций Пример использования компонентов работы с сообщением Компоненты электронной подписи и шифрования Пример использования компонента шифрования Функтоиды Пример использования функтоида Препроцессоры Пример использования препроцессора Компоненты работы со схемой Пример использования компонентов работы со схемой

270 272 275 278 279 279 280 281 283 283 286 286 289

ЧАСТЬ III Дополнительные платформы интеграции Глава 13

Возможности SQL Server 2000

Расширения Transact SQL FOR XML Режим RAW Режим AUTO Режим EXPLICIT OPENXML Аннотированные схемы XML View Mapper Использование ADO Доступ по HTTP Запросы к SQL Server no HTTP Использование шаблонов Непосредственный доступ к объектам базы данных Программный доступ Перспективы расширения возможностей

Глава 14

Возможности Host Integration Server 2000

291 293 294 294 295 296 298 299 300 303 305 305 308 308 310 311 312

313

Обзор Host Integration Server 2000 Логическая архитектура Host Integration Server Системная архитектура Host Integration Server Сетевая интеграция Интеграция данных Интеграция приложений Администрирование Host Integration Server 2000

314 314 316 316 317 318 319

Заключение

320

Развитие BizTalk Server Добавления в BizTalk Server -NET

Словарь терминов Предметный указатель

3:20 321 322

323 337

Посвящается моей семье

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

О чем эта книга В название книги вынесена фраза «Интеграция приложений». Неужели этот вопрос, который при разработке современных бизнес-приложений всегда отодвигается на задний план и решается в последнюю очередь, настолько важен? Попробуем ответить на него. Наилучшая среда для исполнения любого приложения или распределенной системы — изолированная, когда на компьютерах и в сети, где будет работать созданное приложение или внедренное решение, нет ничего — никаких других систем и приложений. Для разработчика это праздник: и реализовать удобно (не нужно тратить время на тестирование различных совместных конфигураций) и, самое главное, не приходится решать задачи интеграции.

Но как быть заказчику? Установка любой новой системы на компьютер только добавит головной боли — нужно искать новых администраторов, способных поддерживать ее в работоспособном состоянии, обучать пользователей работе с системой и переносу информации в нее из уже работающих приложений. Это можно пояснить на простом примере. Предположим, в организации существует система учета персонала (кадровая система) и система учета оборудования — столов, стульев, компьютеров. При приеме на работу нового сотрудника потребуются обе системы — в кадровой надо завести карточку нового сотрудника и в ее отдельных полях указать, что ему выданы стол и стул, а в системе учета оборудования отметить наличие новой мебели и указать, что она закреплена за новым сотрудником, Таким образом, одна и та же операция производится дважды. Нетрудно понять, что происходит при увольнении (не дай бог!) сотрудника или замене стула. Приходится придумывать административные меры, которые уберегут информацию в обеих системах от рассинхронизации — но любые административные меры могут дать сбой... Еще хуже, если систем, содержащих пересекающуюся информацию, больше, чем две, — в этом случае число связей в них будет возрастать в геометрической прогрессии. Интеграция корпоративных информационных систем стала настолько актуальной, что даже получила свой собственный термин — Enterprise Application Integration (EAI), или интеграция корпоративных приложений. Вторая задача интеграции, более важная, заключается в обеспечении связи и взаимодействия торговых партнеров и подразделений одной организации. Весь поток сообщений между торговыми партнерами легко поддается формализации и описанию, но, тем не менее, во многих случаях до сих пор обеспечивается вручную, что делает его крайне неэффективным и дорогим. Существует даже такой терм и н — стоимость транзакции, который показывает стоимость осуществления покупки. Сейчас, во время достаточно тяжелое для мировой экономики, многие компании стремятся повысить эффективность бизнеса и уменьшить стоимость (cost saving) налаженных партнерских связей, Радикального уменьшения стоимости взаимодействия организаций можно достичь, только макси-

мально автоматизировав процессы — то есть, применив интеграцию Business to Business (B2B). Всякий раз решать эту задачу «с нуля» неэффективно, точно так же, как и в случае EAI. Необходимы открытые стандарты, а также наличие инфраструктуры, облегчающей и автоматизирующей решение задач интеграции. В этой книге рассказано о применении современных серверных платформ для интеграции приложений (как в области EAI, так и в области В2В) и, конечно же, подробно описан первый специально предназначенный для интеграции приложений продукт — Microsoft BizTalk Server 2000. За тот период времени, который прошел с момента своего появления, Microsoft BizTalk Server 2000 занял достойное место среди платформ для создания решений в области интеграции и В2В. Уже сейчас достаточно много западноевропейских, американских и, что немаловажно, российских компаний выбрали BizTalk Server 2000 в качестве платформы интеграции. В книге аккумулирован опыт, собранный в процессе создания решений на базе Microsoft BizTalk Server 2000 в российской компании Digital Design. Кроме того, в книге описаны возможности еще двух серверов из линейки Microsoft .NET Enterprise Servers — Microsoft SQL Server 2000 и Microsoft Host Integration Server 2000. Интеграция на базе Microsoft BizTalk Server 2000 опирается на открытый стандарт, созданный сообществом biztalk.org (www.biztalk.org) — BizTalk Framework, который в данный момент реализован в версии 2.0. Этой спецификации тоже уделено должное внимание в книге, Некоторые материалы книги не удастся найти даже в справочной системе Microsoft BizTalk Server 2000. Они по крупицам добыты из публикаций, докладов на конференциях, а также из частных бесед с разработчиками, создавшими этот замечательный продукт. КРАТКО Эта книга посвящена решению задач интеграции приложений в EAI (Enterprise Application Integration) и В2В (Business to Business) на основе спецификации BizTalk Framework с использованием Microsoft BizTalk Server 2000, а также Microsoft SQL Server 2000 и Microsoft Host Integration Server 2000.

Для кого эта книга Эта книга — для всех, кого интересуют современные технологии разработки корпоративных приложений, в том числе для разработчиков бизнес-приложений, сотрудников IT-служб организаций, а также студентов и аспирантов, собирающихся специализироваться в данных областях. Для понимания материала книги достаточно знать основы современных технологий компонентного программирования (СОМ, СОМ+), основы программирования на языке Visual Basic 6.0 и VBScript, технологии XML, а также уметь использовать технологию доступа к данным ADO. КРАТКО Эта книга для разработчиков корпоративных информационных систем, сотрудников IT-служб организаций, а также для всех, кому интересны современные технологии разработки информационных систем.

Структура книги Книга состоит из трех основных частей, посвященных: 1. особенностям электронной коммерции и интеграции приложений; 2. возможностям Microsoft BizTalk Server 2000; 3. дополнительным платформам интеграции, В первой части приведен обзор задач электронной коммерции, а особенно задач класса «business-to-business» (B2B) и интеграции приложений. Эта часть называется «Электронная коммерция и интеграция приложений» и состоит из двух глав. • В главе I «Задачи электронной коммерции» анализируются ситуации в мире информационных технологий и рассматриваются основные сложности разработки решений по интеграции приложений и решений электронной коммерции В2В. • Глава 2 «Технологии электронной коммерции» описывает технологии, применявшиеся и применяющиеся в электронной коммерции. Дан краткий обзор XML, а также базовых технологий передачи сообщений, доступа к данным, и т. д,

Вторая часть книги, самая большая, посвящена собственно Microsoft BizTalk Server 2000. Она называется «Microsoft BizTalk Server 2000». • В главе 3 «Обзор Microsoft BizTalk Server 2000» перечислены функциональные возможности этой серверной платформы, рассматриваются вопросы лицензирования продукта, а также описана история создания и развития BizTalk Server 2000. Кроме того, в этой главе рассказано о стандарте BizTalk Framework, положенном в основу BizTalk и самого BizTalk Server, • Глава 4 «Архитектура BizTalk Server 2000» знакомит с продуктом — его основными составными частами по отдельности и вместе, а также с приложениями, входящими в состав BizTalk Server 2000. • Глава 5 «Установка и администрирование BizTalk Server 2000» посвящена установке и настройке BizTalk Server 2000. На первом этапе знакомства с BizTalk Server 2000 эту главу можно пропустить, она пригодится при разрешении частных проблем и вопросов установки. • Начиная с главы 6 «BizTalk Server Orchestration», подробно описаны компоненты BizTalk Server как набор отдельных подсистем. Здесь рассказывается об основной подсистеме BizTalk Server — Orchestration, предназначенной для «дирижирования» всеми интегрируемыми приложениями, а также распределенными приложениями в решениях В2В. • Глава 7 «Описание документов и преобразований в BizTalk Server 2000» знакомит со способами описания и преобразования документов. Интеграция приложений — это почти всегда интеграция форматов пересылаемых сообщений. А поскольку форматы сообщений разных приложений различны, необходимо их преобразование, • Глава 8 «BizTalk Server Messaging» посвящена второй основной подсистеме BizTalk Server — Messaging, отвечающей за доставку сообщений. • Глава 9 «Взаимодействие приложений с BizTalk Server 2000» посвящена возможностям BizTalk Server 2000 для взаимодействия с самыми разными приложениями. При создании интеграционных решений и решений В2В необходимо тесное вза-

имодействие с приложениями, входящими в состав общего решения. Поскольку эти приложения различны и непохожи, требуются различные принципы общения и взаимодействия, которые и обеспечивает такой сервер интеграции, как BizTalk Server. • В главе 10 «Трекинг документов» рассказано о том, как контролировать прохождение документов. Уже после того, как решение интеграции создано и сообщения между приложениями передаются непрерывно через BizTalk Server в соответствии с заданными в нем сценариями и преобразованиями, на первый план выходит задача контроля прохождения документов. В BizTalk Server она решается с помощью подсистемы трекинпэ документов, которой посвящена глава. • Глава 11 «Безопасный обмен информацией» посвящена защите, что особенно важно для сферы В2В. Эта задача решается средствами шифрования и электронной подписи сообщений. а также с помощью контроля доступа к средствам и возможностям BizTalk Server. • В главе 12 «Расширение возможностей BizTalk Server 2000» описаны возможности расширения функциональности BizTalk Server. Любое решение, каким бы хорошим и универсальным оно ни было, нужно развивать и подстраивать под нужды конкретной задачи. Третья часть книги «Дополнительные платформы интеграции» посвящена еще двум серверным продуктам Microsoft, помогающим строить решения интеграции и электронной коммерции: • Глава 13 «Возможности SQL Server 2000» посвящена SQL Server, который, начиная с версии 2000, приобрел достаточно широкие возможности по интеграции с другими приложениями посредством XML. Также SQL Server может использоваться совместно с BizTalk Server. Кроме того, здесь рассказано о возможностях SQL Server 2000 для работы в Интернете, что необходимо для решений В2В. • Глава 14 «Возможности Host Integration Server 2000» посвящена продукту с новым названием, но с богатой историей. Hos: Integration Server 2000 (ранее — Microsoft SNA Server 4.0) предназначен для создания решений, взаимодействующих с мэйнфреймами.

Завершает книгу «Заключение», где рассмотрены перспективы развития технологий интеграции и BizTalk Server, Кроме того, в книге имеется «Словарь терминов» и указатель.

Содержание компакт-диска Компакт-диск, прилагаемый к книге, содержит; • Microsoft BizTalk Server 2000 Enterprise Edition Evaluation Version (каталог CD-ROM :\BizTalk Server); • Microsoft SQL Server 2000 Evaluation E d i t i o n (каталог CD-ROM:\SQL Server); • примеры к книге (каталог CD-ROM:\Samples). Инструкции по установке BizTalk Server 2000 и SQL Server 2000 находятся в соответствующих каталогах. Требования к установке — операционная система Windows 2000 Server (или Advanced Server). Примеры к книге расположены в подкаталогах: • • • • •

Chapter02 Chapter05 Chapter07 ChapterOS Chapterl3

— — — — —

глава глава глава глава глава

2; 5; 7; 8; 13;

Для корректной работы большинства примеров содержимое каталога CD-ROM:\SampIes\ следует скопировать в каталог C:\BizTalk\. Глава 2 В каталоге CD-ROM \Samples\Chapter02\ расположены файлы, иллюстрирующие принципы XSLT-преобразований.

Глава 5 В каталоге CD-ROM \Samples\Chapter05\TestWMI\ находится пример приложения на Visual Basic 6.0, создающий функцию получения BizTalk Server. Глава 7 В каталоге CD-ROM \Samples\Chapter07\Concatenation\ расположены файлы со спецификациями документа, а также файл описания преобразования BizTalk Mapper, демонстрирующие про-

стое преобразование документов с использованием функтоида, Для проверки работы этого примера достаточно загрузить файл NameMap.xml в BizTalk Mapper и протестировать преобразование, В каталоге CD-ROM \Samp1es\Chapter07\Students\ расположены файлы с спецификациями документа, файл описания преобразования и тестовая база данных для демонстрации сложного преобразования с функтоидами. Для тестирования этого примера можно воспользоваться функцией тестирования BizTalk Mapper или же утилитой тестирования преобразования, поставляемой с BizTalk Server. Она расположена в каталоге \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\MapTest на диске, где установлен BizTalk Server. Для этого вместе с примером приведен командный файл быстрого запуска преобразования testmap.cmd. Глава 8 В каталоге CD-ROM \Samples\Chapter08\BTConfig\ находится пример приложения на Visual Basic 6.0, сохраняющего конфигурационную информацию схемы соединения BizTalk Messaging в xml-файлы. В каталоге CD-ROM \Samples\Chapter08\ расположены схемы документов и описания преобразования для простой схемы соединения, которая может быть создана с помощью файла скртипта SimpleConfiguration.vbs. Перед его запуском спецификации документов и описание преобразований должны быть скопированы в каталоги хранилища WebDAV (подкаталог Book), а после выполнения скрипта следует создать файловую функцию получения, отправляющую файлы в канал TestChannel.

Глава 13 В каталоге CD-ROM \Samples\Chapterl3\QueryHelper\ расположен пример приложения на Visual Basic 6.0, облегчающего тестирование XML-запросов в SQL Server. В каталоге CD-ROM \Samples\Chapter!3\TestVDir\ расположен пример приложения, создающего виртуальный каталог для запросов через HTTP.

Об авторе Александр Ложечкин работает начальником отдела исследований департамента разработки ПО в Санкт-Петербургской компании Digital Design (www.digdes.ru), занимающейся созданием корпоративных информационных систем. Специализируется в области современных технологий, преимущественно компонентных технологий и технологий построения распределенных корпоративных приложений. Своими познан и я м и в этой области щедро делится, выступая на различных конференциях, проводимых компанией Microsoft (DevDays, TechEd), и в статьях, периодически появляющихся в российских компьютерных изданиях — «Byte», «Мир ПК», «Открытые системы», «КомпьютерПресс», Живет с семьей в Санкт-Петербурге. Увлечения — книги, друзья и работа, которая уже стала не только профессией, но и хобби.

Благодарности

с,

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

Спасибо моим коллегам из компании Digital Design, которые своими советами сделали эту книгу лучше: Владиславу Васильеву, Ольге Косолаповой, Арсению Белонучкину. Именно их усил и я м и создано первое в России решение на базе BizTalk Server. Спасибо Антону Смольяниыову и Сергею Березнякову, улучшившим код примеров к книге. Спасибо всем остальным моим коллегам, которые периодически интересовались судьбой книги и не дали мне забросить это дело (хотя я и не собирался). Спасибо Андрею Федорову и Анатолию Суркису, сделавшими возможной мою поездку в Редмонд, в Microsoft, где я смог пообщаться с идеологом BizTalk и руководителем программы BizTalk Server Скоттом Вудгейтом (Scott Woodgate), спасибо также Джен Шенехэн (Jan Shanahan) и Меган Столберг (Megan Stuhlberg), организовавшим эту встречу, Спасибо Александру Драгунову, от которого я впервые услышал название «BizTalk». Спасибо сотрудникам российского представительства компании Microsoft Дмитрию Старостину, Юрию Томашко и Кириллу Жучкову, которые подогревали интерес к BizTalk Server, предлагая мне рассказывать о нем на конференциях проводимых компанией. Спасибо Алексею Федорову и Андрею Колесову, взявшимся опубликовать мои статьи о BizTalk Server в журналах «КомпьютерПресс» и «Byte». Большое спасибо Андрею Козлову, главному редактору издательства «Русская Редакция», постоянно напоминавшему мне о книге и не давшему сорвать сроки ее выхода. Спасибо Юлии Леоновой, редактору этой книги, сделавшей ее. надеюсь, читаемой. Также мои благодарности всем, кого я забыл упомянуть: это не из-за невнимания, а по причине того, что эти строки я пишу поздней ночью. А также большое спасибо всем тем, кто нашел эту книгу достойной своего внимания — значит, я работал не зря. Александр Ложечкин, Санкт-Петербург, ноябрь 2001 года.

ЧАСТЬ

I

Электронная коммерция и интеграция приложений

ГЛАВА

1

Задачи электронной коммерции ч^лова «e-commerce», «dotcom», «B2B», «В2С» прочно вошли в лексику специалистов по информационным технологиям. Сегодня уже трудно представить, как сделать бизнес эффективным без применения современных инструментов, таких, например, как электронная коммерция. Несмотря на некоторый спад, который наблюдается сегодня в сфере высоких технологий, аналитики прогнозируют, что электронная коммерция все-таки будет развиваться. В этой главе рассказано, как эффективно автоматизировать бизнес-процессы и сократить расходы на их обслуживание при помощи современных технологий, В этой главе В этой главе перечислены основные вехи в развитии электронной коммерции и перспективы ее дальнейшего развития, а также затронута проблема «островной автоматизации» — одной из главных при автоматизации бизнес-процессов.

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

Часть [, Электронная коммерция s-i интеграция приложений

ко и прошло практически незамеченным. Хотя теперь уже трудно представить современную организацию без таких средств связи, как факс или электронная почта. Кроме того, возросла информированность партнеров: Интернет представляет всю необходимую для заключения сделки информацию. Это стало возможно благодаря тому, что множество организаций во всем мире обзаводятся собственными страничками или даже узлами в Интернете, где публикуют сведения о компании, о ее достижениях, о предлагаемых товарах и услугах и, конечно же, оставляют координаты для связи. Таким образом, Интернет стал огромной рекламной шюшадкой, такой же, как газеты или телевидение. Однако еще несколько лет назад для заключения сделки партнерам все-таки приходилось вступать в непосредственный контакт. Теперь и это не обязательно. Интернет-технологии позволяют совершать сделки непосредственно через Интернет-узел. В прайс-листах многих компаний, опубликованных в Интернете, появилась маленькая волшебная кнопочка «Купить»! Из средства. используемого на стадии подготовки сделки, Интернет стал средством проведения сделки. Прошло совсем немного времени — и появились платежные системы, средства для оплаты по карточкам, а вслед за этим и хакеры, взламывающие Интернет-магазины, а там — и кризис Интернет-магазинов. Параллельно с розничной торговлей активизировалось применение Интернета для корпоративных продаж, когда и продавец, и покупатель являются организациями-партнерами. Стали возникать так называемые «торговые плошадки», своего рода электронные товарные биржи, сгруппированные по интересам: производители автомобилей объединились и создали «торговую площадку» для покупки/продажи комплектующих (что позволило им, помимо повышения эффективности сделок, заставить поставщиков снизить цены), нефтяные компании через Интернет заключают сделки по покупке оборудования, медицинские организации — фармакологических препаратов. Примеров можно привести множество, Таким образом, сейчас Интернет стал не только средством общения людей и громадным информационным ресурсом, не

только магазином для частных лиц, но и средством проведения сделок между организациями. Возникли приложения для розничной и оптовой торговли: приложения для розничной торговли относятся к классу В2С -- Business-to-Customcr или Business-toConsumer (связывающие розничного продавца и частного покупателя), а решения, объединяющие две организации между собой, называются В2В, то есть Business-to-Business. ПРИМЕЧАНИЕ Существуют также более узкие классификации, например B2G (Business-to-Governmem), то есть объединение частных и правительственных организаций. Еще появилась «ехидная» аббревиатура 2ВВ, что расшифровывается, как То be business (переводится, как «Быть бизнесом»). Она появилась в ответ на множество рекламных акций, в которых многие маленькие компании для придания себе и своим продуктам веса снабжали их громкими и, самое главное, модными лозунгами «В2С», «В2В» и т. д. Конечно, прежде всего, для создания решений В2С или В2В нужно зарекомендовать себя бизнесменом, а не только называться им: хотя все новые технические средства для ведения бизнеса помогают повысить эффективность существующей технологии работы, они не могут ее заменить. Именно попытка выдать желаемое за действительное и привела к снижению активности на рынке высоких технологий. Схематично эволюция возможностей Интернета показана на рис. 1-1,

Эффективный бизнес в Интернете: ???

Корпоративные продажи: торговые площадки

Розничные продажи: магазины

Интернет

Рис. 1 -1.

Эволюция возможностей Интернета

Ситуации Чтобы ответить на вопрос, что будет дальше, необходимо рассмотреть проблемы, которые возникают в процессе работы с автоматизированными системами. Многие фирмы предпочитают не увеличивать количество клиентов, а улучшать эффективность работы с ними. И это понятно, так как именно постоянные клиенты, по выводам аналитиков, приносят до 80% дохода. Предположим, компания уже много лет торгует канцелярскими товарами (или любым другим товаром или услугой), причем достаточно успешно. Естественно, она имеет достаточно большую клиентскую базу, которая постоянно расширяется. Она заключила партнерский договор с другой компанией на долговременное сотрудничество, где определен порядок их взаимодействия. Теперь остается технически обеспечить процесс осуществления сделки.

Деятельность организаций, участвующих в сделке, в той или иной мере автоматизирована (сейчас уже трудно представить организацию, не использующую хотя бы бухгалтерскую или складскую учетную систему). В компании покупателя зачастую автоматизированы сбор заказов на канцелярские принадлежности от сотрудников, формирование общего для компании списка заказов, система контроля и оплаты счетов и др. У продавца наверняка автоматизирована система приема и обработки заказов от клиентов, складской учет и т. д. В заключении сделки принимает участие также банковская система, которая обеспечивает расчеты между организациями безналичным путем. Таким образом, даже в таком простом случае, участников сделки как минимум три, причем каждый из них обладает собственной автоматизированной системой или системами, не связанными между собой, А как связать эти системы в единый бизнеспроцесс покупки/продажи товара? Конечно, если данная задача не автоматизирована, координировать их действия придется человеку! В описанном случае для этого потребуются даже несколько человек, как минимум, по одному от каждой организации. Все эти люди параллельно с выполнением своих непосредственных обязанностей будут принимать сообщения одной автоматизированной системы и заносить ее в другую автоматизированную систему. То есть заниматься рутинными и однообразными операциями по интеграции информационных систем. Ситуация выглядит немногим лучше, если бизнес-процесс не выходит за границы одной организации. Существует термин «островная автоматизация», характеризующий современное состояние информатизации многих структур, когда автоматизированы многие сферы деятельности, однако автоматизированные системы никак не связаны друг с другом. В этом случае перенос информации из одной системы, одного «островка автоматизации», в другую (рис. 1-2) возлагается на людей.

Часть I. Электронная коммерция и интеграция приложений

Рис. 1 -2.

Пример «островной автоматизации»

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

ГЛАВА 2

Технологии электронной коммерции Ьурное развитие Интернета вызвало изменения и в лексике: многие слова стали употребляться с префиксом «е-», в том числе и слово «коммерция». В настоящее время существует множество технологий, применение которых позволяет реализовать новый способ коммерции — е-коммерцию. В этой главе В этой главе дан не претендующий на подробность и точность обзор используемых в электронной коммерции технологий. Прежде всего речь пойдет о технологии, лежащей в основе всей электронной коммерции и особенно направления интеграции приложений — XML. Не менее интересны технологии связи, позволяющие общаться приложениям, находящимся за многие сотни коммутаторов друг от друга — HTTP, SMTP, MSMQ. И, естественно, никакая система не может в наши дни обойтись без хранилища данных, и поэтому один раздел посвящен технологиям доступа к данным.

XML Публикаций об XML великое множество, поэтому, чтобы не повторяться, описание технологии XML здесь дано достаточно кратко. Более подробно об XML рассказано в главе 7 «Описание документов и преобразований в BizTalk Server 2000», а также, например, в книге Брайана Тревиса «XML и SOAP: программирование для серверов BizTalk. Новейшие технологии» («Русская Редакция», 2001).

Появление XML XML создан на основе языка разметки SGML (Standard Generalized Markup Language), очень сложного в изучении и использовании, а также широко популярного HTML, применяемого для графического форматирования текстов, весьма нового и неудобного, но поддерживаемого производителями браузеров и создателями Web-серверов. Ко времени появления XML назрела необходимость в стандартизированном и гибком языке, который позволял бы без труда добавлять новые возможности, теги и конструкции языка. Именно все эти возможности и содержит XML. который можно рассматривать как упрощенный расширяемый язык SGML. XML поддерживает немного возможностей SGML, однако таких, которые позволяют решать большинство задач (здесь работает известный принцип 20% возможностей решают 80% задач). В тоже время стандарт XML существенно строже и не допускает вольностей HTML. Самое главное отличие XML от HTML, если их можно сравнивать, в том, что XML не налагает ограничений на набор тегов и атрибутов — они могут быть любыми. Существуют лишь ограничения на формат описания и того и другого.

Структура XML- документа Простой XML-документ показан на рис. 2-1. "3 C:\Temp\teet.Hird - Microsoft Internet £н

- tpn:.;i;

!.)ev(!kipl4

i --

И.- ;

ограничений [а

ограничений i-!

\>. ;

м , - '.

ограничений

ограничений

Ь.' '

Ы- ,

ограничений

ограничений

[а

[а

Ориентировочная стоимость BizTalk Server — USA$ 5 000 за Standard Edition и USAS 25 000 за каждый процессор в Enterprise Edition. Версия для разработки (Developer Edition) существенно дешевле. Также доступна демонстрационная версия Evaluation Edition, бесплатно распространяемая на дисках и доступная для загрузки на узле Microsoft. BizTalk Server Evaluation Edition расположена на компакт-диске, прилагаемом к книге.

ГЛАВА 4

Архитектура BizTalk Server 2000 /Для того чтобы наилучшим образом понять возможности какого-либо продукта, прежде всего стоит во всех подробностях рассмотреть его компоненты и их взаимосвязи. Однако за частностями не следует забывать о целом — ведь интересны возможности всего продукта целиком. Именно поэтому рассказ о возможностях Microsoft BizTalk Server 2000 начинается с описания его архитектуры. В этой главе Эта глава построена по принципу «от общего к частному*. Вначале рассматриваются подсистемы Microsoft BizTalk Server 2000 — BizTalk Messaging и BizTalk Orchestration, затем компоненты этих подсистем и, наконец, рисуется подробная архитектура BizTalk Server в целом. ПРИМЕЧАНИЕ Эта глава очень тесно связана с предыдущей — «Обзор Microsoft BizTalk Server 2000*, в которой BizTalk Server рассматривался с точки зрения тех задач, которые он позволяет решать. Естественно, в одной главе нельзя подробно описать все подсистемы и компоненты BizTalk Server, поэтому здесь часто встречаются ссылки на следующие главы, посвященные той или иной функции или компоненту.

Подсистемы BizTalk Server Microsoft BizTalk Server 2000 состоит из двух основных подсистем — BizTalk Messaging и BizTalk Orchestration.

Подсистема BizTalk Messaging предназначена для соединения с приложениями, то есть непосредственно для решения задач интеграции: транспортировки сообщений от приложения серверу интеграции с использованием различных транспортных протоколов, сложных преобразований сообщений из формата одного приложения в формат другого, а также для решения вспомогательных задач, например гарантированной доставки сообщений и зашиты от несанкционированного доступа. (Подпобно об этом — в главах 7, 8, 9). Задачи BizTalk Orchestration несколько иные — связать друг с другом несколько приложений на уровне общего бизнес-процесса. В BizTalk Orchestration не предусмотрены развитые возможности транспортировки и преобразования сообщений (для этого есть BizTalk Messaging), зато Orchestration позволяет создавать сложные сценарии взаимодействия, связывающие воедино несколько разнородных приложений. Сценарий взаимодействия — это описание бизнес-процесса, составными частями которого являются интегрируемые приложения. При этом в описании сценария разрешается применять различные условия, циклы и даже транзакции. Подсистема BizTalk Orchestration использует возможности BizTalk Messaging по транспортировке и преобразованию

BizTalk Orchestration

-Z X

BizTalk Messaging

Приложение 1

Рис. 4-1.

Приложение 2

Приложение N

Взаимодействие подсистем BizTalk Server и приложений

сообшений. но при этом она способна и самостоятельно, без участия BizTalk Messaging, отправлять и получать сообщения через очереди MSMQ, а также вызывать СОМ-компоненты (рис. 4-1). О подсистеме BizTalk Orchestration рассказано в главе 6. BizTalk Server расширяет принципы многоуровневой архитектуры приложений, привычно используемой при рассмотрении сложных распределенных приложений. Принято разделять приложения на слои (tiers), или уровни (levels), на каждом из которых решаются те или иные задачи (рис. 4-2): • уровень представления (presentation level) — отвечает за реализацию пользовательскою интерфейса; • уровень реализации бизнес-логики (business-logic level) — отвечает за работу приложения, реализует его основные функции; • уровень доступа к данным (data access level) — организует и управляет доступом к информации приложения, Уровень представления {Presentation Level)

Уровень реализации бизнес-логики (Business-logic Level]

Уровень доступа к данным Data Access Level

Рис. 4-2.

Классическая многоуровневая модель приложения

Все эти уровни можно выделить даже в самом простом приложении, но наиболее четко они проявляются именно в сложных распределенных системах. Что же меняет использование BizTalk Server? При интеграции нескольких приложений их взаимодействие организуется не на уровне пользовательского интерфейса, а на уровне интерфейса программного, то есть на уровне реализации бизнес-логики системы. Несколько совместно работающих приложений удается связать друг с другом посредством BizTalk Orchestration и организовать бизнес-процесс. Таким образом, место BizTalk Orchestration в многоуровневой модели — между уровнем бизнес-логики и уровнем представления.

Часть 51, Microsoft BizTaik Server 2000

Подсистема BizTaik Messaging берет на себя организацию обмена информацией. Информация в сообщении располагается на уровне данных. Таким образом, решая задачу транспортировки сообщений, BizTaik Messaging на многоуровневой модели располагается между уровнями доступа к данным и уровнем реализации бизнес-логики. Модель интегрированных с помощью BizTaik Server приложений показана на рис. 4-3. Уровень представления (Presentation Level)

Уровень управления бизнес-процессом {Orchestration Level)

Уровень реализации бизнес-логики (Business-logic Level)

Уровень управления сообщениями (Messaging Level)

Уровень доступа к данным Data Access Level

Рис. 4-3.

J

Многоуровневая модель при использовании BizTaik Server

Архитектура BizTaik Server Архитектуру BizTaik Server можно представлять разными способами. Например, логическая архитектура показывает разделение BizTaik Server на подсистемы с точки зрения выполняемых функций. Системная архитектура показывает BizTaik Server как набор компонентов, приложений и баз данных.

Логическая архитектура Рассмотрим состав подсистем BizTaik Server с точки зрения решаемых задач. К показанным ранее подсистемам Messaging и Orchestration можно добавить еше одну: BizTaik Document Tracking (рис. 4-4).

Подсистема BizTalk Document Tracking решает вспомогательные задачи. Она необходима для контроля работы решения на BizTalk Server — в ней накапливается информация обо всех прошедших через BizTalk Server документах и сообщениях. Вся информация трекинга сохраняется в базе данных. В текущей версии BizTalk Server реализована только функция сбора информации об обработанных BizTalk Messaging сообщениях, но впоследствии планируется сохранять и информацию о выполняющихся в Orchestration бизнес-процессах. Подсистема BizTalk Orchestration состоит из сервиса, исполняющего сценарии бизнес-процессов. В качестве входной информации в BizTalk Orchestration принимает откомпилированные на языке XLANG описания сценариев и выполняет их, вызывая подсистему BizTalk Messaging и СОМ-компоненты, а также обрашаясь к очередям MSMQ. За выполнение сценариев отвечает сервис XLANG Schedule Engine,

XLANO Schedule Engine

Tracking Info

Подсистема BizTalk Orchestration

Подсистема BizTalk Document Tracking

Messaging Engine

Transport Services

Shared Queues

WebDAV Store

Подсистема BizTalk Messaging

Рис. 4-4.

Логическая архитектура BizTalk Server

Подсистема BizTalk Messaging, отвечающая за взаимодействие с отдельными приложениями, состоит из следующих компонентов: •

транспортных сервисов (transport services), которые реализуют возможность доставки документа к приложению. Ведь для

Microsoft BizTalk Server 2000

интеграции с приложениями помимо анализа содержимого проходящих документов и преобразований необходима и эта возможность; • очереди сообщений (shared queues), которые предназначены для временного хранения обрабатываемых документов и сообщений; • хранилище H^6£HK(WebDAV Store), которое используется для хранения описаний документов и преобразований. Управление подсистемой BizTalk Messaging осуществляет сервис Messaging Engine.

Системная архитектура На системном уровне BizTalk Server 2000 BizTalk Server можно рассматривать как совокупность сервисов и приложений, построенных на базе инфраструктуры, предоставляемой платформой Windows и архитектурой построения приложений Microsoft Windows DNA 2000 (Distributed interNet Applications Architecture архитектура распределенных сетевых приложений). Инфраструктура BizTalk Server 2000 BizTalk Server 2000 работает с помощью множества серверных и клиентских приложений. Среди них есть базовые серверные приложения, такие, как Microsoft SQL Server или Microsoft Message Queuing (MSMQ), а также вспомогательные клиентские приложения. BizTalk Server 2000 применяет следующие базовые серверные приложения: • Windows 2000 — в качестве операционной системы для серверных компонентов и клиентских управляющих приложений; BizTalk Server использует компонентные сервисы Windows (СОМ+), а также модель безопасности Windows; • SQL Server версий 7.0 или 2000 — для хранения и управления базами данных BizTalk; • Internet Information Services (IIS); в частности, World Wide Web Publishing Service используется для реализации хранилища WebDAV, приложения BizTalk Messaging Manager и для реализации транспортных протоколов HTTP и HTTPS;

• Microsoft Message Queue Services (MSMQ) — в качестве одного из транспортных протоколов. BizTalk Server 2000 применяет следующие клиентские приложения: • Internet Explorer 5.0 (и выше) — для работы приложения BizTalk Document Tracking; • Microsoft Management Console (MMC) — для работы административной консоли BizTalk Server Administration; • Microsoft Visio 2000 (или 2002) — на его основе построено приложение BizTalk Orchestration Designer. Кроме того, BizTalk Server использует программные библиотеки и сервисы: • СОМ + . BizTalk Server построен с использованием возможностей технологии СОМ+, он применяет их, в частности, для реализации транзакций BizTafk Orchestration и слабо связанных событий (loosely coupled events) в XLANG Event Monitor, кроме того, он рассчитан на возможное применение кластеров на базе Microsoft Application Center 2000; • Windows Management Instrumentation (WMI) применяется для построения модели конфигурирования BizTaik Server: • BizTalk Server рассчитан на работу с третьей версией Microsoft XML Parser. Компоненты BizTalk Microsoft BizTalk Server 2000 состоит из нескольких компонентов: хранилища WebDAV, баз данных конфигурации BizTalk Server и очередей BizTalk Messaging. Хранилище WebDAV

Название WebDAV расшифровывается как Web Distributed Authoring and Versioning, то есть протокол обеспечения авторизации и всрсионинга для распределенных приложений в Web. WebDAV используется для хранения схем документов и описаний преобразований. Основные достоинства хранилища в возможности доступа к нему по протоколу HTTP, на котором основан и протокол Web DAV

WebDAV — это расширение известного и широко использ>емого протокола доступа к Web-страницам HTTP 1.1. Оно предоставляет команды для доступа к иерархическому хранилищу, аналогичному файловой системе, позволяет устанавливать блокировку на файлы для изменений, а также организовать совместную работу с документами пользователей в Интернете. WebDAV используется как один из интерфейсов доступа к технологии хранилища Web Storage, разрабатываемого Microsoft. Web Storage применяется в качестве хранилища в Microsoft Exchange 2000, а также считается базовым для нового продукта Microsoft Share Point Portal Server 2001. В BizTalk Server WebDAV реализован с помошью World Wide Web Publishing Service в Internet Information Services. В каталоге \Program Files\Microsoft BizTalk Scrver\BizTalkServerRepository на диске, где установлен BizTalk Server, расположены файлы из хранилища, а в Default Web Site IIS реализована виртуальная папка BizTalkServerRepository, соответствующая этому каталогу на диске. Все команды WebDAV обрабатываются IIS и позволяют управлять содержимым каталога и менять его. В качестве клиентской библиотеки для доступа по протоколу WebDAV используется Microsoft BizTalk Server WebDAV 1.0 Type Library. Хотя ее интерфейс недокументирован, при необходимости с его помощью удается решать достаточно сложные проблемы функционирования хранилища. При установке в сети нескольких серверов BizTalk хранилище схем документов и преобразований лучше организовать одно для всех — это позволит использовать общие файлы описания документов и преобразований для всех серверов в группе. Базы данных BizTalk Server BizTalk Server обращается к серверу управления базами данных Microsoft SQL Server (7.0 SP2 или 2000) для хранения следующей информации; • базы данных конфигурации подсистемы BizTalk Messaging. Она по умолчанию называется Interchange BTM и предназначена для использования сразу несколькими группами серверов BizTalk. Состоит из таблиц, хранящих информацию обо всех объектах конфигурации подсистемы Messaging, и содержит хранимые процедуры для управления ими;

• базы данных очередей сообщений InterchangeSQ; она содержит таблицы с элементами очередей. Используется подсистемой BizTalk Messaging и разделяется всеми серверами в группе; • базы данных трекинга подсистемы BizTalk Document Tracking — InterchangeDTA; она разделяется всеми серверами в группе. Содержит информацию обо всех документах, прошедших через сервера BizTalk; • базы данных сохранения состояния процессов XLANG. Используется СОМ-b-приложением XLANG Scheduler для хранения состояния процессов и применяемых в них СОМ-компонентах. Некоторые базы данных могут использоваться только одним сервером BizTalk, а другие разделяются между серверами, как это показано на рис. 4-5. База данных Orchestration (XLANG DB) создается отдельно для каждого сервера. Группа серверов использует обшие базы данных очередей и трекинга. База данных конфигурации BizTalk Messaging — общая для нескольких групп.

BTS Messaging

BizTalk Server

BizTalk Server

BizTalk Servers Group

Рис. 4-5.

BizTalk Server

BizTalk Server

BizTalk Servers Group

Применение баз данных BizTalk Server

Очереди BizTalk Messaging Очереди BizTalk Messaging служат временным хранилищем обрабатываемых сообщений. Как уже говорилось ранее, очереди BizTalk Messaging физически реализованы в базе данных очередей сообщений InterchangeSQ. Всего в подсистеме Messaging четыре очереди сообщений: • Work queue — очередь обрабатываемых документов. Все документы, попавшие в BizTalk Messaging, попадают именно сюда. но долго здесь не задерживаются и отправляются на обработку в сервис BizTalk Messaging Engine; • Scheduled queue — очередь приостановленных документов. Содержит сообщения и документы, ожидаюшие подтверждения при гарантированной доставке, а также документы, ожидающие отправки в установленное время; • Retry' queue — очередь повторных документов. Используется для хранения повторно отправленных документов, например, при организации гарантированной доставки; • Suspended queue — очередь остановленных документов. Содержит документы, не прошедшие обработку по каким либо причинам. Вместе с сообщением в этой очереди хранится и информация об ошибке, приведшей к попаданию сообщения в очередь. Таким образом, все документы в BizTalk Messaging проходят через очередь обрабатываемых документов, а затем либо сразу из нее отправляются в пункт назначения, либо попадают в одну из оставшихся трех очередей: очередь приостановленных документов, если они ожидают отправки, или в очередь повторных документов, если не удалось доставить документ с первой попытки. В очередь остановленных документов новые элементы добавляются из всех очередей — в случае ошибки.

Приложения BizTalk Server Для взаимодействия с подсистемами BizTalk Server и управления сервером используются следующие приложения: • BizTalk Orchestration Designer. Приложение реализовано на базе продукта Microsoft Visio 2000. Работа с Microsoft Visio 2002 возможна после установки BizTalk Server Service Pack la. Biz-

Talk Orchestration Designer предназначен для создания и описании сценариев бизнес-процессов, его пользовательский интерфейс разделен на две части — одна для аналитика, знающего и описывающего бизнес-процесс безотносительно его реализации, и вторая для разработчика, который присоединяет отдельные точки описания бизнес-процесса к реальным приложениям, заставляя их работать вместе. Подробное возможности BizTalk Orchestration и BizTalk Orchestration Designer описаны в главе 6 «BizTalk Server Orchestration»; BizTalk Messaging Manager. Клиентское приложение, совмещающее в себе обычный пользовательский интерфейс и интерфейс в виде страниц ASP (Active Server Pages) в Internet Information Services. Предназначено для создания схемы соединения BizTalk Messaging для соединения с приложениями, преобразований форматов и маршрутизации. О нем рассказано в главе 8 «BizTalk Server Messaging»; BizTalk Server Administration. Инструмент администрирования группы серверов BizTalk, реализован в виде snap-in (оснастки) к Microsoft Management Console (MMC). Описанию администрирования BizTalk Server посвящена глава 5 «Установка и администрирование BizTalk Server 2000»; BizTalk Editor. Это приложение предназначено для создания схем документов BizTalk; BizTalk Mapper. BizTalk Mapper позволяет описать преобразование документов из одного формата в другой. Описанию BizTalk Editor и Mapper посвящена глава 7 «Описание документов и преобразований в BizTalk Server 2000»; BizTalk Document Tracking. Приложение с Web-интерфейсом, реализованным в виде ASP-страниц. Предназначено для доступа к базе данных трекинга, содержащей информацию о прошедших через BizTalk Server документах. О трекинге рассказано главе 10 «Трекинг документов»; XLANG Event Monitor. Инструмент для отладки выполняющихся сценариев BizTalk Orchestration.

Общая архитектура Microsoft BizTalk Server 2000 Теперь, когда назначение отдельных компонентов BizTalk Server более или менее ясно, пора сказать несколько слов о работе всей системы в целом. Архитектура Microsoft BizTalk Server 2000 показана на рис. 4-6. BizTalk Server 2000 можно считать сервером, получающим по одному из транспортных протоколов сообщение от некоторого интегрируемого приложения в определенном формате и отправляющим сообщение в ином формате другому приложению по другому транспортному протоколу. При этом сервер самостоятельно управляет общением с приложениями, ориентируясь на выполняемый сценарий интеграции,

Подсистема BizTalk Orchestration

Рис. 4-6.

Общая архитектура BizTalk Server

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

ГЛАВА 5

Установка и администрирование BizTalk Server 2000 "1тобы воспользоваться возможностями BizTalk Server, о которых говорилось в предыдущих двух главах, а подробнее будет рассказано в последующих, необходимо установить сам Microsoft BizTalk Server 2000. В этой главе Как следует из названия, эта глава посвящена установке и настройке BizTalk Server. Программа установки BizTalk Server создана с использованием технологии Windows Installer, и поэтому возможна как установка в ручном режиме, когда вся требуемая мастером установки информация вводится в появляющиеся диалоговые окна мастера, так и установка в автоматическом режиме, при которой все конфигурационные параметры передаются в программу установки с помощью конфигурационных файлов. ПРИМЕЧАНИЕ Для лучшего усвоения материала этой главы рекомендуется изучить архитектуру BizTalk Server, описанную в главе 4.

Установка BizTalk Server 2000 Версии BizTalk Server 2000 и варианты установки Как уже говорилось ранее, BizTalk Server поставляется в трех версиях: Standard, Enterprise и Developer. Их отличия с точки зрения

Часть И. Microsoft BizTalk Saver 3000

программы установки минимальны — в версиях Enterprise и Developer имеется компонент BizTalk Server Software Developers Kit (SDK). Варианты их установки также одинаковы: • Complete Installation — полная установка продукта; • Tools Installation— установка только инструментов BizTalk Server: (BizTalk Orchestration Designer, BizTalk Document Tracking, BizTalk Editor, BizTalk Mapper) и справочной системы BizTalk Server 2000; • Custom Installation — этот тип установки позволяет выбрать компоненты для установки.

Требования для установки Как и любая программа установки любого программного продукта, программа установки BizTalk Server 2000 предъявляет определенные требования к конфигурации компьютера — как аппаратные, так и программные. Требования к аппаратной конфигурации Минимальные требования для работы BizTalk Server таковы: • • • •

процессор Intel Pentium 300 МГц; не менее 128 Мб оперативной памяти; не менее 6 Гб дисковой подсистемы; CD-ROM, сетевой адаптер, мышь и VGA-монитор.

Однако такая конфигурация позволит разве что разрабатывать решения на BizTalk Server. Для эффективной работы необходим компьютер помощнее с большим объемом памяти. При этом работает принцип; нет пределов совершенству, но в разумных границах и с учетом реальных уловий! При развертывании промышленной конфигурации BizTalk Server для выработки требований необходимо учитывать возможную загрузку — количество документов, проходящих через BizTalk Server, количество и ресурсоемкость исполняемых сценариев BizTalk Orchestration, конфигурацию системы трекинга документов и т. д. Нельзя заранее точно предсказать необходимую конфигурацию сервера — можно лишь предложить рекомендации по выбору аппаратной платформы. Самый простой способ для улучшения производительности — установка BizTalk Server на три

5.

Установка т зйминистр&фовавие BizTaik Server 20Ш

компьютера: один для собственно BizTalk Server, второй для базы данных трекинга и третий для баз д а н н ы х очередей и для базы данных конфигурации BizTalk Messaging. С точки зрения производительности нелишне также разместить на разных компьютерах средства BizTalk Server для обработки и получения документов. Если требуется активная работа по трекингу проходящих документов, то базу данных трекинга лучше расположить на компьютере с RAID-массивом или хотя бы на выделенном высокопроизводительном жестком диске. Требования к программной конфигурации Для работы BizTalk Server необходима, прежде всего, операционная система Microsoft Windows 2000 с установленным Service Pack 1 или более поздним и файловой системой NTFS. Серверные компоненты системы используют базу данных SQL Server 7.0 (с установленным Service Pack 2 или более поздним) или SQL Server 2000. Для работы хранилища WebDAV и приложения BizTalk Messaging Manager необходим World Wide Web Publishing Service, входящий в Internet Information Services. Internet Explorer 5.0 (или выше) потребуется для работы приложения BizTalk Document Tracking. BizTalk Orchestration Designer работает в среде Microsoft Visio 2000 SR-1A. Работа с более поздней версией Visio 2002 поддерживается только при установке BizTalk Server Service Pack la. Также для работы BizTalk Server могут потребоваться (но необязательны) сервер очередей Microsoft Queue Services (MSMQ) и почтовый сервер SMTP с открытой возможностью маршрутизировать сообщения через него (по умолчанию это средство в IIS SMTP Service и в Exchange Server запрещено).

Мастер установки BizTalk Server 2000 Последовательность установки BizTalk Server можно логически разделить на несколько частей — выбор типа установки, установку необходимых компонентов и установку баз данных. Но первое, что необходимо сделать до начала установки, — убедиться, что пользователь, от имени которого будет выполняться установка, обладает всеми необходимыми правами, то есть входит в группу локальных администраторов.

На рис. 5-1 показано первое окно мастера установки BizTalk Server 2000 с приветствием и настоятельной рекомендацией ознакомиться с инструкцией по установке. Не стоит ей пренебрегать, Welcome to the Microsoft BizTalk Server 2000 Setup Wizard The Instel5hiefcf(R) 5etup Wizard wil rnstal Microsoft BiiTalk Server 2000 on your comDUter. To cantinije, dick Next,

to installing Microscft EizTalk Server ЯЮС, it is strongly eccmmerided that you "Jew the Installation Guide,

Microsoft Windows 2000 Server i

Service Pack:

Рис. 5-1.

Первое окно мастера установки BizTalk Server 2000

В следующих окнах вводится код, лицензии, выберается тип установки. (т чи i osott BizTalk Server 2000 Setup Custom Setup Select the program features that you want to install

services cjl'i Messaging

:

*-

:

*'

.i

3ai_T.] Orchestration

;

' Thss featurstesjiifes IJMEan уал hard •

-^ij-i SIML Tools

1 3 BizT* orchestrate De< j^ftte^ t йМй^в^я?*^.^ Jeild 5DK ar*:

:

|

fe.jj

j _J^__j I

Рис. 6-29. Выбор направления пересылки сообщений блока BizTalk Messaging iKi Rrn.hnq Wizard KLfthG Schedule Activation Information Confirm wtieH-.er the BETjJk. Messaging cliannR schedule instance upon message ai rival

Рис. 6-30.

Выбор необходимости запуска нового сценария

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

Блоки связи Блоки связи позволяют организовать взаимодействие блоков процесса и блоков реализации, Они содержат сведения о движущихся в бизнес-процессе сообщениях. Основной блок связи порт. Здесь необходимо еще раз отметить, что порт, как блок связи в BizTalk Orchestration Designer, не имеет ничего общего с портом в схеме соединения BizTalk Messaging, хотя называется так же. Порт связывает блоки реализации из правой части листа процесса и блоки действия (Action) из левой.

Порт Порт создастся автоматически (об этом рассказано ранее) — при создании любого из блоков реализации. Кроме того, предусмотрена возможность создать порт другим способом. Для этого в контекстном меню, появляющемся при щелчке правой кнопкой мыши белой разделительной полосы в центре листа процесса BizTalk Orchestration Designer, надо выбрать команду Add New Port. Свойств у порта немного — только имя. Основные параметры порта указываются при настройке соединения порта и блока Action. Для соединения блока действия и порта пользуются теми же средствами, что и при соединении нескольких блоков процесса между собой. Необходимо выбрать инструмент Connector Tool из панели инструментов и соединить блоки действия и порта. Появившееся окно мастера предназначено для настройки соединения (рис. 6-31). В зависимости от присоединенного к порту блока реализации оно может отличаться заголовком, но содержимое неизменно (за исключением того, что для порта, соединенного с очередью MSMQ или с подсистемой BizTalk Messaging, опции выбора называются по-другому — Send и Receive). Главная возможность этого окна — настройка порта на получение или отправку сообщений. Если порт соединен с блоком BizTalk Messaging, то выбор не разрешен, поскольку направление задается в самом блоке BizTalk Messaging . Если порт настроен на отправку, никаких дополнительных параметров задавать не нужно. Если блок настроен на получение, то стоит указать приблизительное время появления сообщения. Этот параметр необходим лишь для того, чтобы сервис выполнения сценария мог определить необходимость замораживания сценария, которое осуществляется при длительном ожидании сооб-

щения. Сценарий не будет завершен, если за указанный промежуток времени сообщение не появится. Welcome to tlie Method Communication Wizard ThB wizard helps you to create :he oommunication thai: «cuts D«v*een in act.on and а вал. Whe-i the SLttJC Schaouler Enc reaches this acbori in ai XLANG schedule, the engine at eithei inHete 8 method tal, и wet For л nsthod -.all to h* ntiited ff tmtiatE a syrichronous rncthod cal Г Wait fa a synchroiuui method ca

Рис. 6-31.

Выбор направления в окне мастера настройки соединения

Следующий шаг — указание используемого в данном порте типа сообщений. Для вызова компонентов этого делать не нужно, так как для них входящее сообщение составляется из входных параметров метода, а исходящее — из выходных параметров, и поэтому содержимое сообщения определяется автоматически на основании описания интерфейса. Для портов, соединенных; с блоками Message Queuing и BizTalk Messaging, необходимо указать тип сообщения (рис. 6-32). Можно создать новый тип или же выбрать один из ранее заданных типов сообщений.

:rt:,** .* SJl* „. -r I, C.UIK ••.!?. I: . .',-. r. ^;зLVт^U|•^"•

Рис. 6-32.

Выбор типа сообщения

Далее необходимо решить, будет ли сообщение восприниматься BizTalk Orchestration как текстовая строка или как XML-файл. Если сообщение является XML-файлом, для него разрешается указать спецификацию (созданную средствами BizTalk Editor), и тогда сообщение будет восприниматься не как строка, а как структурированный набор значений. В такой форме их гораздо проще использовать в блоках процесса для изменения бизнес-процесса в зависимости от содержимого сообщения. Впрочем, даже оставляя поле для указания спецификации пустым, в сценарии BizTalk Orchestration можно использовать некоторую информацию из сообщения. Например, строку, содержащую само сообщение, а также некоторые служебные параметры: Sender — содержит информацию об отправителе (для СОМ и MSMQ), Status - требуется только при вызове компонентов и содержит код возврата HRESULT, Exists указывает на наличие сообщения. Указав спецификацию сообщения, этот список удастся расширить. При этом становится доступной кнопка Add, посредством которой к существующему списку значений сообщения можно добавить новые (рис. 6-33).

К ,;.; DQCjment

Рис. 6-33.

Щ string string

! ,., '•

ш • •_

Указание параметров сообщения, доступных в сценарии

Для добавления к существующему списку значений сообщений новых значений используют механизм XPath, позволяющий указать какое-либо поле в сообщении XML, как это показано на рис. 6-34.

Рис. 6-34.

Выбор поля в сообщении

В результате данное поле появляется в списке доступных в окне мастера. По завершении работы мастера формируется связь между портом и блоком процесса, а также отображаются изменения на вкладке Data BizTalk Orchestration Designer. О использовании свойств сообщения рассказывалось ранее, при рассмотрении настройки условий блоков Decision и While. Данные Вкладка Data (рис. 6-35) содержит описания всех сообщений, которые используются в сценарии, а также содержит два важных элемента сценария: блок описания портов Port References и блок констант Constants. Блок Port References предназначен для описания применяемых в системе портов, кроме того, он требуется при динамической привязке блоков реализации (если соединить один из портов в этом блоке с полем сообщения, то значение этого поля будет использоваться как адрес при динамическом связывании). Блок Constants необходим для задания констант, которые используются в сценарии наравне с полями сообщений. Все блоки на вкладке данным разрешается связывать друг с другом — это равносильно присвоению значения поля одного сообщения другому. Например, если в сценарии используется два типа сообщений и при этом значения одного сообщения должны быть равны значениям другого, то соответствующие поля на вкладке данных необходимо просто соединить между собой. При этом сообщение, значения полей которого присваиваются полям другого сообщения, должно в сценарии появиться раньше.

1ЛАБА 6.

SixTafk Server Orchestration

Developer Draws Data Flow Between Message Fields

Рис. 6-35. Страница данных сценария

Исполнение сценариев В процессе исполнения сценариев BizTalk Orchestration участвуют 4 основных компонента: • откомпилированный сценарий процесса на языке XLANG; • сервис выполнения сценариев; • компоненты, использующиеся в сценарии (очереди MSMQ, СОМ-компоненты, подсистема BizTalk Messaging); • библиотека доступа к выполняющимся сценариям. Рассмотрим подробнее эти компоненты.

XLANG и сервис выполнения сценариев XLANG (произносится «сленг*) — язык, на котором описываются исполняемые сценарии подсистемы BizTalk Orchestration. Это XML-файл, созданный по определенным правилам и в соответствии с заданной схемой. В нем описаны все блоки, применяемые в сценарии, а также их соединения друг с другом.

СОВЕТ Формат файла XLANG описан на странице http:// www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm. В процессе исполнения каждый XLANG-сценарий можно временно остановить — по команде извне или когда ожидается поступление сообщения. Чтобы сохранить состояние сценария в момент остановки, а также состояния всех компонентов, используемых в сценарии, применяются механизмы замораживания (hydration) и размораживания (rehydration). Состояние сохраняется в специальной базе данных XLANG. Доступ к ней осуществляется через сконфигурированный ODBC Data Source Name (DSN). Для его настройки, а также для вспомогательных операций с базой данных предназначена дополнительная вкладка свойств СОМ+-приложения XLANG Scheduler (рис. 6-36). |. :••

.! j

| I Ч, , ; .krUi.' : Щ •:•«-!•! И М 1 -'

Рис. 6-36.

'• > ' > ' '

' *•''""'

Страница свойств сервиса выполнения сценариев

На ней предусмотрены средства для корректной остановки всех исполняющихся в данный момент сценариев (остановка приложения СОМ+ и тем более — сервиса XLANG Scheduler в некоторых случаях завершается аварийной остановкой сценариев с потерей информации).

Также на этой вкладке можно перезапустить все исполняющиеся сценарии (это иногда требуется при отладке), а также настроить базу данных, в которой предполагается сохранять состояния сценариев при длительных операциях. Хотя сценарий на языке XLANG и отличается от привычной программы на любом другом языке программирования, все же обшие принципы программирования применимы и к нему. Один из таких принципов — невозможность создания программы без стадии отладки. Сценарии XLANG отлаживать в привычном смысле слова (с установкой точек останова и пошаговым прохождением с просмотром значений переменных) невозможно, Но вот для мониторинга сценариев средство предусмотрены. Это XLANG Event Monitor, позволяющий отобразить в любой момент времени все исполняющиеся сценарии и события, которые произошли в процесс исполнения этих сценариев. Подробнее о приложении XLANG Event Monitor рассказано в главе 10 «Трекинг документов».

Библиотека доступа к выполняющимся сценариям Для программного доступа к выполняющимся сценариям разработан набор интерфейсов — IWFSystemAdmin, IWFGroupAdmin, IWFWorkflowInstance и IWFProxy. Более подробно об этих интерфейсах рассказано в главе 9 «Взаимодействие приложений с BizTalk Server 2000».

ГЛАВА 7

Описание документов и преобразований в BizTalk Server 2000 Осякий документ имеет определенную структуру: будь то кассовый чек, платежное поручение или налоговая декларация. Имеющиеся в документе поля бывают обязательными для заполнения или необязательными, цифровыми или текстовыми, то есть обладают определенными свойствами. Документальное сопровождение операций в бизнесе позволяет избежать множества ошибок, а для облегчения создания документов придуманы бланки — по сути, шаблоны документа. Если бюрократическая машина работает на полную мощность, то зачастую появление одного документа порождает множество других — например, заказ не будет выполнен без счета и поручения на склад. При этом содержимое исходящих документов определяется содержимым входящего. Существуют правила, позволяющие на основании информации входящего документа заполнить поля исходящих. BizTalk Server предоставляет средства работы с шаблонами документов, а также способы описания преобразований документов из одного шаблона в другой, что позволяет упростить документооборот. В этой главе В этой главе описаны инструменты BizTalk Server — BizTalk Editor и BizTalk Mapper. Они позволяют создавать спецификацию документа и описание преобразования документа из одного формата в другой. Также здесь рассмотрены термины и понятия, необходимые для работы с этими инструментами.

ПРИМЕЧАНИЕ Спецификации документов и описания преобразований используются в подсистемах BizTalk Messaging и Orchestration. О них подробно рассказано в главе 6 «BizTalk Server Orchestration» и главе 8 «BizTalk Server Messaging».

Описание документа Прежде всего необходимо разобраться, что такое электронный документ и что должно содержать его описание. Электронный документ — это определенным образом структурированная информация. Причем для описания структуры документа можно использовать несколько уровней абстракции. • Логический уровень. Описание документа включает информацию о логической структуре документа. Документ состоит из записей и полей, расположенных в иерархическом порядке. Записи и поля определенным образом связаны между собой — если проводить параллели с классическими реляционными базами данных, то логическая структура документа аналогична логической структуре базы данных, в которой описываются основные сущности, имеющиеся в системы, их свойства (атрибуты) и их связи друг с другом. Точно так же и логический уровень документа описывает информацию, содержащуюся в документе на уровне сущностей (записей), их свойств (полей) и их связей между собой в виде иерархии записей. Основное отличие логической структуры электронного документа от базы данных в характере связей таково: электронный документ, как правило, отличается наличием иерархии связей между записями (полями), тогда как в базах данных чаше применяется реляционная (табличная) структура и реже — иерархическая. • Физический уровень. Описание структуры документа с точки зрения типов д а н н ы х . Каждое поле и запись хранит в себе информацию определенного типа. Для некоторых типов данных можно задать дополнительные ограничения, например для строк— максимальную и минимальную длину, для чисел максимальное и минимальное значение. • Формат хранения. Документ можно сохранить в различных форматах: в виде XML-файла (extensible Markup Language),

файла с разделителями или позиционного файла. Указание о том, как хранится каждый из элементов логической структуры документа в файле это и есть описание формата хранения документа. Очевидно, что описание формата хранения документа необходимо только в том случае, если документ сохраняется не в виде XML-файла. В случае XML информация о том, как каждый из элементов логической структуры документа хранится в файле, содержится в стандарте XML, и ее нет необходимости специально описывать. Здесь необходимо некоторое отступление для того, чтобы определить термины, используемые при описании документов. Основные термины это спецификация, схема и экземпляр документа. Схема документа содержит описание логической структуры XML-документа. Существует несколько стандартов схем, Основные стандарты — DTD, XSD и XDR. Первые два это стандарты W3C, последний — собственная разработка Microsoft. Каковы же особенности каждого из них? • DTD (Document type definition) — первый появившийся стандарт для описания структуры XML-документа. Его недостатки известны — DTD-схема не является XML-документом и не содержит описания типов данных, то есть содержит сведения только о логической структуре. В W3C разрабатывается стандарт DT4DTD (Datatypes for DTDs), но результата пока нет, созданы лишь предварительные версии. • XSD (XML Schema Definition)— разрабатывающийся W3C стандарт, как полагают, решит многие проблемы, характерные для DTD. Работа над этим стандартом скоро будет завершена, и Microsoft сразу же собирается взять его за основу для своих продуктов. Это заявление подтверждается тем фактом, что предварительные версии Microsoft XML Parser 4.0, а также платформа .Net уже поддерживают XSD. • XDR (XML Data Reduce) — стандарт, представленный Microsoft и используемый в Microsoft XML Parser 3.0. Позволяет описывать типы данных. XDR-схема сама является XML документом. Данный стандарт предложен Microsoft как промежуточный, до выхода окончательной версии XSD.

История стандартов описания XML

Почему для описания XML-документов создано столько стандартов? Причина в том, что первый из них — DTD был слишком неудобен и нефункционален. Сразу после выхода стандарта XML 1.0 консорциум W3C начал разработку нового стандарта XSD, в котором предполагалось исправить все недостатки DTD. Но время шло, стандарт все не появлялся, а необходимость в нем все росла. И тогда Microsoft одновременно с выпуском Internet Explorer 5.0 представила свой вариант описания схем XML-документа под названием XDR. Несмотря на существование собственного стандарта многие продукты Microsoft, в том числе и BizTalk Server совместимы с последней редакцией XSD. Кроме того, Microsoft обещает обеспечить миграцию своих продуктов с XDR на XSD, как только появится его окончательный вариант. Поскольку для XML-документа нет необходимости описывать формат хранения, ни один из стандартов XML схем не описывает структуру документа на этом уровне. Поэтому, при использовании документов не XML-формата для описания формата хранения необходимо расширить схему документа. Поскольку XDRсхема позволяет расширить структуру нестандартными свойствами записей и полей документа, можно сделать это, добавив информацию о формате хранения. В BizTalk Server в схему документа добавляются дополнительные свойства, необходимые для обработки документа. Исходя из этого, схема документа — это только его логическое описание, недостаточное для BizTalk Server. А спецификация документа — это схема с добавлением необходимой информации о формате хранения документа, а также некой дополнительной информации BizTalk Server, например, о маршрутизации документа. На основании спецификации создается экземпляр документа.

BizTalk Editor Поскольку разработкой спецификаций документов могут заниматься люди, не имеющие большого опыта и знаний в создании XML-схем, в комплект поставки BizTalk Server входит утилита

BizTalk Editor, предназначенная как раз тем, кто не знает ничего (или почти ничего) о XML и о XML-схемах, но собирается создать спецификацию. BizTalk Editor — классическое приложение Windows SDI (Single Document Interface). Окно приложения состоит из трех подокон (рис. 7-1).

Рис. 7-1. Окно приложения BizTalk Editor

В левой части отображается иерархическая структура документа. Документ представляется в виде записей (Record) и полей (Field). Запись обозначается значком листочка с горизонтальными чертами, а поле — с вертикальными. В правой части расположен набор страниц свойств с более подробным описанием выделенного элемента (поля или записи); Declaration, Reference, Parse, Namespace, Dictionary, Code List. (Подробнее об этих страницах рассказано далее.) Нижнюю часть экрана занимают страницы Output и Warning, в которых, согласно принятому в средах разработки правилу, отображается выводимая по командам приложения информация и ошибки, найденные при проверке разрабатываемой спецификации. Необходимо отметить, что то, что BizTalk Editor называет

предупреждением (warning), на самом деле необходимо рассматривать как ошибку, поскольку спецификация хотя бы с одним предупреждением ошибочна и се нельзя использовать при работе BizTalk Server,

Создание спецификации документа При создании спецификации документа наиболее часто используется принцип проектирования «сверху вниз», то есть сначала разрабатывается логическая структура документа, затем описывается физическая структура и далее — формат хранения документа. Применение BizTalk Server удлиняет эту цепочку еще на один этап — добавление информации, используемой при транспортировке документа, а также данных, необходимых для BizTalk Server.

Логическая структура документа BizTalk Editor предлагает отказаться от принятых в XML понятий «элемент» (element) и «атрибут» (attribute), заменяя их на соответственно «запись» (record) и «поле» (field). Это позволяет, во-первых, показать, что разрабатываемая BizTalk спецификация не является XML-схемой в чистом виде, и, во-вторых, использовать терминологию, принятую при проектировании баз данных. При создании спецификации документа необходимо решить, какие свойства документа считаются полями, а какие — записями. Четких правил на этот счет нет. Наиболее общий принцип, который можно выделить, таков: то, что в документе является сущностью, необходимо описывать как запись, а то, что является свойствами сущности, — как поле. При этом необходимо помнить, что только запись может являться контейнером для других записей и полей. Зачастую одна и та же запись встречается в документе в нескольких местах. В этом случае BizTalk Editor воспринимает эти записи как одну и синхронизирует свойства. Особенный случай — включение записи в саму себя, Ее называют циклической ссылкой (cyclic reference) и обозначают в спецификации специальным значком (рис. 7-2), А в свойствах записи появляется дополнительное свойство — Cycle Count, обозначающее максимальное количество циклов в данной записи.

.Nsme

Cfdrftetwd

Type Model

i . . • ; Closed

Order Cyc\s Count

' 7

ГнГч( j-А'иглх*}

зг Рис. 7-2.

,..., ,-

.. ,

.

1 .!T:'I

Значок циклической записи

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

Формат хранения Документ представляют не только в виде XML-файла (в котором формат хранения задается стандартом), но и в виде плоского файла (flat file), который чаще всего соответствует одному из стандартов — EDIFACT или Х12. Однако иногда стандарт на формат хранения плоского файла отсутствует, в этом случае необходимо дать подробное указание BizTalk Server, каким образом понимать входящий плоский файл и каким образом отправлять исходящий, то есть подробно описать формат хранения. Для этого в спецификацию документа добавляется информация о структуре входящего или исходящего файла. Прежде всего необходимо разделить плоские файлы на два основных типа позиционный плоский файл (positional flat file) и плоский файл с разделителями (delimitered flat file). Проще всего разницу между ними можно прояснить на примере: Иванов,Иван,Иванович, 40 Петров,Петр,Петрович,37 Иванов Петров

Иван Петр

Иванович Петрович

40 37

Часть 11, Microsoft BizTalk Saver 2000

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

Escape-символ Для файлов с разделителями возникает трудность, когда значение поля должно содержать символ или последовательность символов, используемую как разделитель. В этом случае необходимо использовать так называемый escape-символ. Тот, кто хотя бы немного знаком с программированием, наверняка вспомнит, что в языке С и C++ прежде чем вставить в строковый литерал один из зарезервированных символов, таких, как, например, «двойные кавычки», необходимо вставить escape-символ — «обратная косая черта». Вот так: "Это слово в кавычках: \"Слово в кавычках\""

В этом случае кавычки являются зарезервированным символом, то есть их использование внутри строки запрещено. Если же необходимо вставить такой зарезервированный символ в строку, его предваряют обратной наклонной чертой. Wrap-символ Описанная выше проблема с зарезервированными символами решается использованием символа окружения (wrap character). Предположим, в файл с разделителями необходимо занести значение поля Фамилия Имя Отчество следующим образом (цифра 40 это значение следующего поля):

Иванов, Иван Иванович, 40 Здесь запятая — не разделитель полей, а зарезервированный символ в значении поля. Оно будет воспринято как два значения, следующих оно за другим. Для того чтобы интерпретировать значение поля как одно целое, можно использовать символ окружения (здесь символом окружения служат кавычки): "Иванов, Иван Иванович", 40

Выравнивание В позиционном файле для значения каждого поля выделяется фиксированное пространство. Если длина значения поля больше, не поместившаяся часть отсекается. Выбрав тип выравнивания, можно указать, какую часть значения надо отсечь — правую или левую. Pad-символ В позиционных файлах необходимо чем-то заполнять пустые места между окончанием значения предыдущего поля и началом следующего. Для этого используется символ заполнения (pad character). В приведенном выше примере таким символом стал пробел, но им может быть и любой другой печатный символ, например звездочка, как показано в следующем примере: Иванов****Иван***Иванович***40 Петров****Петр**«Петрович**«37 Средство BizTalk Editor для описания плоских файлов позволяет описать множество различных форматов представления данных. Стоит обратить дополнительное внимание на тщательное тестирование созданных спецификаций как с соответствующими спецификациями входными файлами, так и с заведомо ошибочными. Несмотря на достаточно широкие возможности, иногда используемый формат настолько сложен, что его не удается описать средствами BizTalk Editor. В этом случае выход один — написать собственные компоненты входных и выходных преобразователей, выполняющих преобразование входного файла в нестандартном формате в XML и обратное преобразование выходного XML файла в нестандартный формат. О создании собственных входных и выходных преобразователей рассказано в главе 12 «Расширение возможностей BizTalk Server 2000». 5-2241

Часть Н. Microsoft BizTalk Server

Использование BizTalk Editor О пользовательском интерфейсе BizTalk Editor рассказывалось в предыдущих разделах, этот же раздел посвящен вопросам создания спецификаций документов его средствами. При описании спецификации документа в Bi/Talk Editor свойства полей, записей и документа в целом указываются на шести вкладках (рис. 7-3): • Declaration — свойства записей и полей, описывающие тип данных поля или записи; • Reference — свойства записей и полей, а также самого документа: • Parse — название говорит само за себя — свойства физического формата представления документа; • Namespace — применяемые в документе пространства имен; • Dictionary — свойства документа для маршрутизации; • Code List — свойства документов EDI.

Рис. 7-3.

Вкладки BizTalk Editor

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

Вкладка Declaration На вкладке Declaration сгруппированы свойства записей и полей описывающие тип элемента схемы (таблица 7-1). Таблица 7-1. Свойство

Вкладка Declaration Назначение

Общие свойства для записей и полей Name

Имя

Description

Текстовое описание

Таблица 7-1.

продолжение

Свойства ТУре

Назначение Для записи это свойство всегда равно значению Element, а для полей можно выбирать между Element и Attribute. Поле с типом Element похоже в документе на запись, но не может содержать других записей. Например, здесь у поля FullName тип Attribute: А здесь — Element:

Fu11Name_1

Model

Это свойство присутствует у записей и полей с типом Element. Имеет значения Open и Close. Запись или поле с типом Open может содержать в себе записи и элементы, не соответствующие описанным, а запись с типом Close — нет

Content

• Element Only — запись может содержать в себе только другие записи; • Empty — запись не содержит ничего: • Text Only — запись может содержать в себе только тест. Доступно и для полей с типом Element, но только со значением Text Only

Свойства записей Order

Cycle count

• One — запись может содержать только один из под эле ментов: • Sequence — запись должна содержать все подэлементы и только в приведенном порядке; • Many — запись может содержать один или несколько подэлементов в любом порядке и в любом количестве Разрешается устанавливать только для записей не верхнего уровня в том случае, если запись содержит саму себя. Содержит максимальное число повторений записи ннутри себя см. след. стр.

rosoft BizTsik Server Таблица 7-1.

продолжение

Свойство

Назначение

Свойства полей Data type

Тип данных поля. Соответствует списку типов данных стандарта XDR

Data Type Values

Для типа данных Enumeration содержит список значений перечисления, разделенных пробелом

Minimum Length

Для строковых и бинарных типов данных содержит минимальную длину

Maximum Length

Для строковых и бинарных типов данных содержит максимальную длину

Default \klue

Значение поля по умолчанию

Список свойств полей и записей на вкладках Dictionary и Reference можно расширять. Для этого в свободной записи в таблице необходимо указать имя свойства и значение. Некоторые свойства присутствуют в раскрывающемся списке. Они используются, например, при связывании спецификации BizTalk с базой данных SQL Server. Подробнее об этом в главе 13 «Возможности SQL Server 2000».

Вкладка Reference Вкладка Reference предназначена для установки свойств документов, записей и полей описывающих их использование в документе {таблица 7-2). Таблица 7-2. Вкладка Reference Свойство

Назначение

Свойства корневой записи Specification Name

Название спецификации

Standard

Формат документа: •

XML; • Х12; • EDI FACT; • CUSTOM

Standards Version

Версия стандарта (используется для документов формата EDIFACT и Х12)

Document Type

Тип документа (используется для документов формата EDIFACT и Х12)

Таблица 7-2.

продолжение

Свойство

Назначение

Version

Версия документа (используется для документов формата ED1FACT и Х12)

Default Record Delimiter

Разделитель записей по умолчанию (кроме формата XML)

Default Field Delimiter

Разделитель полей по умолчанию (кроме формата XML)

Default Subfield Delimiter

Разделитель подполей по умолчанию (кроме формата XML)

Default Escape Character

Escape-символ по умолчанию (кроме формата ХМ L)

Code Page

Кодовая страница документа (только для формата CUSTOM)

Receipt

Поле, в котором можно установить, что данный документ является квитанцией (Receipt). Подробнее о квитанциях рассказано в главе 9 «Взаимодействие приложений с BizTalk Server 2000»

Envelope

Поле, в котором можно установить, что данная спецификация — это спецификация конверта

Target Namespace

Поле позволяет установить пространство имен документа в случае использования BizTalk Framework — совместимого обмена сообщениями

Свойства записей Minimum Occurrences

Минимальное количество записей данного типа. Принимает значение 0 или 1

Maximum Occurrences

Максимальное количество записей данного типа. Принимает значение 1 или *, т. е. не меньше одной или неограниченно

Свойства полей Required

Считается ли данное поле обязательным

Start Position

Начальная позиция поля в записи (для позипионных записей плоских файлов)

End Position

Конечная позиция поля в записи (для позиционных записей плоских файлов)

Вкладка Parse Вкладка Parse предназначена для установки свойств спецификаций документов в форматах EDIFACT, X12 и CUSTOM. Для спецификаций документов XML эта вкладка не заполняется. Для плоских файлов и документов EDIFACT и Х12 набор свойств этой вкладки различается: какие-то свойства присутствуют всегда, независимо от формата, а какие-то — только для определенных форматов,

Вкладка Namespace На вкладке Namespace показаны используемые в документе пространства имен (namespace) XML.

Вкладка Dictionary Вкладка Dictionary предназначена для установки свойств самомаршрутизирующихся документов. Подробнее о работе с такими документами рассказано в главе 9 «Взаимодействие приложений с BizTalk Server 2000», Для того чтобы документ стал самомаршрутизирующимся, необходимо, чтобы в нем содержалась информация, показывающая, кто является источником и приемником данного документа, а также как называется документ. На вкладке расположены свойства, хранящие в себе ссылку в соответствии со стандартом XPath на поле или запись в документе. Чтобы установить какое либо из свойств вкладки, необходимо в дереве представления структуры документа выделить какуюлибо запись или поле и пометить флажком соответствующее свойство вкладки. При этом в столбце Node Path вкладки отобразится путь XPath к данной записи или полю. Свойство Document Container Node может ссылаться только на запись, остальные свойства — только на поле. В поля Source Type и Destination Type заносится строковое значение типа идентификатора в соответствии с набором идентификаторов в соответствующем списке свойств объекта организации схемы соединения BizTalk Messaging (рис. 7-4). Подробнее об идентификаторах организаций рассказано в главе 8 «BizTalk Server Messaging» В таблице 7-3 описаны все свойства с данной вкладки.

Bunctesverband de Bank Identifier Cods KTNel (Korea Trade Nelwcik Savices] UPLI (Universal Postal Union] ODETTE (Qpgamzalion for Data Exchange through Tele Trare SCAC [Standard Cariier Alpha CiJde) ECA [Eleciranic Commerce Australia TELEBOX -ЮС IieJichs Teietoni] i

Г SPaij^iW

Рис. 7-4.

Окно выбора типа идентификатора

Таблица 7-3.

Вкладка Dictionary

Свойство Document Container Node

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

Document Node

Имя документа

Source Type

Тип идентификатора источника документа

Source Value

Значение идентификатора выбранного типа источника документа

Destination Type

Тип идентификатора приемника документа

Destination Value

Значение идентификатора выбранного типа приемника документа

Для документов в формате EDI указывать эти поля на вкладке Dictionary нет необходимости, так как размещение этих полей в документе указывается в стандарте, описывающем соответствующий формат.

Вкладка Code List На вкладке Code List для полей в спецификациях документов EDIFACT и Х12 можно пометить флаг, обозначающий, что в данном поле документа содержится определенная информация, соответствующая стандарту EDIFACT или Х12. Чтобы установить соответствие значения соответствующего поля коду, надо пометить соответствующий флажок на вкладке.

Часть 11. Microsoft BizTalk Server 20CO

Работа с документами BizTalk Editor предоставляет возможность создания экземпляра документа в соответствии со спецификацией. Правда, документ, независимо от формата, установленного в спецификации, создается в формате XML. Также имеется средство проверки экземпляра документа на соответствие спецификации. Ограничение те же — документ должен быть представлен только в формате XML. Для того чтобы проверить создание документа в необходимом (отличном от XML) формате хранения, придется использовать тестовые схемы соединения, порты и каналы,

Работа со схемами Как уже говорилось ранее, спецификация документа BizTalk не является схемой документа, поскольку содержит дополнительные, свойства, которых нет в схеме. Но при описании документа для использования не в BizTalk Server применяются другие стандарты — XDR, DTD и т. д. Даже в библиотеке схем (www.biztalk.org) хранятся не спецификации документов BizTalk Server, a их XDR-схемы. В BizTalk Editor имеются средства экспорта и импорта спецификации документа. Экспорт можно осуществить только в XDRсхему. Затем созданную XDR-схему преобразуют в XSD с помощью поставляемой в составе BizTalk Server SDK утилиты XSLTпреобразования. Она находится в каталоге \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\XSDConverter на диске, где установлен BizTalk Server.

Docjrnenl XDR Scheme Type Definition

Рис. 7-5.

Диалоговое окно выбора типа импорта в BizTalk Editor

Импорт документа разрешен из XDR-схемы и из DTD-схемы. Также предусмотрено создание спецификации документа на основе экземпляра файла. На рис. 7-5 показано диалоговое окно выбора типа импорта в BizTalk Editor,

Преобразование документов Рассмотрим последовательность обработки файла внутри подсистемы BizTalk Messaging (рис. 7-6).

Плоский файл Спецификация документа Выходной преобразователь (Serializer)

Входной преобразователь (Parser) 1

Преобразование (Map)

XML

Рис. 7-6. Последовательность обработки файла внутри подсистемы BizTalk Messaging

Документ попадает в BizTalk Server в одном из поддерживаемых форматов (XML, EDIFACT X 1 2 или плоский файл). Первая стадия, которую проходит документ, — трансформация документа во входном преобразователе из его собственного формата в промежуточный формат XML, который является внутренним форматом представления документов BizTalk. Также на этой стадии выполняется проверка соответствия документа его спецификации. В случае если документ поступает сразу в формате XML, начальная трансформация не выполняется, документ только про-

Часть II, Microsoft BizTalk Server

веряется на соответствие стандарту XML и спецификации. Как уже говорилось, если необходимо отправить в BizTalk Server документ в формате, не поддерживаемом BizTalk, возможно реализовать собственный входной преобразователь. Следующая стадия — преобразование документа из одной логической структуры в другую. При этом преобразуется не формат хранения, а логическая структура записей и полей документа. Это действие осуществляется в канале подсистемы BizTalk Messaging. Указания, как преобразовывать документ содержатся в описании преобразования (тар). Преобразование в BizTalk Server основано на механизме XSLT (Extensible Stylesheet Language Transformation). Этот стандартный механизм, позволяющий описать преобразование XML-документа, создавался для генерирования HTML-страничек из XML. Впоследствии область применения XSLT значительно расширилась, и сейчас он используется для любых преобразований XML. В BizTalk Server XSLT применяется для внутренних преобразований промежуточных XML-доку ментов. Схемы XSLT достаточно сложны для понимания и создания. Для того чтобы пользоваться этим механизмом, не вникая в тонкости XSLT, в BizTalk Server предусмотрен специальный инструмент для создания описаний преобразования — BizTalk Mapper.

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

Поле в центре экрана предназначено для соединения полей и записей исходной и результирующей спецификации. Причем. соединяя какую либо часть спецификации слева с какой-либо частью спецификации справа, можно указать, что при преобразовании значение данного поля или записи входящего документа перейдет в соответствующее поле или запись исходящего. Проще всего это прояснить на примере. Средствами BizTalk Editor создадим две спецификации простых XML-документов, затем с помощью BizTalk Mapper опишем преобразования одного документа в другой и проверим это преобразование на практике. На рис. 7-7 показана спецификация входного документа. JB'BizTalk Editor - 1пЬпигнЮ

Рис. 7-7,

Спецификация входного документа

Стоит обратить внимание на то, что на вкладке Output приведено содержимое документа (которое создастся командой Create XML Instance из меню Tools), соответствующего спецификации. При этом записей типа Record2 две — такое количество записей BizTalk Editor сгенерировал для тестового документа потому, что в свойствах этой записи на вкладке Reference указано, что максимальное количество записей этого типа больше 1 (т. е. в поле Maximum Occurrences стоит значение «*»). В таких случаях для тестового примера документа BizTalk Editor создаст две записи.

Часть II. Microsoft BizTalk Saver 20nO

Спецификация второго документа несколько отличается по структуре (рис. 7-8). Как и в первой спецификации, запись Record имеет значение «*» (в поле Maximum Occurrences). ЗЩЩйВ' iv Т Ш

>'

-iecord F-;e;a="Field_l" По dl="Fieldl_l'

«Record Fieid="Fleld_2" Fieldl=°Fieldl__2" FielrJ2="Field2_2" />

Fie!dS="Field2_l" />

Рис. 7-8. Спецификация второго входного документа

Для простоты примера все поля в этих спецификациях имеют строковый тип данных (это указано на вкладке Declaration). Теперь с помощью BizTalk Mapper создадим описание преобразования. Для этого в BizTalk Mapper создадим новую спецификацию (командой меню или кнопкой на панели инструментов). BizTalk Mapper при этом предложит вначале выбрать спецификации входящего и исходящего документов в двух последовательно появляющихся одинаковых окнах (рис. 7-9) с разными заголовками Select Source Specification Тире и Select Destination Specification Тире. Как показано на рис. 7-9, источником спецификаций документов могут служить локальные диски, файлы из хранилища WebDAV и стандартные, поставляемые с BizTalk Server шаблоны спецификаций.

Select Sourie sjrecPftcatien iype

'-• Local File;•

Рис. 7-9.

Terrplatei

WebDAV Files

Окно выбора типа спецификации

Для примера выберем файлы InboundDocSpec.xml и OutboundDocSpec.xml, созданные в BizTalk Editor. Результат этой операции — BizTalk Mapper с открытыми спецификациями и не связанными пока друг с другом полями (рис. 7-10).

Рис. 7-10. BizTalk Mapper с открытыми спецификациями и не связанными пока друг с другом полями

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

Часть SI, Microsoft BizTalk Server

шить его через поле связывания в центре экрана и отпустить на нужном поле в спецификации исходящего документа. В результате образуется связь между двумя полями в спецификациях документов. Чтобы удалить созданную связь, надо выделить ее в поле связывания (она в этом случае окрашивается в синий цвет) и нажать кнопку Del. Создадим несколько связей между полями и посмотрим на результат этих операций. На рис. 7-11 видно, что не обязательно связывать каждое поле с каждым, можно некоторые поля не связывать (они остаются пустыми), а несколько других связать с одним и тем же во входящем документе.

Рис. 7-11.

Связи между полями

Чтобы проверить работу такого преобразования, в BizTalk Mapper предусмотрено тестирование. При этом создается тестовый экземпляр входящего документа (такой же, как и в BizTalk Editor при выполнении команды Create XML Instance), этот документ преобразуется в соответствии с описанием, и его результат попадает в окно Output. Чтобы преобразование сделать более наглядным, можно задать тестовые значения полей входящего документа на вкладке Values (рис. 7-12). В этом случае генерируемый тестовый экземпляр документа будет содержать именно эти данные.

ГЛАВА 7.

Описание документа и преобразований в BsxTafk Server 2000

-t

На вкладке расположено два поля ввода: Source test value, в которое можно занести тестовое значение для выделенного поля во входящем документе, и Destination constant value, предназначенное для присвоения полям в исходящем документе константных значений. Ограничение на изменение тестовых значений таково: если какая-то запись встречается в документе несколько раз (см. запись Record2 входящего документа и запись Record исходящего, рис. 7-10), невозможно указать число вхождений этой записи для тестового документа (оно всегда будет равно 2), а также разные значения полей в различных экземплярах этой записи. ?.? BizTalb Mapper - Мар.ит1 *

Рис. 7-12. Задание тестовых значений полей входящего документа на вкладке Values

После указания тестовых значений описание преобразования можно протестировать. Результат преобразования — исходящий документ — показан на вкладке Output (рис. 7-13). Произведенные преобразования очень просты, хотя даже программирование без использования BizTalk Server и XSLT заняло бы много времени. BizTalk Mapper позволяет в процессе преобразования производить и достаточно сложные манипуляции с данными. Для этого в BizTalk Mapper входят так называемые функтоиды (functoid) — описания сложных преобразований данных, которые могут выполняться при преобразовании документов.

Часть П. Microsoft SizTalk Sesx'er 2(300

i 1 < . f i. i °:Record Fi=ld="TecTBoeoe значение поля 1 в записи 2* r ifjldl="TecTBOBoe значение поля 2 в записи 2" Field?---'Тесгвовое значение поля 2 в записи 2 ' /:= 1 «Record Fie'd="TECTBOBoe значение поля 1 в записи 2' 1 ;l FeldJ.='TecTBOBoe значение поля 2 в записи 2 ' i&id2-="TeciBOBDe значение поля 2 в записи 2 /;• 1 ^Record/ Fieldl="'TecTBDBoe значение поля в записи' /> ^Rec.fjrd"! Fie!dl='Тествовов значение поля 1 в записи 1" Field2""KoHCTaHTHoe значение" ,'-,-•

Рис. 7-13. Результат преобразования (исходящий документ) показан на вкладке Output

Функтоиды Доступные для использования функтоиды расположены на палитре, которую можно открыть с панели инструментов или из меню. Это окно с набором вкладок, на которых расположены символы, обозначающие функтоиды (рис, 7-14). Для использования функтоид необходимо перетащить мышью с палитры на поле связывания, расположенное в центре BizTalk Mapper. Затем необходимо соединить вход функтоида и необходимые для преобразования поля или записи из спецификации исходного документа (так же, как и при связывании полей и записей между собой), а выход функтоида соединить с полем или записью в спецификации исходящего документа или другим функтоидом (для выполнения каскадных преобразований). Рассмотрим эти операции на примере.

Рис. 7-14.

Палитра функлоидов

Допустим, при преобразовании документа необходимо в одно из полей исходящего документа записать склеенные между собой поля входяшего документа (произвести конкатенацию строк). Предположим, имя и фамилия во входящем документе записываются в два равных поля, а в исходящем документе — в одно. Например, из документа: необходимо получить документ: ,>! .

Рис. 8-6.

Окно параметров BizTalk Messaging Manager

В окне можно задать:

• максимальное число элементов, возвращаемых при поиске (увеличение его с некоторых случаях вызывает падение производительности приложения); • имя компьютера, на котором находится управляемый BizTalk Messaging Manager BizTalk Server; • тайм-аут ожидания ответа от сервера — при плохих каналах связи стоит увеличить это значение. Кроме того, здесь имеется флажок, установив который, можно включить запуск диалогового окна при запуске приложения (рис. 8-7).

Рис. 8-7.

Стартовое диалоговое окно BizTalk Messaging Manager

Объектная модель конфигурирования подсистемы BizTalk Messaging Если пользовательский интерфейс приложения BizTalk Messaging Manager no каким-то причинам не удобен или необходимо программно конфигурировать подсистему BizTalk Messaging — на помощь приходит объектная модель BizTalk Messaging — BizTalk Messaging Configuration Object Model.

Она позволяет делать все те же операции, что и интерфейс BizTalk Messaging Manager, и даже больше, BizTalk Messaging Manager при конфигурировании использует ту же самую библиотеку BizTalk Messaging Configuration Object Model.

Архитектура библиотеки конфигурирования Библиотека конфигурирования управляет базой данных, хранящей информацию обо всех элементах BizTalk Messaging; она построена на базе интерфейса ADO (Active Data Objects). Вся логика создания элементов конфигурации реализована в хранимых процедурах базы данных, позволяющих читать и изменять информацию в таблицах, храняших свойства всех элементов. Архитектура библиотеки конфигурирования показана на рис. 8-8.

BizTalk Messaging Configuration Object Model

База данных конфигурационной информации BizTalk Messaging InterchangeBTM

Рис. 8-8.

Архитектура библиотеки конфигурирования

Объекты библиотеки Объектная модель конфигурирования достаточно проста — полгора десятка объектов, которые можно разделить на два типа объекты, представляющие свойства объектов схемы соединения BizTalk Messaging, и вспомогательные объекты, используемые при конфигурировании, ВНИМАНИЕ! Объекты схемы соединения и объекты библиотеки конфигурирования — это не одно и тоже. В первом случае это условное понятие, обозначающее описывающие элементы, из которых состоит схема взаимодействия BizTalk Messaging, а во втором — обыкновенные СОМ-объекты, реализующие СОМ-интерфейсы. Средствами СОМ-объектов библиотеки конфигурирования можно создавать и манипулировать объектами схемы взаимодействия. Далее при употреблении термина «объект» для обозначения разных сущностей будет уточняться, что имеется в виду: СОМ-объект или объект библиотеки конфигурирования и объект схемы соединения.

Объекты конфигурирования В таблице 8-2 описаны объекты схемы соединения BizTalk Messaging и соответствующие им СОМ-объекты библиотеки конфигурирования, Таблица 8-2. Объекты схемы соединения BizTalk Messaging и объекты библиотеки конфигурирования Элемент конфигурационной структуры BizTalk Messaging

Объест библиотеки конфигурирования

Описание документа (Document Definition)

BizTalkDocurnent

Канал (Channel)

BizTalkChannel

Порт (Port)

BizTalkPort

Список рассылки (Distribution List)

BizTalkPortGroup

Организация (Organization)

BizTalk Organization

Приложение (Application) Конверт (Envelope)

BizTalkOrganization BizTalkEnvelope

Все объекты, перечисленные в правом столбце, реализуют интерфейс IBizTalkBase.

Интерфейс IBizTalkBase Методы интерфейса IBizTalkBase реализуют все СОМ-объекты, представляющие собой объекты схемы соединения BizTalk Messaging. В интерфейсе IBizTalkBase сгруппированы свойства и методы, предназначенные для работы с объектами, сохраненными в базе данных. При работе с объектами в базе данных создается копия всех свойств объекта в оперативной памяти, эти свойства меняются, и только после этого объект сохраняется в базе данных. Таким образом, изменение свойств объекта выполняется не непосредственно в базе данных, а в копии объекта в памяти. А значит, для изменения свойств объекта необходимо реализовать следующую последовательность действий: • считать свойства объекта из базы данных в оперативную память (создать копию объекта в памяти) по его имени или числовому идентификатору; • изменить свойства копии объекта в памяти; • сохранить изменения в базу данных. Необходимые для выполнения вспомогательных операций методы и свойства (таблицы 8-3 и 8-4) сгруппированы в отдельном интерфейсе IBizTalkBase. Помимо них интерфейс IBizTalkBase позволяет создать новый и удалить существующий объект в базе данных. Таблица 8-3.

Имя

Свойства интерфейса IBizTalkBase

DateModified

Тип String

Описание Дата и время последнего изменения информации об объекте в базе данных

Handle

Long

Числовой идентификатор объекта. Доступно только для чтения

Name

String

Строковое имя объекта

Таблица 8-4.

Методы интерфейса IBizTalkBase

Имя Clear

Описание Очищение копии объекта в памяти. Все свойства объекта принимают значения по умолчанию

Create

Создание объекта в базе данных в соответствии со значениями свойств в копии объекта см. след. стр.

Таблица 8-4.

продолжение

Имя Load

Описание Создание копии объекта с заданным идентификатором (см. свойство Handle) из базы данных в оперативной памяти

LoadByName

Создание копии объекта с заданным именем (см. свойство Name) из базы данных в оперативной памяти

Remove

Удаление объекта из базы данных

Save

Сохранение объекта в базе данных

Общие объекты Основным объектом библиотеки является BizTalkConfig. Это единственный объект библиотеки, экземпляр которого можно создать. Ссылки на все остальные объекты удается только получить через вызовы методов и свойств объекта BizTalkConfig (таблица 8-5) и других объектов. Таким образом, любая работа с библиотекой конфигурирования BizTalk Messaging начинается с создания объекта BizTalkConfig и получения ссылки на него: Dim oBizTalkConfig As BTSObjectModelLib,BizTalkConfig Set oBizTalkConfig = New BTSObjectModelLib.BizTalkConfig Таблица 8-5.

Свойства объекта BizTalkConfig

Имя

Т'И:'

Certificates

Recordset

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

Channels

Recordset

Documents

Recordset

Возвращает объект Recordset, содержащий информацию о каналах Возвращает объект Recordset, содержащий информацию об описаниях документов

Envelopes

Recordset

Описание

Возвращает объект Recordset, содержащий информацию о конвертах

Таблица 8-5.

продолжение

Имя

1иП

Описание

Organizations

Recordset

Возвращает объект Recordset, содержащий информацию об организациях

PortGroups

Recordset

Возвращает объект Recordset, содержащий информацию о списках рассылки

Ports

Recordset

Возвращает объект Recordset, содержащий информацию о портах

Какая информация содержится в объектах Recordset, возвращаемых свойствами BizTalkConfig? Ответ на этот вопрос можно получить, проведя несложный эксперимент: ' Создание и получение ссылки на объект BizTalkConfig Dim oBizTalkConfig As BTSObjectModelLio.BizTalkConfig Set oBizTalkConfig = New BTSObjectModelLib.BizTalkConfig ' Ссылка на объект Recordset библиотеки ADO Dim oRS As ADODB.Recordset Din sDir As String sDir = "D:\Temp\" ' Получение списка всех сертификатов Set oRS = oBizTalkConfig.Certificates(BIZTALK,STORE_TYPE_BIZTALK,_ BIZTALK_USAGE_TYPE_BOTH, " " ) ' Сохранение полученного объекта Recordset в XML-файле oRS.Save sDir & "Certificates.xml", adPersistXHL 1 Получение и сохранение списка каналов Set oRS = oBizTalkConfig.Channels oRS.Save sDir 4 "Channels.xml", adPersistXML

' Получение и сохранение списка документов Set oRS = oBizTalkConfig.Documents oRS.Save sDir 4 "Documents.xml", adPersistXHL ' Получение и сохранение списка конвертов Set oRS = oBizTalkConfig.Envelopes oRS.Save sDir & "Envelopes.xml", adPersistXML

' Получение и сохранение списка организаций Set oRS = oBizTalkConfig.Organizations oRS.Save sDir & "Organizations.xml", adPersistXML 1 Получение и сохранение списка списков рассылки Set oRS = oBizTalkConfig,PortGroups oRS.Save sDir & "PortGroups.xml", adPersistXML 1 Получение и сохранение списка портов Set oRS = oBizTalkConfig.Ports oRS.Save s3ir & "Ports.xml", adPersistXML

Таким образом получают все свойства объекта BizTalkConfig, а затем сохраняют их в XML-файл с помощью библиотеки ADO. На рис. 8-9 показан один из шести созданных в этом примере файлов, на котором отображен список каналов подсистемы BizTalk Messaging.

TBstDo£X/Ou ip.it Do v4-; F-"--'|pQrtl6noD4 >TeslPart.f /¥•!(•*•> -ih- Го ;. tujN^i -'vulr.f. jtrs.it ч-м-- .' -"- 1'

'r.-Home Organization.. ,л-з и-!? £ •r="IAppl300D2"-= Destination--' •'•^.;;:!Hnme Organization -

Рис. 8-11. Просмотр средствами BizTalk Configuration Assistant свойства одного, нескольких или всех объектов схемы взаимодействия в виде XML-файла -

' «I port corJigurabon lei Pall 60004 SB ас! = DeatedaeeirConTrit-ce [JicUorary"! del Filwem* - "We tKJ \-en-,p'Oes(ina!io-,\Do

Set did • nolhtig channel 5ave

Jj

•

Рис. 8-12. Просмотр средствами BizTalk Configuration Assistant свойства одного, нескольких или всех объектов схемы взаимодействия в виде уже преобразованного сценария VBScript Кроме того, разрешается выполнить экспотр и импорт конфигурационной информации (рис. 8-13).

Рис. 8-13. Средства для экспорта и импорта конфигурации подсистемы BizTalk Messaging Использование объектной модели Для использования библиотеки конфигурирования BizTalk Messaging в среде Visual Basic 6.0 необходимо подключить ее в ссылках проекта (References), как показано на рис. 8-14.

HrJpsr COf Canponer: 1 .С Type LRI №5 RAD US Prolool ] .0 Type Librarv ill -) VldeoS-A VSFiexGrid 7,0 ( . :ДВМ*пэдн 1.0 Type library . aboutloek 1.0 T-jpe Library •^ourlcw**x 1.0 Typelijrary •ye OS. П5 Ext

Рис. 8-14. Подключение библиотеки конфигурирования BizTalk Messaging в ссылках (References) Для доступа к любому типу объектов необходимо создать объект типа BizTalkConfig, содержащий методы и свойства, которые позволят как получить уже существующий объект любого типа, так и создать новый.

Создание схемы взаимодействия В этом разделе будет рассмотрено создание объектов схемы взаимодействия BizTalk Messaging с помощью пользовательского

интерфейса BizTalk Messaging Manager — вручную и с использованием библиотеки конфигурирования BizTalk Messaging — программно, на языке Visual Basic.

Использование BizTalk Messaging Manager Сначала рассмотрим последовательность действий при создании объектов подсистемы BizTalk Messaging с помощью приложения BizTalk Messaging Manager.

Создание описания документа в BizTalk Messaging Manager Перед созданием объекта описания документа в BizTalk Messaging Manager необходимо создать описание документа в BizTalk Editor. После этого можно приступать к созданию объекта описания документа. Для этого в меню File/New необходимо выбрать пункт Document Definition. Появится первое окно мастера создания описания документов (рис. 8-15).

Рис. 8-15.

Первое окно мастера создания описания документов

Для создания объекта описания документа в BizTalk Messaging Manager необходимо выполнить следующие действия.

Следует указать ссылку на спецификацию документа (не обязательно) (рис. 8-16). .,!PJ _",

! КЩЩШШШаШ

•-

Рис. 8-16.

Ссылка на спецификацию документа

2. Если ссылка на спецификацию документа указана, для данного документа можно установить глобальные поля трекинга (global tracking fields) (рис. 8-17). New Document ОгПпйМп

- : :

Еегяй btetHJTradaig | авеейзп Cniena j Spenfc*raildife'

, |iedali

-: - InboundDocumenT S Record

•,'

'--:--'-- -I, - 1 -i ,i

Рис. 8-17.

Установка глобальных полей трекинга

3. Для документов EDI можно указать поля для критерия выбора (selection criteria) (рис. 8-18).

Si

Сетей

Рис. 8-18.

&аф

-

Задание полей для критерия выбора

Теперь новый объект — описание документа — создан.

Создание организации и приложения 1. Необходимо выбрать имя организации и дать ее описание (рис. 8-19).

Ш1,1.'1.1-'

Рис. 8-19.

.£)

Имя организации и ее описание

2. Следующий шаг — установка (при необходимости) идентификаторов организации (рис. 8-20).

.laid

Установка идентификатора организации

Рис. 8-20.

••• •

'

. ..

Рис. 8-21.

Создание нового приложения в организации

Описанным способом создаются объекты, представляющие организации-партнеры. При установке BizTalk Server в конфигурации подсистемы BizTalk Messaging автоматически создается объект «Home Organization», представляющий собой домашнюю организацию. Внутри домашней организации можно создавать объекты приложения. Для этого необходимо открыть диалоговое окно свойств домашней организации и перейти на вкладку Applications и щелкнуть кнопку Add (рис. 8-21).

Создание конверта При создании конверта необходимо выбрать формат конверта, а также, если требуется, указать ссылку на спецификацию конверта (рис. 8-22).

Snatope иисймиюл Path Bnd%i папе

Создание конверта

Рис. 8-22.

Создание порта Прежде чем создавать порт, выберите его направление — к приложению или к организации (рис. 8-23),

ffi

tS- OisdUBltet \j$<

CW+T

iOWiaKBCWJOn

Ш Document B 'oi this messaging port Organic з irJDFm^acinlot ar open destaation nusl beipecifieC m H-e document cr ir\ 8fl*i(jeftis6c-n

Рис. 8-26. Окно мастера для порта к организации

В обоих окнах одинаковы области выбора основного и резервного транспортов. При щелчке кнопки Browse в каждой из этих областей, возникает соответствующее диалоговое окно выбора типа транспорта и установки его свойств для основного транспорта (рис. 8-27) и для резервного транспорта (рис. 8-28). •

Рис. 8-27.

Окно выбора типа основного транспорта и установки его свойств

Рис, 8-28.

Окно выбора типа резервного транспорта и установки его свойств

А установив флажок Service window в области Primary transport (см. рис. 8-25 и 8-26), можно указать время использования основного транспорта.

Для порта к приложению в качестве приемника разрешается выбрать XLANG-сценарий — либо уже исполняющийся в момент отправки сообщения, либо вновь запускаемый. А для порта к организации — только организацию — приемник сообщений и указать основной и резервный транспорты либо вообще не указывать приемник, установив переключатель Open destination. В этом случае порт станет открытым. Следующее окно мастера создания порта (рис. 8-29) одинаково для портов к организациям и портов к приложениям. *Envelope Infa Enlsrlm

Рис. 8-29.

Третье окно мастера создания порта

Оно предназначено для выбора конверта, используемого при отправке сообщений через данный порт, а также для задания для конвертов форматов EDI (EDIFACT и Х12) и Custom разделителей (delimiters). Если для данного порта необходимо использовать не идентификатор организации по умолчанию, а какой-то другой, то в поле Organization identifier укажите его. Последнее окно мастера показано на (рис. 8-30), Здесь задается кодирование сообщений в формате MIME, a также шифрование и электронная подпись документа. При необходимости шифрования документа необходимо указать сертификат, на ключе из которого будет выполняться шифрование. Также в этом окне определяется, надо ли запускать мастер создания канала для этого порта сразу после завершения работы мастера создания порта.

. Security Infoination Enlep the security information -i you chaoss a signal ure lypfr, (hen you must provide a aignatuiP --erlfocale when cieding th* channel IDF fhrs nesiaging pol

Рис. 8-30.

Последнее окно мастера

Создание списка рассылки При создании списка рассылки необходимо в окне, показанном на (рис. 8-31), выбрать те порты, из имеющихся в системе, которые необходимо объединить. Ш$ :•=;.••

ja

Рис. 8-31. Здесь выбирают те порты, из имеющихся в системе, которые необходимо объединить

Создание канала До создания канала, как и при создании порта, необходимо выбрать тип; канал от приложения или канал от порта (рис. 8-32). А также в списке портов указать тот, с которым будет связан создаваемый канал (вместо порта для этой цели можно использовать список рассылки).

Рис. 8-32.

Выбор типа канала: от приложения или от порта

Рис. 8-33.

Первое окно мастера создания каналов

После выбора необходимого типа канала появится первое окно мастера создания каналов (рис. 8-33) В этом окне можно указать, что данный канал является каналом получения квитанций (receipt channel). Подробнее о каналах получения квитанций рассказано в главе 9 «Взаимодействие приложений с BizTalk Server 2000*. Следующее окно мастера создания канала отличается для канала от организации (рис. 8-34) и канала от приложения (рис. 8-35). SMMM Application Proud* informal .on about the jou

appkcation la thit channel

I" SANG schedule

Рис. 8-34.

Окно мастера создания канала от организации Л

Source Organization Enter SDUIC? organization anroimatiun tc'ths channel OigarmaMninfQtrnflrJDn lui an open source must be joecified iri tht docunenl я in submission parameters

Рис. 8-35.

Окно мастера создания канала от приложения

Одинаково в этих окнах наличие возможности указать необходимость получения квитанций от приемника сообщений и время ожидания квитанции в минутах. Для отправки квитанций отправителю при обработке сообщений в этом канале надо отметить флажок Generate receipt и указать канал отправки квитанций, Следующее окно предназначено для описания входящего документа (рис. 8-36).

Рис. 8-36.

Окно для описания входящего документа

Рис. 8-37.

Здесь можно указать поля трекинга

Для входящего документа можно указать необходимость трекинга (щелкните кнопку Tracking..., чтобы открыть нужное окно) содержимого документа в канале и части документа, которые необходимо сохранять при обработке (рис. 8-37). Если требуется в данном канале обрабатывать не все документы, соответствующие описанию, а только некоторые, можно задать эти условия в диалоговом окне, открываемом при щелчке кнопки Filtering... (рис. 8-38).

..i

Рис. 8-38.

Окно, открываемое при нажатии кнопки Filtering...

Помимо этого, при использовании шифрования и электронной подписи входящих документов необходимо указать соответствующие сертификаты. В следующем окне (рис. 8-39) указывают описание исходящего документа, схему преобразования документа и необходимость электронной подписи при отправке документа в порт. Ссылка на схему преобразования в хранилище WebDAV устанавливается аналогично ссылке на спецификацию документа. Она является обязательной в случае использования различных спецификаций для входящего и исходящего документов. В следующем окне мастера (рис. 8-40) необходимо указать необходимость регистрации (logging) документов, проходящих через канал.

Как видно, содержимое этого файла соответствует содержимому файла входящего документа за исключением названия тега верхнего уровня: вместо InboundDocument — Out bound Document. Итак, приведенный пример иллюстрирует простейший пример использования BizTalk Server для интеграции приложений.

ГЛАВА 9

Взаимодействие приложений с BizTalk Server 2000 Интеграция с сервером интеграции звучит, как «масло масляное». Но тут уж ничего не поделаешь — эта глава именно об интеграции с сервером интеграции. Пользуясь средствами общения, люди почти всегда прибегают к помощи посредников. При отправке сообщения на пэйджер не обойтись без оператора, обычное письмо привозит на почту почтовый служащий, для работы электронной почты необходим провайдер и т. д. BizTalk Server, как сервер интеграции, поддерживает множество возможностей для получения и отправки сообщения. Они распределены по всей внутренней архитектуре сервера и заслуживают отдельного рассказа. В этой главе После создания решения, интегрирующего приложения и организации средствами подсистем BizTalk Messaging и BizTalk Orchestration осталось только принять сообщения на обработку от одного приложения (приложений) BizTalk Server и отправить их в другое. В этой главе описаны все возможные способы для выполнения этой процедуры. BizTalk Server принимает документы с помощью: • функций получения (receive functions), позволяющих получить документы из файловой системы и из очереди MSMQ; • программного интерфейса Ilnterchange. который, в частности, используют из ASP для получения документов по протоколу

HTTP и из скрипта Exchange для получения документов по SMTP; • средств BizTalk Orchestration, позволяющих получать документы от подсистемы BizTalk Messaging, из очереди MSMQ, а также от СОМ-компонентов — как обычных, так и реализованных в скрипте. Отправляет же документы BizTalk Server таким образом: • через транспортные сервисы, позволяющие положить сообщение в папку на диске, отправить в очередь MSMQ, на страничку в Интернете через HTTP или HTTPS, по почте через SMTP; • с помощью компонентов интеграции (Application Integration Component, AIC); • из XLANG сценария в очередь MSMQ, в канал BizTalk Messaging или в вызов СОМ-компонента. Именно об этом, а также об организации взаимодействия двух подсистем BizTalk — Messaging и Orchestration и гарантированной доставке сообщений рассказано в этой главе. ПРИМЕЧАНИЕ В этой главе рассказано о взаимодействии с BizTalk Server. Поэтому, прежде чем изучать материал этой главы, рекомендуется ознакомиться с предыдущими главами, а особенно с главой 6 «BizTalk Server Orchestration», главой 7 «Описание документов и преобразований в BizTalk Server 2000* и главой 8 «BizTalk Server Messaging». Расширению возможностей BizTalk Server посвящена отдельная глава— 12 «Расширение возможностей BizTalk Server 2000». ^ __

Способы получения и отправки сообщений На рис. 9-1 показаны все возможные способы отправки документа в BizTalk Server и получения его обратно в преобразованном виде. Многие способы отправки и получения документов можно использовать и в подсистеме Messaging и в подсистеме Orchestration.

Рис. 9-1. Архитектура отправки и получения сообщений BizTalk Server

Как видно, большинство средств получения сообщений взаимодействует с подсистемой BizTalk Messaging и уже через нее — с BizTalk Orchestration. Причем получение сообщений в BizTalk Messaging осуществляется с явным или неявным использованием интерфейса (Interchange. Непосредственное получение сообщений в BizTalk Orchestration возможно, кроме как средствами программных интерфейсов, только из MSMQ. Аналогично дело обстоит и с отправкой сообщений — большинство средств отправки доступно из BizTalk Messaging, а также возможна отправка в компоненты (то есть их вызов) и в очереди MSMQ из BizTalk Orchestration.

Получение сообщений Как уже говорилось ранее, документы BizTalk Server получает как в подсистему BizTalk Messaging, так и в подсистему BizTalk Orchestration. Получение документов в BizTalk Messaging всегда выполняется через интерфейс I Interchange. Поэтому логично начать рассказ о средствах получения именно с него.

Интерфейс (Interchange Самый простой способ отправить документ в BizTalk Server (с точки зрения его создателей) — средствами СОМ-интерфеЙса Interchange, описанного в библиотеке Microsoft BizTalk Server Interchange 1.0 Type Library. Он содержит пять функций — две для отправки документов и три для проверки того, что произошло с документами после отправки (выполнена она успешно или нет).

Два метода отправки сообщений с помощью этого интерфейса — Submit и SubmitSync отличаются, как видно из названия, тем, что один из них синхронный, то есть возвращает управление вызывающей программе только после получения ответа от BizTalk Server, а второй — асинхронный, так как после отправки документа возвращает управление немедленно, независимо от успешности отправки. Использование синхронной отправки разрешено, только если для отправки документа после обработки BizTalk Server использует синхронный протокол, такой, как HTTP(S) или AIC (Application Integration Component). В этом случае метод возвращает управление только тогда, когда документ полностью прошел все стадии обработки в BizTalk Messaging, был отправлен получателю и получатель вернул необязательный ответ. При этом ответ получателя возвращается в параметре ResponseDocument. Далее описаны все методы интерфейса [Interchange.

Submit Метод Submit предназначен для асинхронной отправки сообщений на обработку в BizTalk Server. Описание этого метода показано ниже: Function Submit( lOpenness As BIZTALK_OPENNESS_TYPE, Document As String, DocNarne As String, „ SourceQualifier As String, SourcelD As String, DestQuallfier As String, _ DestID As String, ChannelName As String, FilePath As String, EnvelopeName As String, PassThrough As Long) ) As String

Параметры этого метода описаны ввместе с параметрами метода SubmitSync в таблице 9-1.

SubmitSync Метод SubmitSync предназначен для синхронной отправки документов в BizTalk Server (таблица 9-Г), Метод возвращает управ-

ление вызывающей программе только тогда, когда отправленный документ пройдет все этапы обработки, и будет отправлен получателю, а тот, в свою очередь, пришлет ответ (если это поддерживается используемым транспортом). Описание метода: SubSubmitSync( lOpenness As BIZTALKJ)PENNESS_TYPE, Document As String, DocName As String, SourceQualifier As String, SourcelD As String, DestQualifier As String, DestID As String, ChannelName As String, FilePath As String, EnvelopeName As String, PassThrough As Long, _ SubmissionHandle As Variant, ResponseDocument As Variant) Таблица 9-1. Параметры методов Submit и SubmitSync Параметр

Тип

lOpenness

Enum

Назначение Значение из перечисления BIZTALK_OPENNESS_ TYPE. Этот параметр позволяет отправлять самомаршрутизирующиеся документы, содержащие информацию об источнике и приемнике документа, а также несамомаршрутизирующиеся документы. Перечисление содержит необходимые значения: • BIZTALK_OPENNESS_TYPE_NOTOPEN — несамомаршрутизирующийся документ; • BIZTALK_OPENNESS_TYPE_SOURCE — в документе содержится информация об источнике; • BIZTALK_OPENNESS_TYPE_DESTINATION — в документе содержится информация о приемнике. см, след. стр.

Таблица 9-1. Параметр

продолжение

Тип

Назначение Для того чтобы документ стал самомаршрутизирующимся, необходимо в его спецификации установить соответствующие значения на вкладке Dictionary в BizTalk Editor. Это единственный обязательный параметр в методах. Остальные можно опустить все либо, как. например, в параметрах Document и FilePath, только один из них

Document

String

Через этот параметр можно передать содержимое документа в виде строки, кроме того, возможно указать путь к файлу документа на диске с помощью параметра FilePath. Необходимо установить только один из этих параметров, но не оба сраз\

DocName

String

Имя описания документа (document definition) в схеме соединения BizTalk Messaging, которое будет использоваться при обработке документа. Эта информация необходима для выбора подходящего канала обработки, но ее можно опустить либо в случае прямого указания канала через параметр EnvelopeName, либо если информация о типе документа содержится в нем самом

Sou rce Qualifier

String

Тип идентификатора организации (organization identifier), который передается через параметр SourcelD. Это может быть имя (используется по умолчанию), телефонный номер и т. д.

SourcelD DestQualifkr

DestID

String String

String

Идентификатор организации отправителя сообщения Тип идентификатора организации (organization identifier), который передается через параметр DestID Идентификатор организации получателя сообщения

Таблица 9-1.

продолжение

Параметр ChannelName

Тип

Назначение

String

В случае использования маршрутизации этот канал для обработки выбирается на основании информации, указанной в документе, либо информации, переданной в BizTalk Server при отправке документа. Если же необходимости в маршрутизации нет, имя канала для обработки разрешается указать явно через параметр ChannelName. Этот параметр обязательно задают при установке параметра PassThrough в True, то есть при использовании отправки с пропуском начальных стадий обработки (pass-through submitting)

FilePath

String

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

EnvelopeName

String

PassThrough

Long

Имя используемого при отправке конверта (envelope). Параметр необязателен при отправке документов XML и при отправке плоских файлов Флаг, показывающий необходимость отправки с пропуском начальных стадий обработки (pass-through submitting). В случае установки этого параметра в True параметры DocName, SourceQualifier, SourcelD. DestQualifier и DestID надо опустить, но обязательно установить параметр ChannelName. Кроме того, параметр lOpenness необходимо установить в значение BIZTALK J3PENNESS_TYPE_NOTOPEN

Submission Handle

Variant Идентификатор отправленного документа. Используется для последующего поиска информации о документе в базе данных трекинга. Этот параметр имеется только в функции Submit Sync, а в функции Submit он является возвращаемым значением см. след. стр.

Таблица 9-1. Параметр

продолжение Тип

Назначение

ResponseDocument Variant В этот параметр записывается ответный документ в случае его наличия

CheckSuspendedQueue Функция CheckSuspendedQueue позволяет проверить содержимое очереди приостановленных документов (Suspended Queue). Это можно делать в любой момент времени, однако рекомендуется проверять наличие новых документов после использования метода Submit, асинхронно отправляющего документы на обработку. Метод SubmitSync не вернет управление до тех пор, пока документ не будет отправлен адресату, поэтому проверка очереди приостановленных документов при его использовании считается излишней. Описание функции: Function CheckSuspendedQueue( DocName As String, SourceName As String, DestName As String) As Variant

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

GetSuspendedQueueltem Details По полученным с помощью функции CheckSuspendedQueue идентификаторам документов можно получить дополнительную информацию о причине их попадания в очередь средствами функции GetSuspendedQueueltemDetails: SubGetSuspendedQueueItemDetails( IteroHandle As String, SourceName As Variant, DestName As Variant, DocName As Variant, ReasonCode As Variant, ItemData As Variant)

У функции один входной параметр — ItemHandle, через который в нее передается идентификатор документа в очереди, и пять выходных параметров, через которые можно получить информацию о документе (имя описания документа, имена источника и приемника, а также содержимое) и причину его попадания в очередь. Причину попадания документа в очередь позволяет узнать ReasonCode. Его значение соответствует одному из значений перечисления CISReasonToQueue_tag, объявленного в той же библиотеке, что и интерфейс [Interchange.

DeleteFromSuspendedQueue После того как необходимая информация о документах в очереди отложенных документов получена, можно очистить очередь, удалив из нее все или только некоторые документы с помощью функции DeleteFromSuspendedQueue: Sub DeleteFromSuspendedQueue( DocumentHandieList As Variant) Функция удаляет из очереди те документы, идентификаторы которых переданы ей через массив строк в параметре DocumentHandleList.

Использование (Interchange Таким образом, алгоритм использования интерфейса [Interchange для асинхронной отправки выглядит так: 1. отправка документа в BizTalk Server с помощью функций Submit; 2. проверка через некоторое время очереди приостановленных документов с помощью функции CheckSuspendedQueue: 3. определение причины попадания документа в эту очередь посредством функции GetSuspendedQueueltemDetails; 4. удаление документа или документов из очереди с помощью Delete FromSuspendedQueue. При использовании синхронной отправки SubmitSync успешность отправки выясняется сразу после вызова по коду возврата, правда, возврат производится с задержкой,

Интерфейс IBizTalkTrackData Чтобы получить информацию об отправленном через интерфейс [Interchange сообщении, можно воспользоваться интерфейсом IBizTalkTrackData. Через него удается выяснить информацию, сохраненную в базе данных трекинга. Подробнее об этом рассказано в главе 10 «Трекинг документов».

Функции получения Функции получения (receive functions) необходимы для отправки документов в BizTalk Messaging из определенного каталога файловой системы или из очереди MSMQ. Они представляют собой не что иное, как надстройку над интерфейсом [Interchange. Оба типа функции с определенным интервалом времени проверяют очередь в MSMQ или каталог в файловой системе на появление там новых файлов или сообщений и вызывают с необходимыми параметрами функцию Submit интерфейса [Interchange. Функции получения создаются и настраиваются из приложения BizTalk Server Administration. В левой части ММС-приложения расположен узел Receive Functions (рис. 9-2).

Console Root ф Mic'osort Bi2T..,

Рис. 10-9.

•

Создание запроса расширенного поиска

После создания запрос следует сохранить в базе данных для дальнейшего использования, присвоив ему определенное имя. Чтобы отыскать этот запрос, надо нажать кнопку Browse в основном окне приложения или ввести имя в поле Expression name,

Программный доступ к базе данных трекинга Для программного обращения к базе данных трекинга можно воспользоваться объектом BTSDocTracking, который находится в библиотеке Microsoft BizTalk Server Doc Tracking 1.0 Type Library. Объект имеет три метода, все они описаны в таблице 10-1. Таблица 10-1. Имя метода GetlnDocDetails

Описание методов объекта BTSDocTracking Назначение Метод возвращает ссылку на объект Recordset, который содержит информацию о входящих документах, соответствующих идентификатору, подученному в результате вызовов методов Submit или SubmitSync интерфейса llnterchange

GelOutDocDetails Метол возвращает ссылку на объект Recordset, который содержит информацию об исходящих документах, соответствующих идентификатору, полученному в результате вызовов методов Submit или SubmitSync интерфейса llnterchange Get Interchanges

Метод возвращает ссылку на объект Recordset, который содержит всю информацию о пересылках, соответствующих идентификатору, полученному в результате вызовов методов Submit или SubmitSync интерфейса [Interchange

Настройка BizTalk Tracking для работы с Orchestration Как уже говорилось ранее, BizTalk Tracking предназначен для сбора информации о проходящих документов только через подсистему Messaging, но не через Orchestration. Но это препятствие можно обойти. В SDK к BizTalk Server входит демонстрационное приложение WorkFIowAudit, позволяющее включить запись дополнительной информации о документах, а также проходящих

между BizTalk Messaging и Orchestration событиях в таблицы базы данных трекинга. Для того чтобы активизировать эту возможность, необходимо: • зарегистрировать средствами утилиты RegSvr32 библиотеку WorkFlowAudit.dll, хранящуюся в каталоге \Program Files\Microsoft BizTalk Server\SDK\XLANG Samples\WorkFlowAudit\bin\ на диске, где установлен BizTalk Server; • запустить приложение WorkflowAuditClient.exe, находящееся в каталоге \Program Files\Microsoft BizTalk Server\SDK\XLANG Samples\ W o r k F l o w A u d i t C l i e n t \ , и щелкнуть в нем кнопку Start. Информация записывается только при запушенном приложении! Окно приложения WorkflowAuditClient показан на рис. 10-10.