Microsoft BizTalk Server 2010 R2: Основы программирования

Что это такое?

Статья опубликована в журнала MSDeveloper.RU

Когда я впервые столкнулся с BizTalk Server, то довольно долго пытался «въехать», как же с его помощью начать создавать приложения. О том, что такое BizTalk Server и для чего оно нужно, мне было понятно из обзорных статей, например, на сайте Microsoft есть довольно неплохая обзорная информация по этой технологии (http://www.microsoft.com/biztalk/ru/ru/overview.aspx), более того, наверное, на русском языке больше материала просто не найти.

Итак, что же такое BizTalk Server? Если кратко, то это серверное решение Microsoft, которое служит для связывания разрозненных систем, с использованием различных способов обмена информацией. Можно выделить две основные функции BizTalk Server:

· «Брокер сообщений», т.е. преобразование сообщений из формата одной системы в формат другой;

· «Интеграционная шина», т.е. связывание систем через использование унифицированного канала обмена информацией.

Ознакомление с теоретической частью интеграции корпоративных приложений я рекомендую начать с книги «Шаблоны интеграции корпоративных приложений» (авторы Г. Хоп и Б. Вульф), в данной статье я попытаюсь показать, как можно с наименьшими усилиями начать писать приложения, используя Microsoft BizTalk Server 2010 R2.

Средства, необходимые для разработки

Итак, для того, чтобы писать приложения под BizTalk Server 2010 R2 нам понадобятся такие инструменты:

· Microsoft Windows: Windows 7, Windows Server 2008 R2, Windows Server 2008 SP2, Windows Vista (SP2)

· SQL Server 2008 R2 \ SQL Server 2008 SP1

· Microsoft Visual Studio 2010

· Microsoft .NET Framework 4 и .NET Framework 3.5 (SP1)

· SQLXML 4.0 (SP1)

· Internet Information Services (IIS) 7.5

Непосредственно для BizTalk Server (здесь и далее BTS) нужно скачать версия для разработчиков BizTalk Server 2010 — Developer Edition со страницы http://goo.gl/l0uOf. Установка и настройка достаточно простая и описана в моем блоге на странице http://goo.gl/2RPF7

Пример

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

Не будем выдумывать сложных задач, пусть ее условия будут максимально простыми, как, например, сложить числа a и b. Итак, пусть у нас есть такие участники процесса:

· Система А, делающая запрос к интеграционной шине, будет отправлять два числа;

· Система B, представляющая интеграционную шину, будет эти два числа складывать;

Весь процесс можно представить на диаграмме последовательности:

pic01

Как видим, все максимально просто, и я уверен, что можно без труда реализовать подобную систему, не используя BTS. Однако, в реальности таких сценариев очень много («взять отсюда, отдать туда»), и они осложнены тем, что участников довольно много и сам поток информации должен динамически изменяться, следуя каким-то бизнес-правилам, например, шина может не сама вычислять результат, а обращаться за данными в другие системы типа SAP. Отсюда возникают задачи масштабирования приложений, управления их нагрузкой, предоставления удобной платформы для управления бизнес-правилами. В составе BTS всё это есть – разработаны адаптеры для различных источников данных (базы данных, FTP- и веб-сервисы, файлы, почта и прочее), есть платформа для управления бизнес правилами (Business Rules Composer) и средства для обширной диагностики системы.

Итак, у нас есть два участника процесса, сейчас нам нужно определить, на чем будет реализована каждая из систем. Система А будет представлена консольным приложением и сервисом WCF, система B будет реализована на основе BTS.

Разработка решения на BizTalk

Начнем работу с создания нового проекта BizTalk:

pic02

Данный шаблон создаст проект для BTS и добавит ссылки на все нужные сборки:

pic03

Схемы

Нам нужно представить вид, в котором мы будем обмениваться информацией с другими системами. Основной язык, используемый в BTS, — это XML, что, впрочем, неудивительно, именно этот язык служит основным средством для связывания гетерогенных сред. Поэтому наши типы данных будут в виде XML. Для этого определим два типа – Request и Response, запрос и ответ соответственно. Добавим две схемы через стандартный диалог Add New Item:

pic04

Замечу, что в данном диалоге можно увидеть все основные объекты, которыми оперирует BTS, а именно оркестровки, карты, конвейеры и схемы. О них речь пойдет ниже.

Итак, добавим две новых схемы. BTS предоставляет специальные редакторы для XML, с его помощью можно довольно легко редактировать структуру XML:

pic05

С помощью редактора XML нужно создать такую структуру:

<ns0:Request xmlns:ns0="http://SystemB.Request">
    <A>10</A>
    <B>10</B>
</ns0:Request>

Для этого нужно переименовать Root в Request и добавить к нему два дочерних узла через команду контекстного меню Insert Schema Node \ Child Record.

pic06

Далее, у узлов A и B нужно задать типы данных, сделать это можно, выделив соответствующий узел в дереве XML и в окне свойств задав нужный тип Base Data Type, в нашем случае это xs:int.

pic07

Аналогичным образом создадим структуру для Response:

<ns0:Response xmlns:ns0="http://SystemB.Response">

<Result>10</Result>

</ns0:Response>

Чтобы затем не возвращаться к структуре XML, нам нужно к Request и Response добавить узел CorrelationID. Для этого через команду Insert Schema Node \ Child Record добавляем новый узел CorrelationID, задаем тип xs:string и дальше определяем вид этой строки. Допустим, мы хотим, чтобы это был GUID, для этого делаем следующее:

1. Закрываем файл, выбираем его в окне Solution Explorer, вызываем контекстное меню, выбираем команду Open With

pic08

2. Выбираем XML (Text) Editor

pic09

3. Находим и заменяем кусок вида

pic10

на кусок вида

pic11

Таким образом мы наложили ограничение в виде паттерна GUID ([a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}) на строку, которая может храниться в поле CorrelationID.

Аналогичные действия нужно совершить с Request.

Оркестровки

Итак, у нас есть схемы данных, теперь нам нужно определиться, каким образом наши данные будут «гулять» в ходе нашего процесса. Для этого BTS предоставляет нам способ описания бизнес-процессов – оркестровки. Оркестровка – это некая блок-схема обработки сообщений, выглядит она следующим образом:

pic12

На первый взгляд пугает, конечно, но на самом деле ничего сложного в этом нет, думаю, все умеют читать блок-схемы. BTS предоставляет фиксированный набор компонент для оркестровок, это набор компонент для управления ходом процесса (Loop, Decide, Terminate, Throw Exception), компоненты манипуляции с данными (Receive, Send, Transform, Message Assignment) и прочее. То есть, нельзя, как в Windows Workflow Foundation, разработать свои компоненты и использовать их, хотя произвольный код можно выполнять в специальном компоненте Expression. На картинке ниже представлены все компоненты:

pic13

Давайте создадим свою оркестровку, начнем с добавления через команду Add \ New Items:

pic14

Выбираем BizTalk Orchestration, задаем название (я назову «MainFlow») и нажимаем Add. К проекту добавится файл MainFlow.odx и откроется окно редактирования оркестровки:

pic15

Оркестровка описывается в виде XML и с помощью языка XLANG/s, который является «младшим» братом C#. Для просмотра исходного кода оркестровки следует выбрать нужную в проекте, в контекстном меню выбрать команду Open With и в появившемся окне Open With выбрать пункт XML (Text) Editor. Откроется окно с подобным содержимым:

pic16

К счастью, практически никогда этот код читать нужно не будет.

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

1. Нужно получить входящий запрос от системы A

2. Нужно рассчитать ответ

3. Нужно отправить рассчитанный ответ системе A

Приступим к реализации, начнем с получения данных, для которых есть компонент Receive, который будет «прослушивать» входящий канал на предмет новых сообщений. Открываем оркестровку, в Toolbox находим элемент Receive и бросаем его на оркестровку, должно получиться вот так:

pic17

Мы должны получить сообщение в виде XML, созданного по определенной нами схеме Request, поэтому мы должны определить сообщение типа Request. Для этого в окне Orchestration View нужно выбрать узел Messages и через контекстное меню вызвать команду New Message:

pic18

Эта команда добавит новое сообщение, у которого нужно задать тип через окно свойств Properties:

pic19

Окно выбора Message Type сделано не очень удобно, нельзя изменить его размеры, тем не менее, нужно в появившемся окне выбрать узел Schemas и созданный нами ранее тип SystemB.Request.

Далее нам нужно указать, откуда данное сообщение поступит. Для этого нам нужно определить логический порт для входных данных. Для этого нужно вызвать контекстное меню поля Port Surface и выбрать команду New Configured Port…:

pic20

Появится мастер создания нового порта, нужно нажать кнопку Next, далее задать имя порта (оставим предложенное по умолчанию), снова нажать Next и задать конфигурацию порта так, как на картинках ниже:

pic21

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

pic22

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

После нажатия на кнопку Finish оркестровка должна принять следующий вид:

pic23

Теперь у нас есть источник сообщений, дальше нам нужно эти сообщения из него получить. У компонента Receive есть ряд свойств, которые нам нужно установить. Для этого выделяем фигуру Receive_1, вызываем окно свойств и устанавливаем свойства так, как на картинке ниже:

pic24

Обращаю ваше внимание на свойство Activate=True, которое указывает, что наша оркестровка будет вызвана всякий раз, когда на порт поступит сообщение.

Дальше у нас стоит задача по расчету и отправке результата. Для этого нам нужно добавить еще одно сообщение, также типа Response, скопировать в его поле CorrelationID соответствующее поле из первого сообщения, а также заполнить поле Result. Для этого воспользуемся картами (Maps).

Карты

Карты – это XSLT-преобразования, которые мы можем выполнять над нашими сообщениями.

В окне Orchestration View добавляем еще одно сообщение Message_2 типа SystemB.Response. Находим в Toolbox элемент Transform, кидаем его на оркестровку сразу под компонентом Receive_1 и в его контекстном меню выбираем Configure Transform Shape (также можно просто два раза кликнуть по компоненту):

pic25

Откроется окно с параметрами трансформации:

pic26

Указываем, что мы хотим создать новую карту трансформации, выбираем источника (Message_1) и получателя (Message_2), ставим галочку When I click OK, launch the BizTalk Mapper и далее нажимаем OK, должно открыться окно BizTalk Mapper:

pic27

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

pic28

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

pic29

Далее нам требуется рассчитать сумму A и B, к счастью для нас есть разработанный функтоид Addition, он расположен в разделе Mathematical Functoid окна Toolbox. Его нужно натащить на карту:

pic30

Если два раза щелкнуть по расположенному функтоиду, откроет окно его свойств:

pic31

Как мы видим, ему требуется входные параметры в количестве от 2 до 100. Предоставим ему это, закроем окно его свойств и натащим поля A и B из первого сообщения на наш функтоид:

pic32

Желтый восклицательный знак на функтоиде подсказывает нам, что мы не задали выход для функции, натащим поле Result второго сообщения на добавленный функтоид:

pic33

Теперь всё в порядке, данная карта будет принимать сообщения типа Request и Response, при этом после преобразования в поле Result сообщения Response будет храниться сумма значений полей A и B сообщения Request, а в поля CorrelationID будут одинаковы. Сохраняем карту и закрываем окно BizTalk Mapper.

Итак, на данный момент мы умеем получать сообщение и вычислять результат. Теперь нам нужно отправить результат наших вычислений. Для этого нужно добавить на правый Port Surface новый порт (собственно, правый или левый – значения не имеет):

pic34

pic35

pic36

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

pic37

Тип сообщения, с которым работает порт, можно указать вручную, для этого нужно в окне Orchestration View найти созданный тип порта, выбрать операцию и указать у нее тип:

pic38

Далее нам нужно на добавленный порт отправить сообщение Message_2, в котором после преобразования с помощью карты будет храниться искомый результат. Для этого из Toolbox нужно натащить компонент Send и расположить его прямо под элементом Construct Message:

pic39

После этого нужно указать, какое сообщение мы будем отправлять, для этого нужно в окне Properties выбрать Message_2, а затем натащить коннектор фигуры Send_1 на коннектор Request порта Port_2 (либо просто выбрать Operation в свойствах Send_1):

pic40

После этого наша оркестровка приобретает законченный вид, а наше приложение можно разворачивать в пуле приложений BizTalk Server 2010 R2.

pic41

Развертывание приложения

Для развертывания (Deploy) нашего приложения нам нужно подписать нашу сборку (поскольку она будет располагаться в GAC), а также задать параметры развертывания.

Открываем окно свойств проекта (выбрать проект в окне Solution Explorer, в его контекстном меню выбрать пункт Properties), переходим на вкладку Signing и задаем файл для подписи сборки. Если нужно, можно сразу создать новый файл:

pic42

После этого переходим на вкладку Deployment, где нужно задать следующие параметры:

BizTalk Group

a. Application Name – имя приложения;

b. Configuration Database – база данных BizTalk, в которой хранится вся конфигурационная информация. По умолчанию это база называется BizTalkMgmtDb;

c. Server – имя компьютера, на котором развернут BizTalk;

pic43

На этом всё, нужно сохранить все файлы и выбрать в главном меню Visual Studio пункт Build \ Deploy Solution, при этом не забывайте, что VS должна быть запущена от имени администратора.

Настройка портов

Развернутое приложение нужно настроить на получение сообщений, в нашем случае настроим его на получение сообщений от веб-сервиса. Для этого нужно запустить утилиту BizTalk WCF Service Publishing Wizard, которая умеет создавать и публиковать веб-сервисы для приложений BTS.

После запуска утилиты появится мастер публикации сервиса. На экране выбора типа WCF-сервиса нужно установить следующие параметры:

pic44

Здесь мы указали, что сервис должен использовать WCF-биндинг basicHttp, разрешить endpoint с метаданными и создать физический порт (receive location) для нашего приложения, SystemB. На следующем экране нужно выбрать опцию Publish schemas as WCF service, далее появится следующий экран:

pic45

Здесь нам нужно задать сигнатуру для нашего сервиса. Помимо переименования, на данном месте нужно вспомнить, что наш логический порт Port_1 имеет тип OneWay, поэтому Response в данном случае у сигнатуры лишний, его нужно удалить через контекстное меню (в данном окне вообще всё делается через контекстное меню). Далее, нужно указать, что мы принимаем сообщения типа Request:

pic46

Появится окно выбора сборки с типам, нужно найти сборку SystemB.dll, ее можно взять либо из GAC (C:\Windows\Microsoft.NET\assembly\GAC_MSIL\SystemB), либо из папки bin\$Configuration$ нашего проекта, далее нужно выбрать тип SystemB.Request:

pic47

Описание сервиса принимает вид:

pic48

Далее на экране ввода namespace веб-сервиса можно оставить всё по умолчанию, либо задать свой, например, «http://SystemB». На следующем экране нужно задать параметры публикации сервиса, я указываю следующие:

pic49

На следующих шагах мастер опубликует сервис и можно попробовать зайти по опубликованному адресу, в моем случае это «http://localhost/SystemB/SystemB.svc». К сожалению, не все так просто в век всеобщей безопасности, поэтому вместо сервиса BTS можно увидеть сообщение об ошибке логина:

pic50

Дело в том, что Application Pool по умолчанию (DefaultAppPool) не имеет доступа к базам данных BTS в MS SQL Server, поэтому нужно заводить отдельный пул приложений и настраивать у него запуск с учетной записью, которая эти права имеет, а затем назначать веб-сервис выполняться в созданном пуле.

После всех этих действий можно снова попробовать обновить адрес в IE. Если всё было сделано правильно, появится следующая картинка:

pic51

Смысл этой ошибки в том, что мы создали сервис, привязали его к входящему порту нашего приложения, но само приложение, как и его порт, не было запущено. Для запуска приложения нужно запустить утилиту BizTalk Server Administration Console. Эта утилита является основным средством настройки и диагностики BizTalk Server 2010 R2, в ее состав была включена существовавшая отдельно утилита HAT – Health and Activity Tracking.

Итак, открываем BTS Administration Console и в дереве консоли слева переходим на узел BizTalk Server Administration \ BizTalk Group [%DataBase%] \ Applications \ SystemB \ Receive Locations:

pic52

Выбираем единственный receive location, в контекстном меню выбираем у него Enabled и идем смотреть обратно в браузер

pic53

pic54

На этот раз ошибок нет, сервис показывается, по адресу http://localhost/SystemB/SystemB.svc?wsdl можно получить его WSDL.

Тестирование

Полученное приложение хотелось бы рассмотреть в работе, для этого я предлагаю использовать программу soapUI, которая позволяет тестировать веб-сервисы (включая нагрузочное тестирование и создание mock-веб-сервисов).

Запускаем soapUI, добавляем новый проект и указываем WSDL к нашему веб-сервису:

pic55

После нажатия на кнопку OK программа скачает WSDL, распарсит его и подготовит проект, а также сгенерирует тестовый запрос к сервису:

pic56

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

pic57

Если терпение еще осталось, можно побороться и с этой ошибкой J

Идем в BTS Administration Console и в дереве выбираем Event Viewer \ Windows Logs \ Application (можно и отдельно запустить просмотрщик событий). Последнее событие-ошибка будет от BizTalk Server:

pic58

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

Снова выбираем наше приложение в списке приложений BTS, в контекстном меню выбираем Configure:

pic59

Зададим параметры для оркестровки MainFlow:

pic60

Здесь нам также нужно создать новый физический Send Port для привязки его к логическому Port_2, который отсылает, если вы помните, ответ. Чтобы не усложнять и без того раздувшееся вступление в мир BizTalk, будем ответы складывать в папку на диске.

В раскрывающемся списке напротив Port_2 окна Configure Application нужно выбрать <New send port>

pic61

Появится окно по созданию нового порта отправки, нужно задать Type=FILE и нажать кнопку Configure, где нужно будет задать папку, в которую будут приходить ответы:

pic62

Я задам, чтобы файлы складывались в папку C:\temp\SystemA. Затем нужно закрыть все окна, нажав кнопки OK, в итоге окно по настройке приложения будет выглядеть вот так:

pic63

После этого нужно запустить приложение:

pic64

После запуска возвращаемся в soapUI и выполняем запрос:

pic65

На этот раз нам придет «пустой» ответ, а в папке, указанной для SendPort, будет лежать файл с ответом:

pic66

Заключение

В данной статье мы рассмотрели основы программирования для BizTalk Server 2010 R2, разобрались с основными частями работ по созданию приложений, а также проверили наше тестовое приложение на работоспособность. Безусловно, затронутые вещи – лишь верхушка айсберга, который представляет собой BTS, поскольку кроме таких базовых вещей есть также вопросы по использованию других типов адаптеров, более сложных сценариев работы с использованием реестров UDDI и платформы определения бизнес-правил Business Rules. Отдельным вопросом является (автоматизированное) тестирование, поскольку тестирование приложений BTS — довольно сложное недокументированное дело. Также мы не затронули вопросы диагностирования и вычисления метрик производительности BTS на основе платформы Business Activity Monitoring, которая, к слову, может использоваться не только в рамках приложений BTS, но и для замеров производительности сервисом WCF и WWF.

29 комментариев к “Microsoft BizTalk Server 2010 R2: Основы программирования

  1. Спасибо Вам огромное за детальную и очень понятную статью, для меня как для новичка в этой теме.
    Я только начинаю «въезжать» в biztalk server и многие вещи стали более понятней после прочтения. Может можете посоветовать книгу по biztalk server 2010 .
    Задача — обмен данными между MS CRM and NAV.
    Смотрел коннекторы от майрософта, но что то не впечатляют они меня.
    Пока смотрю в сторону biztalk но нужна очень «правильная» книга что бы сделать меньше ошибок.
    Заранее спасибо.

    1. Первый отзыв по статьям, который я получил! 🙂

      Книги, которые я могу порекомендовать вам:
      — SOA Patterns With BizTalk Server 2009
      — BizTalk Server 2006 (Wrox)
      — Microsoft BizTalk Server 2010 Patterns (Packtpub)
      — Microsoft BizTalk 2010: Line Of Business System Integration (Packtpub)
      — BizTalk 2010 Recipes (Apress)

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

  2. БТ не массовый подукт и в россии не слишком распространенный.
    возможно это в силу своей не простой идеологии, однако множество задач которые могут быть решены действительно велико.
    собственно у меня вот какой вопрос: удалось ли вам посмотреть другую сторону БТ связанную с маршрутами сообщений.
    если с вариантами типа: приложение как сервис и управление длительными процессами с использование оркестровки идейно все понятно, то уровень esb пока еще вызывает определенные трудности.
    доводилось ли использовать esb toolkit и настраивать так называемые itineary services. было бы здорово обменяться опытом

    1. Мы «тыкали палкой-копалкой» в ESB toolkit, но в конце концов отказались от его использования. По нескольким причинам:
      — Он мудреный какой-то, возможно инструменты по его настройке недостаточно развиты. Нет интуитивно понятного.
      — Может быть наша система была недостаточно сложна для применения такой надстройки, но маршрутизацию я с легкостью сделал вручную. По сути, вся работа тулкита по маршрутизации заключается в промотировании каких-то служебных полей в сообщении, ну а в оркестровках в Receive мы ставим фильтры на эти поля. Я сделал единую оркестровку EntryPoint, которая принимала сообщения в формате кастомера, конвертировала их в наш внутренний формат сообщений и отправляла сообщение дальше через direct port binding (таким образом, через Messaging Engine и его MsgBox). Ну а оркестровки точно также и настраивал, устанавливая фильтры в Receive. Таким образом, у нас нет одной большой оркестровки, в которой бы находился огромный Decide с вызовом кучи оркестровок по условию какому-то.
      Оттого я что-то не прочувствовал каких-то преимуществ для использования этого тулкита.

    2. У меня есть мнение насчет немассовости бизтолка:
      — он дорогой.
      — малая доля информатизации России. Диагнозы у нас в медкартах хранятся, а не передаются с помощью HL7 между больницами, например.
      — высокий порог вхождения, трудно в него бывает въехать. Хотя конечно, было бы желание 🙂

  3. А мне довелось использовать ESB Toolkit. Но впечатления от него остались неоднозначные: с одной стороны идея не плохая, но реализация очень сырая, будто не 2.1 верия, а 0.1.

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

    1. Насколько я понял, вся сущность ESB Toolkit в том, что он промотирует свойства некие в сообщение, а дальше уже бизтолк по ним раскидывает по оркестровкам. Но это настолько мало, что прикручивать малопонятный фреймворк кажется совсем нецелесообразным. Для динамической отправки по оркестровкам я за час наверное сделал единую оркестровку-точку входа, ничего сложного. В целом согласен, какая-то сырая и недопиленная штука.
      А по развитию — надо смотреть аналоги. IBM-овские и оракловые решения меня совсем не прельщают, особенно беспокоит Java, с которой я, поимев дело один раз, больше встречаться не хочу.

  4. Во-первых, спасибо за статью.
    Вопрос по статье:
    После фразы «Зададим параметры для оркестровки MainFlow:» идет картинка, на которой в колонке Recieve Ports стоит значение «WcfRecievePort_SystemB/SystemB». У меня подобного значения для выбора нет. Не подскажете, откуда оно берется?

    1. см. раздел «Настройка портов» — там с помощью BizTalk WCF Service Publishing Wizard генерируется веб-служба и при этом создается receive location (на рис. http://www.written.by.krechun.com/wp-content/uploads/2012/02/pic44.png тычка Create BizTalk receive location in the following application проверьте, чтоб в поле BizTalk application name стояло именно ваше приложение)

          1. Чудеса какие-то. Возможно, вы с типами сообщений напутали? Или не в том приложении создали receive location? В BizTalk Server Administration Console перейдите в ваше приложение, раскройте список Receive Locations — есть там что-нибудь?

                1. Отправил.
                  Вот ещё что. Стал повторно проверять все шаги, наткнулся на то, что этот код:

                  10
                  10

                  Я нигде не увидел. Это что-то значит?

                  1. Вы всё-таки неправильно сгенерировали сервис.

                    Зайдите в BizTalk Server Administration Console в свое приложение в Receive Ports — там у вас один receive port, а у него в колонке Two Way стоит Yes — т.е. вы создали порт receive-response, а нам нужен OneWay.

                    При настройке порта в админ. консоли вы не можете выбрать порт, потому что бизтолк понимает, что для логического порта Port_1 требуется тип порта OneWay, а не TwoWay, который вы создали.

                    Когда вы генерируете сервис с помощью BizTalk WCF Publishing Wizard, убедитесь, что финальная версия сервиса выглядит именно так, как на рис. http://www.written.by.krechun.com/wp-content/uploads/2012/02/pic48.png

                    Пройдите еще раз раздел Настройка портов, только внимательнее 🙂

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

  6. Евгений, большое спасибо. Делаю для диплома интеграционное решение на базе BTS и ваша статья была очень полезна. Все шаги понятны, единственная проблема возникла при запуске сервиса, но это уже не относилось к BTS, а связано с тем, что у меня не были доустановлены компоненты ASP.NET для IIS 7. Вопрос решился запуском утилиты — C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe с ключем -i

  7. Добрый день.
    Огромная благодарность за статью и за то, что восстановили работу сайта.
    Пройдя все шаги в статье, проблем не было. Все заработало так, как и должно было.
    Но у меня возникли проблемы с «обновлением».
    Что я сделал:
    1. Внес изменения в схему Response (добавил еще парочку вычисляемых полей).
    2. Внес изменения в карту Transform (чтобы эти поля вычислялись).
    3. Все сбилдил и развернул на сервер.
    Все работает, но файлы результата формируются по старой схеме Response (без дополнительных полей).
    Пробовал удалить узел WCF-сервиса и заново его опубликовать.
    Пробовал удалить само приложения c BTS
    Пробовал удалить саму карту Transform
    Но ничего не помогает.

    Не подскажете, как проходит обновление приложений в BTS’е?

    1. Добрый день,

      Обновление приложений проходит примерно так, как вы всё сделали – единственно, я обычно стараюсь поддерживать порядок в солюшене и заставляю студию саму деплоить проект. В вашем случае какая-то магия, вы уверены, что вы изменили схему и карту? Карта точно используется? У вас написаны юнит-тесты, которые это подтверждают? Если всё честно, то можно попробовать удалить сборки из GAC еще. А так, в целом, удаление из BTS должно по-любому удалить весь мусор.

  8. Привет, спасибо за статью..

    У меня появляется ошибка:
    The Messaging Engine failed to register the adapter for «WCF-BasicHttp» for the receive location «/BTProject1Service2/Service1.svc». Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

    можешь помочь пожалуйста?

  9. Спасибо огромное!!!! 3 недели копала мсдн и просторы сети, до всего уже дошла, но ваш материал подлечил мои смутные сомнения! Конечно по сравнению с другими интеграционными системами наворочено много, но зато и возможностей много + бизнес идет на поводу микрософта=>.Нет +бизталк будут наплаву еще лет 10 как мин(про российский рынок не утверждаю).

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *