Category Archives: BizTalk course

Microsoft BizTalk Server: Что это такое?

Что такое Microsoft BizTalk Server?

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

Интеграция?

BizTalk позиционируется, как пакет для интеграции систем.

Что Microsoft вкладывает в понятие «интеграция», применительно к BizTalk?
Здесь три главных аспекта:

  • обмен данными
  • преобразование форматов данных
  • бизнес процессы

Обмен данными

Обмен данными в разных форматах и по разным протоколам и стандартам. Имеются в виду форматы данных, такие, как многочисленные текстовые форматы, SQL, Xml. Протоколы, такие, как HTTP, SOAP, SMTP, POP3, FTP, MSMQ, которые обычно включают в себя и стандарты форматов данных. Форматы приложений, таких, как, SAP/R3, Siebel и индустриальные стандарты, такие как EDI, SWIFT, HL7, HIPPA, которые включают в себя форматы данных, протоколы, системы аудита, защищенности.
Иногда в понятие обмена данными вкладывается структурное преобразование данных между форматами (например, данные надо преобразовать из текстового формата в формат Xml) плюс использование нужного протокола обмена (пример, данные надо передать по протоколу SOAP, что означает преобразование данных в формат Xml, упаковку этих данных в SOAP-пакеты и использование протокола SOAP для отправки этих пакетов).
Иногда понятие обмена данными расширено настолько, что включает в себя стандарты безопасности, средства аудита, архивирования, синхронизации данных и т.п. К примеру, модули, ответственные за обмен EDI данными, представляют из себя целые системы, состоящие из множества частей и удовлетворяющие множествам EDI стандартов. Одних только схем EDI в составе BizTalk поставляется несколько тысяч. Для обмена данных BizTalk включает в себя большое количество адаптеров, как простых (File, SOAP, FTP), так и сложных (SAP, J.D.Edvards, HL7…).

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

Обычно операция получения схем недооценивается, особенно в BizTalk. Но попробуйте сами создать парсер для преобразования csv файла в XML. Попробуйте найти утилиту, которая это сделает корректно.  То же касается и SQL процедур и таблиц.

BizTalk делает очень много, чтобы предоставить или создать девелоперу качественные XML схемы.

Преобразование форматов

Другая сторона обмена данных – это преобразование форматов данных между системами. В BizTalk преобразование данных реализуется так: все внешние форматы данных преобразуются к одному внутреннему формату — Xml. Все адаптеры осуществляют такое преобразование, как в одну, так и в другую сторону. Сообщения в формате Xml описываются схемами — Xsd. Чтобы осуществить структурные преобразования, то есть когда требуется часть данных поменять местами, часть данных удалить и т.п, используется стандарт Xslt. Документ Xslt (карта — map) описывает, как исходный (source) XML документ преобразовывается в конечный (destination) XML документ. BizTalk имеет для этих целей два редактора: Schema Editor и Mapper. Первый редактирует и создает Xsd схемы, второй –Xslt преобразования.

Маpper – это один из лучших редакторов в мире для создания Xslt преобразований.

Бизнес процессы

Microsoft добавило в BizTalk средства, которые имеют более широкое использование, чем просто обмен данными. Это Business Process Orchestration – бизнес процессы «между системами». Тут нужно отметить, что большая часть бизнес процессов должна происходить внутри систем, не между ними, не между интегрируемыми системами. Но это в идеале. В реальной жизни, приходится встраивать бизнес процессы между системами. Но всегда помните, что это не совсем правильный подход.

Вернемся к тому, как бизнес процессы реализуются в BizTalk. В BizTalk встроены следующие средства: редактор для создания бизнес процессов и среда выполнения этих процессов. К примеру, нам потребовалось создать систему, координирующую продажи товаров. Сейчас система состоит из нескольких независимых приложений. Одно приложение этой системы инициирует обработку, например выдает счет на товары. Другие приложения отвечают за утверждение счета, комплектации заявки на отгрузку товара, комплектации отгрузки, обработки сопутствующих финансовых транзакций. Все эти приложения могут быть независимы друг от друга, могут даже принадлежать разным компаниям. В BizTalk создается координирующие программы, бизнес процессы, Orchestration, которые и управляют всем бизнес процессом. Запуск бизнес процесса, а значит и Orchestration инициируется одним из внешних приложений. Orchestration запрашивает у других приложений недостающие данные, дает им задания на обработку, и таким образом интегрирует их в один бизнес процесс. Когда все данные введены и обработаны, Orchestration завершает процесс. Orchestration может ожидать данные от других программ дни, а то и месяцы. Интересно то, что одновременно могут работать многие тысячи экземляров Orchestration для многих тысяч заявок.
Возникающие при этом проблемы очень интересны и на практике бывают довольно сложны в реализации: это и обеспечение бесперебойного восстановления системы после сбоев оборудования, и обеспечение стабильной работы большого количества приложений, обеспечение синхронизации тысяч документов, программ, партнеров и т.д. Простая интеграция, когда данные берутся из одного источника, преобразуются в формат другой программы и передаются этой программе, не решает проблемы асинхронной обработки. Что будет, если принимающая данные сторона временно не работает? Что делать, если исходная системы выдала несколько комплектов данных, а принимающая сторона все еще не работает или не успевает их принять в том же темпе? Business Process Orchestration решает и эти проблемы.
BizTalk предоставляет среду, которая ответвечает за создание огромного количества процессов, за управление этими процессами. BizTalk предоставляет специальный редактор Orchestrations, позволяющий моделировать разнообразные бизнес процессы с помощью простых блок-схем.
Основное применение Orchestrations — координация обработки интегрируемых данных, а не только согласование форматов данных. Это консолидация данных из разных источников, реализация бизнес логики по промежуточной обработке данных, синхронизация данных из разных источников, поддержка транзакций и т.п. Создана теория и несколько стандартов, посвященных именно долгоживущим процессам, называющимися Long Running Transactions. Основные игроки в данном сегменте, это IBM, Microsoft, Siebel, TIBCO и ряд других.

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

Инструментарий разработчика

BizTalk можно рассматривать с двух сторон: С одной стороны — это инструментарий разработчика, включающий в себя многочисленные редакторы (схем, maps, Orchestrations…). Часть средств BizTalk работают, как независимые программы, но большая часть средств — как редакторы в Microsoft Visual Studio. Все о чем я говорил выше, относится как раз к инструментарию разработчика.

Среда выполнения

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

Поподробнее

Среда выполнения частично состоит из .NET кода, работающего на нескольких Windows services (это — BizTalk application servers), частично из SQL баз данных, таблиц, процедур, jobs и много другого (это — SQL Servers). Обе части могут работать в кластерах, либо все — на одном компьютере. Сервера приложений кластеризуются средствами самого BizTalk. Добавить сервер — тривиальная задача. Весь код создан для работы в полностью автоматическом режиме. Система восстанавливается автоматически после сбоев питания, сети и других неприятностей.

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

Один из нюансов использования BizTalk состоит в том, что он используется прежде всего для интеграции систем в автоматическом режиме, для интеграции программ с минимальным участием человека. Одни приложения поставляют данные, другие их потребляют. В промежутке располагается BizTalk Server, который согласовывает форматы обмена, координирует обмен данных и их обработку. Обычно система на базе BizTalk работает без участия человека. BizTalk – это типичная back-end система. Ее многочисленные и мощные средства для разработчика контрастируют с минимальным набором средств для оператора, которому надо лишь в ограниченных пределах наблюдать за работающей системой, подстраивать ее. В BizTalk есть четкое деление между средой разработки (development) и средой исполнения (runtime).

Чтобы продемонстрировать надежность BizTalk, я демонстрирую простую операцию. Я запускаю на обработку побольше данных, после чего просто выключаю сервер. Выдергиваю вилку из разетки. Еще не разу не было такого, чтобы после включения сервера пропало хоть одно сообщение. Пробовал я такое и на кластере BizTalk серверов. Результат тот же, 100% надежность.

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

Типичные примеры использования BizTalk:

Синхронизация данных между системами

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

Синхронизация данных между приложениями в реальном масштабе времени

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

Композитный распределенный сервис

Приложение обращается к Web-сервису за данными. Web-сервис запускает BizTalk процесс, который обращается к другим Web-сервисам за дополнительными данными, после чего консолидирует данные и выдает их первому приложению. (Это типичный пример создания композитных Web-сервисов.)

RFID

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

Реклама

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

Filed under BizTalk, BizTalk course

BizTalk: Соглашения об именах в примерах

Вначале можно ознакомиться со статьей BizTalk: BizTalk Solution Naming Conventions.

В небольших  приложениях мы особенно не беспокоимся об именах. Когда же количество объектов приложения начинает расти, мы вынуждены начать думать об именах. Опытного разработчика, работавшего с большими проектами, можно распознать по тщательно и досконально продуманным именам в коде. Это верно на 200% . Программист может со скоростью мысли писать изощренный код , но, если он не думает об именах, он никогда не делал большие проекты.

Когда девелопер начинает работать в новой команде, он/она проводит вначале много часов, читая документацию, и «Соглашения об именах» (Naming conventions) обычно — важная часть этой документации. Потом он/она начинает разработку и опять часть времени уходит на ознакомление со существующим кодом, чтобы вникнуть в действующие стандарты кодирования. И опять, Соглашения об именах — важная часть этого процесса.

Документированные Соглашения об именах важны, но реальный код не менее важен. Документация может устареть, код всегда актуален. И код более нагляден.

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

Описание примера

Этот BizTalk код состоит из многих BizTalk приложений (applications). Каждое из приложений состоит в свою очередь из 1-10 Visual Studio проектов (projects). Эти приложения были разработаны в течении многих лет разными группами разработчиков. Приложения интегрируют несколько систем. Некоторые системы имеют только один интерфейс, некоторые — несколько интерфейсов. В большинстве случаев интерфейс одной системы интегрирован с интерфейсом другой системы. Иногда несколько систем интегрированны с одним интерфейсом системы.

Для этого примера было выбрано одно приложение (solution) . Еще раз акцентирую, это приложение из реальной жизни. Почему это приложение, GLG.Samples.Name.Shared.Schemas, было создано в данной ситуации? 

Как известно, интерфейсы в BizTalk определяются с помощью протокола и одной или нескольких XML cхем (schemas). Во многих случаях эти схемы диктуются самими интегрируемыми системами, а не разработчиками приложений. Обычно разработчик использует Adapter Wizard, чтобы сгенирировать/импортировать эти схемы. Эти схемы определяются и при необходимости меняются не разработчиками BizTalk приложения, а создателями и хозяевами интегрируемых систем. В дальнейшем такие схемы я буду называть внешними (external schemas).

Одна из интересных характеристик внешних схем то, что они могут использоваться несколькими BizTalk приложениями. Я однажды уже писал, что схемы, используемы в портах, должны быть уникальными (receive locations should be unique), они не могут содержаться одновременено в нескольких установленных библиотеках (deployed assemblies). Это означает, что если нам надо использовать одну и ту же схему в нескольких проектах, мы должны установить одну общую (shared) библиотеку один раз, не больше, и ссылаться на нее из всех этих проектов. 

Данное ограничение заставляет обращать особое внимние на организацию и тщательную проработку общих библиотек.

Обычно используется следующий дизайн: Все внешние схемы размещены в отдельном приложении Visual Studio. В данном примере схемы сгруппированы по системам. Внутри каждой системы схемы сгруппированы по имени интерфейса. Группировка схем и лежит в основе Соглашения об именай.

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

Викторина 🙂 по деталям реализации:

  1. Нормально ли, когда имена скомпонованы из четырех и даже более частей, наподобие GLD.Samples.Names.Shared.Schemas?
  2. Необходим ли GLD.Samples префикс для имен BizTalk приложений?
  3. Почему мы используем суффикс _Ops в именах проектов SystemA, SystemB, и SystemC?

(Попытайтесь ответить на эти вопросы самостоятельно. Я дам мои ответы в конце статьи.)

В данном примере рассмотрены два варианта Соглашений об именах. Я назвал их Длинные имена и Короткие имена.

Длинные имена

Картинка из Solution Explorer (все картинки взяты из BizTalk Server 2013):

Solution.Long

Это картинка папок:

Folders.Long

Короткие имена

Это картинка из Solution Explorer:

Solution

Это картинка папок:

Folders

Сравнение соглашений

Соглашение Короткие Имена выглядит изящнее. Здесь нет общих префиксов (GLD.Samples.Names.Shared.Schemas) внутри имен проектов и файловых папок. Если вы сражаетесь с хорошо известным ограничением Visual Studio TFS на общий размер имен файлов, это соглашение будет предпочтительным вариантом.

Я предпочитаю Длинные Имена (Полные имена). В этом случае имена проектов абсолютно такие же как .NET namespace у этих проектов и такие же, как имена билиотек (assembly). Полные имена проектов лучше в ситуациях, когда имена проектов могут быть включены одновременно в несколько Visual Studio приложений (solutions) или когда приложения часто перемещаются между приложениями. Срабатывает закон KISS (keep it simple stupid). В данном случае соглашение Длинные имена позволяет обходиться одним соглашением для многих объектов. Закон KISS неимоверно важен в больших проектах. Простота обходится дорого, сложность рождается бесплатно. За простоту приходится сражаться. В данном случае наблюдается некий пародокс, простота достигается не короткими именами, а длинными.

Еще одна важная причина в том, что с полными именами быстрее работать, так как проще копировать имена без изменений и не тратить время на применения правила для сокращения длины имени для разных объектов.

Имена BizTalk приложений (Applications)

Это картинка Административной Консоли (BizTalk Administration Console):

BizTalkAdminConsole

Вы видите Visual Studio приложение (solution) GLD.Samples.Names.Shared.Schemas установлено (deployed) как  Names.Shared.Schemas приложение (application). Префикс GLD.Samples удален, так как все устновленные VS приложения используют этот префикс. Если все артифкты используют одну и ту же часть имени, эта часть совершенно однозначно может быть удалена. Не должна быть удалена, а может быть удлалена. Возникает вопрос, почему эта часть не удалена из имени приложения/проекта (solution/project)? Причина в том, что проекты и assemblies практически всегда именуются одинаково. Но assemblies работают в одном глобальном пространстве имен вместе с system, Microsoft и другими assemblies, в едином пространстве имен .NET run-time. В этом глобальном пространстве имен префикс GLD.Samples помогает нам находить наши assembles. Получается, что глобальное пространство имен assemblies вынуждает нас использовать этот префикс, что, в свою очередь, вынуждает нас использовать этот префикс для имен проектов. Это и есть обещанный ответ на второй вопрос. Smile

В результате я использовал соглашение с Короткими именами для имен BizTalk приложений. 

Насколько сложной может быть иерархия имен?

Для примера возьму имя GLD.Samples.Names.Shared.Schemas.Sap.AV_CREDIT_STATUS_MODIFY. Не слишком ли оно сложное и длинное?

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

Иерархические соглашения об именах — короли в BizTalk разработке. Эти соглашения отражают группировку объектов. Иерархические соглашения работают хуже в тех областях, где объектов мало и они логически не связаны. Здесь лучше работают соглашения, основанные на ключевых словах (keys or tags).

Обычно мы видим такую картину:

  • простые, небольшие проекты: соглашения об именах либо отсутствуют либо покрывают только часть объектов
  • большие проекты: иерархические соглашения об именах. Одна иерархия для всего проекта.
  • очень большие проекты: соглашения об именах, основанные на ключевых словах, либо несколько иерархический соглашений об именах для одинаковых объектов, но для разных частей проекта.

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

Надеюсь, я ответил на первый вопрос.

Теперь ответ на третий вопрос. Сразу уточню, что этот вопрос относится только к BizTalk проектам.
Почему был использован суффикс _Ops для проектов SystemA, SystemB и SystemC?

 Например, почему было использовано имя GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck_Ops, а не имя GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck ?

Проблема с этим именем в том, что проект содержит схему с именем CreditCheck. Что плохого в этом, почему мы не не можем использовать одинаковое слово для части имени проекта и для схемы?

XML схема (XML schema) сериализуется в .NET класс и имя схемы сериализуется в имя класса. В результате мы имеем класс с полным именем (full qualified name) GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck.ChreditCheck. И когда мы компилируем проект мы получаем ошибку:

Error.SymbolXIsAlreadyDefined

Описание (description) ошибки могло бы быть чуть понятнее, что-нибудь типа: “symbol ‘GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck’ is already defined; the first definition is in assembly…”.

По какой-то причине .NET builder разбирает имена иногда слева направо, а иногда справа налево, что и приводит к подобным ошибкам.

Это деталь реализации, но мы вынуждены из-за нее изменить наше соглашение об именах. Имя схемы мы не можем изменить (это внешняя схема), а вот имя проекта мы изменить можем. Добавили _Ops (operations) и это разрешило конфликт одинаковых имен.

Выводы

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

Из моего опыта: идеальных Соглашений об именах не бывает, всегда надо исходить из разумных компромисов.

Оставьте комментарий

Filed under BizTalk, BizTalk course, Integration Architecture

BizTalk: маппинг с помощью Xslt

BizTalk Map редактор (Mapper) — хороший редактор, особенно в последней 2010 версии. Но и он иногда не справляется с некоторыми видами маппинга. Когда это случается, самое время вспомнить про Xslt код. Самое время вспомнить, что maps базируются на Xslt коде и выполняются с помощью Xslt парсера.

Щелкните правой клавишей по Mapper Grid (полю между схемами) и выберите команду Properties /Custom XSLT Path.  Введите имя файла с Xslt кодом. Теперь будет выполняться только код из этого файла, забудьте про все связи и функтоиды на картинке Маппера.

Вот пример из реального проекта.

Посмотрим налево на исходную схему. В ней есть два исходных адреса (Address_1, Address_2, City, Zip). Один на верхнем уровне исходной схемы, другой на внутри записи Member_Address с параметром MaxOccurs=* (это означает, что запись может повторяться неограниченное количество раз).

Результирующий адрес расположен внутри записи Locator также с параметром MaxOccurs=*.

Map.Pict

Нам надо трансформировать все исходные структуры адреса в одну результирующую структуру.

К примеру, исходный XML документ выглядит так:

Source.Xml

Тогда результирующий XML документ должен выглядеть так:

Output.Xml

То есть один адрес верхнего уровня и два адреса нижнего уровня преобразовались в три адреса на одном и том же уровне.

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

Попробуем сделать это же с помощью Xslt кода и получим простой и однозначный маппинг:

Xslt

Просто и элегантно.

4 комментария

Filed under BizTalk, BizTalk course

BizTalk: Вопросы для интервью максимальной сложности

Эта подборка вопросов — 6 часть из серии «Вопросы для интервью».

Пора повеселиться 🙂

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

Буду рад, если вы напишете свои варианты ответов в комментариях. Спасибо!

Я буду помечать вопросы, на которые поступили интересные / правильные ответы.

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

Оставьте комментарий

Filed under BizTalk, BizTalk course, Certification, Работа

BizTalk course: 10 Orchestrations

Theory:

Теории здесь на несколько дней.

Practice:

  1. В Проект №1 (совсеми последующими улучшениями) добавить orch OrderShipping, которое принимает все OrderDetails, адресованные отдельной ShippingCompany. Сделать его, используя шаблон Unified Sequencial Convoy. Первое сообщение OrderDetails будет активировать отдельную orch instance для отдельной ShippingCompany. Последующие сообщения OrderDetails будут обрабатываться этой же instance. Все OrderDetails объединяются в одно сообщение OrderDetailsSummary (cделать схему этого сообщения).  OrderDetailsSummary завершается после объединения 5 сообщений OrderDetails ИЛИ через 10 минут после старта. OrderDetailsSummary выводится в FILE Send port.
  2. Добавить еще один FILE Send port, который будет отлавливать и выводить сообщения FailureReport. Смоделировать ошибки в orch  и убедиться что информация об ошибке доставляется на этот порт.
  3. Добавить SMTP Send port, который будет отлавливать и отправлять по почте информацию об ошибках.
  4. Tracing: во все orch добавить Expression shapes в след.местах: в начале/конце orch; после создания/receive/send всех сообщений; после ветвления в шейпах с несколькими ветвями; после начала каждого нового цикла в Loop. В Expression shapes добавить вывод отладочной информации: содержимое новых сообщений, измененных переменных и т.п. Использовать DebugView, чтобы вывести эту отладочную информацию.
  5. Tracking: включить полный Tracking для всех orch и портов. Отследить: прохожение сообщений; содержимое сообщений во всех возможных точках; контекст сообщений.
  6. to be continued…

Практики по этой части будет еще много.

3 комментария

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 09 Maps

Что учим:

Maps: практика и еще раз практика. Теории здесь мало.

Основные моменты в трансформациях:

  • Изменения в уровнях вложенности.
  • Schema paremeters: MinOccurs and MaxOccurs
  • Преобразования в/из Empty и Null значения.
  • Условные преобразования
  • Коды, их использование, генерация, lookup
  • Script functoids: in-line code; Xslt-code; Xslt-templates
  • Использование pure Xslt.

Задания:

  1. Сделать map схемы Order.xsd в схему ShippingOrder.xsd. Это пример на трансформацию схемы с глубокой иерархией узлов в так называемую «плоскую» схему. [Файлы схем надо сохранить и переименовать, удалив .doc в конце.]
  2. Сделать обратное преобразование: map схемы ShippingOrder в Order.
  3. Условные преобразования: При преобразовании из п.1 использовать такую логику: TotalAmount = Quantity * Price * (100%+Tax). Tax определяется по полю CompanyOriginator.Address.StateProvince: если WA, то Tax = 10%, если CA, то Tax = 8.5%, если BC, то Tax = 12%. Могут быть только три вышеперечисленных значения.
    1. при преобразовании использовать только обычные фанктоиды. Script functoid не испльзовать.
    2. использовать Script functoid: Inline C#
    3. использовать Script functoid: Inline Xslt
    4. использовать Script functoid: Inline Xslt call template
  4. В Order_to_ShippingOrder map для nodes OrderDetail.item и company name добавить дополнительную логику: если node is Null, то в ShippingOrder должно получиться не Null, а Empty string, т.е.пустая строка («»). Соответсвенно изменить схему Order, чтобы эти nodes могли быть null. Использовать те же четыре метода из предыдущего пункта.
  5. В Order_to_ShippingOrder map для nodes Order. добавить дополнительную логику: если StateProvince в полном виде (к примеру Washington), то сделать преобразование в кодWA. Если уже WA, то использовать то, что есть. Если ошибка в StateProvince, то использовать то, что есть. Только для тех StateProvince, которые перечислены в п.3.
  6. Повторить п.5, но для преобразования сделать и использовать  дополнительный C# проект …Helper , класс MapHelper.

В качестве образца с удовольствием рекомендую проект Андрея Кошелева.

5 комментариев

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 08 Web-services

Что учим:

  • Создание Web-service (WS)
  • Интеграция BizTalk с WS
    • Publishing WS — Создание WS из BizTalk
    • Consuming WS — Обменн данными между WS и BizTalk

 Одна из важнейших частей системной интеграции — Web-services (WS). Для начала сделайте Лабораторную работу (см.ниже 1), потом почитайте немного теории. Чтобы сделать следующие (см.ниже 2 и 3) примеры, вам понадобится установить Windows Samples. Здесь инструкции по загрузке и установке. Сами примеры небольшие и не загромождены частностями.

BizTalk может делать (publish) WS на базе Orch, т.е.он показывает Orch внешнему миру, как будто это WS. Кроме этого он может использовать (consume) WS, т.е. запрашивать и получать данные у WS.

Для независимой отладки WS чаще всего используется утилита SoapUI. Ее бесплатную версию желательно скачать и установить.

Все это может занять 4-10 часов.

Практика:

  1. MSDN Virtual Lab: BizTalk Server 2009: Using the WCF Adapters in BizTalk Server 2009
  2. Windows Communication Foundation (WCF). Getting Started sample
  3. Windows Communication Foundation (WCF). Getting Started Tutorial

Теория

  1. Windows Communication Foundation (WCF) Conceptual Overview
  2. BizTalk Server 2010: Using Web Services
  3. BizTalk: Document: Consuming and Exposing Web Services from an Orchestration

Оставьте комментарий

Filed under BizTalk, BizTalk course, WCF

BizTalk course: 07 Проект №1; Вариант 2

Что учим:

  • disassembling (debatching) Variant 2
  • сложные solution
  • deployment нескольких проектов
  • система имен solution, projects, assemblies

Требования:

  • Проект 1, предыдущий вариант, оставляем без изменений. Новый проект делаем с нуля, copy-past не используем.
  • Disassembing в проекте 1.2 делаем по другому варианту, в сравнении с проектом 1.1. Т.е.если в 1.1 использовался disassembing в pipeline with envelope schema, то в 1.2 используется debatching в orch.
  • Проект сегментируем и все его атрифакты раскладываем по нескольким Projects. Отдельный project для Schemas, отдельный для Maps, и т.д. для Orch-s, если есть.
  • Задаем Project Properties:
    • Deployment / Application Name: <Initials>.Samples.Debatching
    • Application /Assembly name, / Default namespace: <Initials>.Samples.Debatching.<ProjectName>
  • Имена у проектов такие:
    • <Initials>.Samples.Debatching.Schemas
    • <Initials>.Samples.Debatching.Maps
    • <Initials>.Samples.Debatching.Orchestrations
      — где <Initials>, например для меня будут LG, имя проекта LG.Samples.Debatching.Schemas
  • [Xml] Target namespaces для Schema: http://<initials>.samplas.debatching.schemas/<date>
  • [.NET] namespaces:
    • для Maps-s: <Initials>.Samples.Debatching.Maps.<MapName>
    • для Orch-s: <Initials>.Samples.Debatching.Orchestrations.<OrchName>
  • Добавляем в проекты нужные ссылки на другие проекты. К примеру, project Maps должен иметь ссылку на project Schemas.
  • Application отлаживаем и deploy.

Подробно об использовании имен см. BizTalk: Naming convention for the BizTalk solutions

Теория

Надо прочитать за пару дней основы архитектуры BizTalk.

Оставьте комментарий

Filed under BizTalk, BizTalk course

BizTalk course: 07 Проект №1

Проект №1

User Requirements:

  • Система обработки заказов
  • Xml документы  Order приходят от разных заказчиков в файловый фолдер.
  • Order состоит из шапки и из нескольких Order Detail строк. Каждая строка – это описание заказа для отдельного продукта.
  • Есть три типа продуктов. Продукт каждого типа поставляет отдельная Shipping компания.
  • Xml документы Shipping доставляются в виде файлов в файловые фолдеры. Есть три фолдера, каждый для отдельной Shipping компании.

Implementation requirements

  • Из каждого документа Order делается несколько документов Shipping. Один Shipping на каждую Order Detail строку.
  • Для преобразования  Order в Shipping-s обычно используется два метода:
    • Disassemble в pipeline, используя envelope cхему (google with “BizTalk disassembler”)
    • Disassemble в orchestration, преобразовывая сообщение в объект XmlDocument , далее в string, потом выделяя Order Detail помощью XPath выражения. Т.е.манипуляцией strings. (google with “BizTalk debatching”)
  • Используйте любой из методов, на свое усмотрение. Как это делать, найдите в интернете. Можете использовать код в BizTalk SDK и код из многочисленных блогов.
  • Прочитайте теорию в http://msdn.microsoft.com/en-us/library/aa577393(v=BTS.70).aspx . Не забудьте прочитать все статьи включающие в себя вышеназванную статью.
  • Схемы для Order, Order Detail,  Shipping делайте на свое усмотрение. Maps – тоже.
  • Проект считается готовым, когда тестовые файлы пройдут от входного фолдера  к выходным фолдерам.
  • Мне пришлите файлы проекта в zip файле.  Кроме того пришлите мне сэкспортированные отдельные файлы deployed application: msi и bindings.
  • Время на весь проект: для опытного BizTalk developer – 1 час, для entry level — >5 часов.

Дополнение: Вначале я задал требование по созданию Canonical Order. Это требование отменяется.

4 комментария

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 06

1. Virtual Lab http://www.microsoft.com/biztalk/en/us/virtual-labs.aspx
BizTalk Server 2009: Integration with  POP3 and SharePoint and Routing Failed Messages

2. Отвечаем на вопросы:

  • Как можно принять сообщения в BizTalk используя email?
  • Как можно отправить сообщения из BizTalk используя email?
  • Почему для принятия и отправки сообщений email используются разные адаптеры?
  • Как можно принять/отправить Xml сообщение, используя email?
  • Приведите 3 сценария, когда нам нужно использовать именно email и ничто другое.
  • Чем email адаптеры отличаются от FILE адаптера?

6 комментариев

Filed under BizTalk, BizTalk course, Microsoft