Подходы к миграции для BizTalk Server в Azure Logic Apps
В этом руководстве рассматриваются стратегии миграции и ресурсы, а также рекомендации по планированию и рекомендации по обеспечению успешной миграции.
Примечание.
Обзор миграции и руководство по выбору служб в Azure для миграции см. в следующей документации:
Параметры стратегии
В следующих разделах описаны различные стратегии миграции, а также их преимущества и недостатки.
Большой взрыв
"Большой взрыв" или "прямая смена" — это подход, который требует большого количества планирования и не рекомендуется для организаций, которые не знакомы с Azure Logic Apps или имеют большие системы или решения для миграции. Когда организация реализует новый стек технологий, новые учебные курсы обычно часто приводят к результату. Инвестируя слишком рано или слишком много, у вас не будет возможности воспользоваться уроками, полученными и адаптироваться без риска значительных переработок.
Этот подход также может занять больше времени для получения или получения значения. Если вы уже выполнили некоторые действия миграции, но вы еще не выпустили их в рабочую среду из-за других ожидающих или выполняемых работ, перенесенные артефакты не создают значение для вашей организации.
Мы рекомендуем использовать этот подход только в том случае, если у вас есть небольшие рабочие нагрузки BizTalk с низкой сложностью, эксперты по темам (SMEs), которые знают среду BizTalk, и прямые сопоставления между функциями BizTalk, которые в настоящее время используются и Azure Logic Apps. Опыт работы с Azure Logic Apps также значительно снижает риски с помощью этого подхода.
Итеративная или волна на основе (рекомендуется)
Этот подход позволяет организации постепенно достичь ценности, но раньше, чем в противном случае. Ваша команда проекта может узнать о стеке технологий рано, используя ретроспективы. Например, можно развернуть существующий интерфейс BizTalk или проект в рабочей среде, а затем узнать о потребностях решения, включая управление, масштабируемость, операции и мониторинг. После получения этих знаний можно спланировать спринты для оптимизации существующих возможностей или внедрения новых шаблонов, которые впоследствии можно использовать в будущих работах.
Независимо от вашего подхода, если вы планируете перейти в Azure Logic Apps или Azure в целом, настоятельно рекомендуется рефакторинг решений BizTalk Server в бессерверные или облачные решения перед выводом инфраструктуры сервера. Этот выбор является отличной стратегией, если ваша организация хочет полностью преобразовать бизнес в облако.
BizTalk Server и Azure Logic Apps имеют разные архитектуры. Для дальнейшего модернизации решений можно использовать Службы Azure Integration Services для расширения возможностей в Azure Logic Apps, которые касаются основных потребностей интеграции клиентов.
Для повышения рентабельности инвестиций (ROI) рекомендуется использовать основные собственные возможности в Azure Logic Apps (цен. категория "Стандартный") как можно больше и расширено с другими службами Azure Integration Services по мере необходимости. Это сочетание позволяет использовать дополнительные сценарии, например:
- Облачные гибридные возможности с azure Logic Apps (стандартный) с гибридным развертыванием
- Возможности рабочего процесса с отслеживанием состояния или без отслеживания состояния в Azure Logic Apps (стандартный)
- Встроенная встроенная (в приложении) мейнфрейм и интеграция с соединителями в Azure Logic Apps (стандартная версия)
- Обмен сообщениями в pub-sub с помощью Служебная шина Azure
- Расширенные возможности SOAP в Azure Управление API
Доставка проекта миграции BizTalk
Чтобы завершить такой проект, рекомендуется следовать итеративному или волнообразному подходу и использовать процесс Scrum. Хотя Scrum не включает концепцию Sprint Zero (Sprint 0) для предварительной работы с спринтом, рекомендуется сосредоточиться на первом спринте на выравнивании команды и техническом обнаружении. После Sprint 0 следуйте выполнению нескольких спринтов миграции и сосредоточьтесь на выпуске функций к минимально жизнеспособному продукту (MVP).
Спринт 0
Во время этого спринта рекомендуется выполнить обнаружение сред BizTalk Server с помощью планирования волн. Понимание широты и глубины проекта имеет решающее значение для успеха. В следующем списке содержатся конкретные области, которые необходимо устранить во время Sprint 0:
| Область | Description |
|---|---|
| Обнаружение | Захватить данные обо всех интерфейсах и приложениях, чтобы узнать количество интерфейсов и приложений, которые необходимо перенести. Также необходимо назначить сложность каждому интерфейсу или процессу. Во время этого процесса каталогизации соберите следующие сведения, чтобы определить приоритеты работы: — используемые адаптеры — Функции BizTalk Server, такие как мониторинг бизнес-активности, подсистема бизнес-правил, EDI и т. д. — Пользовательский код, например выражения, карты и компоненты конвейера — пропускная способность сообщений - Размеры сообщений -Зависимости — зависимости приложений и системы |
| Проект архитектуры | Создайте высокоуровневую архитектуру для использования в качестве фокуса для миграции. Эта конструкция включает в себя элементы, которые решают высокоуровневые функциональные и нефункциональный потребности. |
| Минимальное определение жизнеспособного продукта (MVP) | Определите функции первой волны. Другими словами, процессы, которые нуждаются в поддержке после завершения первой волны. |
| Невыполненная миграция | Определите первые волны и их рабочие элементы с техническими разработками. |
Средства обнаружения
Чтобы помочь в обнаружении миграции, можно использовать программу командной строки Миграции интеграции Azure, которая также называется средством миграции BizTalk, который является проектом с открытым исходным кодом Майкрософт. В этом средстве используется поэтапный подход, помогающий выявить полезные аналитические сведения и стратегии миграции решений в облако. Мы рекомендуем использовать средство миграции только для обнаружения и создания отчетов. Вы также можете рассмотреть возможность использования других продуктов для обнаружения от партнеров, которые предоставляют решения в этом пространстве.
Для другого способа создания инвентаризации с помощью элементов BizTalk Server можно использовать BizTalk Documenter, разработанный Марком Бримблом. Это средство работает с BizTalk Server 2020, несмотря на то, что поддерживается только BizTalk Server 2016.
Проект архитектуры
Хотя Azure Logic Apps предоставляет возможности, позволяющие повторно использовать ресурсы BizTalk Server, необходимо иметь современную архитектуру, чтобы использовать преимущества более современных возможностей. С функциональной точки зрения используйте бизнес-логику как можно больше. С точки зрения модернизации продукта используйте службы Azure Integration Services столько, сколько вы можете. Для обеспечения качества и перекрестных проблем рекомендуется использовать Платформу Azure Well-Architected Framework.
В рамках этой платформы миграции BizTalk являются критически важными рабочими нагрузками. В этом термине описываются коллекции ресурсов приложений, требующих высокой доступности на платформе, то есть они всегда должны быть доступными, операционными и устойчивыми к сбоям.
Чтобы завершить проектирование архитектуры для миграции BizTalk, следуйте методологии проектирования критически важных рабочих нагрузок в Azure. Для начальной архитектуры и топологии просмотрите и используйте эталонную архитектуру, описанную в статье "Базовая корпоративная интеграция в Azure " в Центре архитектуры Azure.
Чтобы настроить исходную среду, используйте акселератор целевой зоны Служб Azure Integration Services, предназначенный для создания и развертывания платформы интеграции с использованием типичной целевой зоны предприятия.
Минимальное определение жизнеспособного проекта (MVP)
MVP — это версия продукта, которая имеет достаточно возможностей, доступных для использования клиентом. Эта версия показывает возможности и возможности продукта для сбора отзывов клиентов и продолжения работы. Для миграции BizTalk определение MVP отражает итерации, волны или группы спринтов, необходимых для выполнения рабочих функций и удовлетворения начальных рабочих нагрузок интеграции.
Мы рекомендуем включить определение MVP в следующие бизнес-результаты, которые выражаются как Эпичные в терминологии Scrum:
Бизнес-результаты (Эпические)
- Какова основная цель, которую вы хотите достичь?
- Какие возможности или функции необходимо использовать для этого MVP?
- Что такое потоки бизнес-процессов? Этот вопрос предоставляет возможность оптимизировать существующие процессы, поддерживаемые BizTalk Server.
- Каковы бизнес-решения, например, бизнес-результаты, влияющие на MVP, или что такое доступность ресурсов?
Рекомендуется включить MVP в следующие процессы в области, которые выражаются как функции в терминологии Scrum:
Процессы в области (функции)
| Возможность | Description |
|---|---|
| Высокоуровневые системные функции | Эти сведения можно извлечь с помощью средств обнаружения и выразить описания с точки зрения функций. |
| Актеры или лица | Используйте эти сведения для определения лиц, пострадавших от поддерживаемых сценариев MVP. |
| Взаимодействия | Эти сведения можно извлечь с помощью средств обнаружения. |
| Сущности и сообщения данных | Эти элементы дают возможность узнать, можно ли включить дальнейшие улучшения в обмен данными в среде BizTalk Server. |
| Сопоставление данных | Сегодня в мире используется JSON. Однако BizTalk Server использует XML. Этот момент является отличной возможностью решить формат данных и потребности преобразования для новой платформы. |
| Бизнес-правила | Эти правила, ориентированные на данные, открывают возможность переосмыслить свой подход или повторно использовать их, используя возможности Azure Logic Apps. |
| Рекомендации по конфиденциальности данных | Вы должны сделать конфиденциальность главным приоритетом. Если клиент не выбирает модель гибридного развертывания в Azure Logic Apps (стандартный), необходимо решить эту область в каждой волне из-за потенциальных изменений среды развертывания. |
| Рекомендации по регулированию | Этот аспект более релевантн, если у клиентов нет облачных рабочих нагрузок. |
| Защита на стадии проектирования | Необходимо разработать каждую функцию с учетом безопасности. |
| Предлагаемые функции для сосуществования | При доставке каждой волны у вас есть определенная степень сосуществования. Вы должны выровнять эту гибридную архитектуру с существующими индикаторами уровня обслуживания (SLIS) и целями уровня обслуживания (SLOS). |
| Нефункциональный аспект | Бизнес-процессы могут иметь разные нефункциональный требования. Не все должно происходить в режиме реального времени. И наоборот, не все это пакетный процесс. |
| Бизнес-метрики | Необязательная возможность показать ход выполнения для работы миграции. |
Вы также хотите определить и перечислить различные переменные вне области, которые формируют область работы MVP, например:
- Доступность ресурсов
- Риски
- Документация
- Ускорение выхода
Начальная невыполненная работа
Начальная невыполненная работа — это набор пользовательских историй, которые группируется в функции для создания процессов в области для MVP. Другими словами, MVP представлен элементами Scrum, известными как Epics, Features и User Stories. В идеале каждая эпопея включает в себя группу приложений BizTalk или проектов BizTalk. Можно использовать простое правило, которое связывает одно приложение BizTalk или проект BizTalk с функцией.
Например, предположим, что у вас есть проект BizTalk Server с оркестрацией "LoanRequests", которую клиенты используют для запроса банковских кредитов. Таким образом, у вас есть следующая предлагаемая функция и история пользователя:
Функция: обработка кредитов
Пользовательская история: "Как клиент, я хочу отправить заявку на кредит, чтобы банк может добавить средства в мой безопасный счет".
Эта история пользователя, которая в настоящее время может существовать в качестве реализации в BizTalk Server, имеет следующие задачи для реализации с помощью Azure Logic Apps и Служб Azure Integration Services:
- Сбор повторно используемых артефактов BizTalk.
- Создайте рабочий процесс запроса на кредит с помощью Azure Logic Apps.
- Настройте асинхронное обмен сообщениями с помощью Служебная шина Azure или IBM MQ.
- Сопоставление JSON с XML-данными с помощью рабочего процесса Azure Logic Apps.
- Настройте службы Azure Integration Services по мере необходимости для шаблонов обмена сообщениями.
На следующей схеме показаны предлагаемые длительности для эпических, функций, пользовательских историй и задач, которые подразделяют пользовательские истории. Хотя решения о реализации влияют на эти длительности, предполагается, что вы используете существующие артефакты BizTalk в Azure Logic Apps. Создайте стандартные рабочие процессы с помощью предварительно созданных шаблонов рабочих процессов как можно больше.
Волны миграции (Спринты)
После завершения работы команды Sprint 0 у вас должно быть четкое представление MVP для сборки. Волна — это набор спринтов. Начальная невыполненная работа должна включать рабочие элементы, которые следуют следующей схеме как можно больше:
Во время волны ваша команда завершает действия по миграции, тестированию и выпуску в рабочую среду. Давайте более подробно рассмотрим, что происходит в каждой волне.
Миграция
Во время каждой волны миграция фокусируется на согласованных историях пользователей. Для первой волны ваша команда фокусируется на первоначальной невыполненной работы. Технологические решения должны использовать сведения в сопоставлении функций BizTalk Server, описанные в сопоставлении компонентов. Почему переход с BizTalk Server на Azure Logic Apps?
На следующей схеме показаны события, которые должны произойти во время миграции волн:
| Этап | Описание: |
|---|---|
| 1 | Обнаружение существующих приложений и интерфейсов BizTalk. Хотя эта активность появилась в Sprint 0, это действие должно произойти при запуске каждой волны. Клиенты могут продолжать вносить изменения в среду BizTalk. Ресурсы: - Средство миграции BizTalk - Средство BizTalk Documenter |
| 2 | Настройте исходную среду миграции. Вы можете использовать акселератор целевой зоны Служб Azure Integration Services, который является платформой внедрения облака для создания и развертывания платформы интеграции с типичной структурой целевой зоны предприятия. Как владелец рабочей нагрузки, вы можете уверенно достичь целевого технического состояния с помощью предоставленных архитектурных рекомендаций и ресурсов миграции BizTalk. Пример архитектуры см. в примере среды миграции. |
| 3 | Создайте и проверьте рабочие процессы приложения логики уровня "Стандартный", которые выполняются в однотенантном Azure Logic Apps с помощью портал Azure или Visual Studio Code с расширением Azure Logic Apps (стандартный). С помощью Visual Studio Code вы можете локально разрабатывать, тестировать и хранить проект приложения логики с помощью любой системы управления версиями. Дополнительные сведения см. в следующей документации: - Создание примера рабочего процесса приложения логики уровня "Стандартный" с помощью портал Azure - Создание примера рабочего процесса приложения логики уровня "Стандартный" с помощью Visual Studio Code Схема, на которой показан пример приложения логики и подключений, см . пример среды миграции. |
| 4 | Чтобы получить полные преимущества от простого и согласованного развертывания рабочих процессов приложения логики уровня "Стандартный" в разных средах и платформах, необходимо также автоматизировать процесс сборки и развертывания. Расширение Azure Logic Apps (standard) для Visual Studio Code предоставляет средства для создания и обслуживания автоматизированных процессов сборки и развертывания с помощью Azure DevOps. Дополнительные сведения см. в статье "Автоматизация сборки и развертывания для рабочих процессов приложения логики уровня "Стандартный" с помощью Azure DevOps. |
| 5 | Чтобы развернуть критически важные приложения логики уровня "Стандартный", которые всегда доступны и реагируют даже во время обновлений или обслуживания, включите развертывание без простоя путем создания и использования слотов развертывания. Нулевое время простоя означает, что при развертывании новых версий приложения конечные пользователи не должны испытывать нарушения или простои. Дополнительные сведения см. в статье "Настройка слотов развертывания", чтобы включить развертывание без простоя в Azure Logic Apps. |
На следующей схеме показан пример начальной среды миграции со стандартным приложением логики, которое управляет рабочими процессами, взаимодействующими с API, службами, гибридными решениями и локальными ресурсами:
Тест
Каждая волна имеет собственные действия тестирования, внедренные в каждую историю пользователя. Если вы хотите использовать shift-left тестирование, убедитесь, что выполнены следующие задачи:
Автоматизация тестов.
Azure Logic Apps (цен. категория "Стандартный") включает возможность выполнения автоматического тестирования. В следующем списке содержатся дополнительные сведения и ресурсы, которые свободно доступны на сайте GitHub:
Автоматическое тестирование с помощью Azure Logic Apps (цен. категория "Стандартный") из команды Azure Logic Apps
При использовании Azure Logic Apps (стандартный) автоматизированное тестирование больше не сложно выполнить из-за базовой архитектуры, которая основана на среде выполнения Функции Azure и может выполняться в любом месте, где Функции Azure может выполняться. Вы можете написать тесты для рабочих процессов, которые выполняются локально или в конвейере CI/CD. Дополнительные сведения см. в примере проекта для Azure Logic Apps Test Framework.
Эта платформа тестирования включает следующие возможности:
- Создавайте автоматизированные тесты для комплексных функций в Azure Logic Apps.
- Выполните детальную проверку на уровнях выполнения рабочего процесса и действий.
- Проверьте тесты в репозитории Git и запустите локально или в конвейерах CI/CD.
- Макет возможностей тестирования для действий HTTP и соединителей Azure.
- Настройте тесты для использования различных значений параметров из рабочей среды.
Сборник схем интеграции: Стандартное тестирование Logic Apps от Майкла Стивенсона, Microsoft MVP
Платформа тестирования сборника схем интеграции основана на платформе тестирования, предоставленной корпорацией Майкрософт, и поддерживает дополнительные сценарии:
- Подключитесь к рабочему процессу в приложении логики "Стандартный".
- Получите URL-адрес обратного вызова, чтобы можно было активировать рабочий процесс из теста.
- Проверьте результаты выполнения рабочего процесса.
- Проверьте входные и выходные данные операции из журнала выполнения рабочего процесса.
- Подключитесь к платформам автоматического тестирования, которые могут использовать разработчики приложений логики.
- Подключитесь к SpecFlow для поддержки разработки на основе поведения (BDD) для приложений логики.
Независимо от того, какие подходы или ресурсы автоматизации используются, вы хорошо можете выполнять повторяющиеся, согласованные и автоматизированные тесты интеграции.
Настройте пробное тестирование ответа с помощью статических результатов.
Независимо от того, настроили ли автоматические тесты, можно использовать статическую функцию результатов в Azure Logic Apps для временной настройки макетов ответов на уровне действия. Эта функция позволяет эмулировать поведение определенной системы, которую вы хотите вызвать. Затем можно выполнить некоторое первоначальное тестирование в изоляции и уменьшить объем данных, создаваемых в бизнес-системах.
Выполняйте параллельные тесты.
В идеале у вас уже есть базовые тесты интеграции для среды BizTalk Server и установлены автоматизированные тесты для Azure Logic Apps. Затем можно выполнять тесты параллельно, помогая проверять интерфейсы с помощью одних и тех же наборов данных и повысить общую точность тестирования.
Выпуск в рабочую среду
Завершив работу команды и выполнив "определение готового" для пользовательских историй, рассмотрите следующие задачи:
Создайте план связи для выпуска в рабочую среду.
Сделайте план "вырезать".
План вырезки охватывает сведения о задачах и действиях, необходимых для перехода с текущей платформы на новую платформу, включая шаги, которые планирует выполнить ваша команда. Включите следующие рекомендации в план вырезки:
- Предварительные действия
- Репетиция платья
- Люди
- Планирование оценки
- Отключение интерфейсов на старой платформе
- Включение интерфейсов на новой платформе
- Тестирование проверки
Определите план отката.
Выполните тестирование проверки.
Планирование операций или рабочей поддержки.
Выберите критерии "Перейти или нет" для выпуска в рабочую среду.
Празднуйте успех вашей команды.
Удерживайте ретроспективу.
Рекомендации по миграции BizTalk
Хотя рекомендации могут отличаться в разных организациях, рассмотрите сознательные усилия по повышению согласованности, что помогает сократить ненужные усилия, которые «переуздать колесо» и избыточность аналогичных общих компонентов. Когда вы помогаете включить повторное использование, ваша организация может быстрее создавать интерфейсы, которые становятся проще поддерживать. Время на рынок является ключевым фактором для цифрового преобразования, поэтому главный приоритет снижает ненужные трения для разработчиков и групп поддержки.
При создании собственных рекомендаций рассмотрите возможность согласования со следующими рекомендациями:
Общие соглашения об именовании ресурсов Azure
Обязательно настройте и последовательно применяйте хорошие соглашения об именовании для всех ресурсов Azure из групп ресурсов к каждому типу ресурсов. Чтобы создать прочный фундамент для обнаружения и поддержки, хорошее соглашение об именовании сообщает цель. Наиболее важным моментом для соглашений об именовании является то, что у вас есть, и что ваша организация понимает их. У каждой организации есть нюансы, которые они могут учитывать.
Рекомендации по этой практике см. в следующих рекомендациях и ресурсах Майкрософт:
- Примеры аббревиации для ресурсов Azure
- Средство именования Azure, которое создает имена, совместимые с Azure, помогает стандартизировать имена и автоматизировать процесс именования.
Соглашения об именовании ресурсов Azure Logic Apps
Проектирование приложения логики и рабочего процесса обеспечивает ключевую отправную точку, так как эта область обеспечивает гибкость для разработчиков для создания уникальных имен.
Имена ресурсов приложения логики
Чтобы различать ресурсы приложения логики "Потребление" и "Стандартный", можно использовать различные сокращения, например:
- Потребление: LACon
- Стандартный: LAStd
С точки зрения организации можно разработать шаблон именования, включающий бизнес-подразделение, отдел, приложение и, при необходимости, среду развертывания, например DEV, UATPRODи т. д., например:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Предположим, что у вас есть стандартное приложение логики в разработке, которое реализует рабочие процессы для отдела кадров в бизнес-подразделении корпоративных служб. Вы можете присвоить ресурсу приложения логики LAStd-CorporateServices-HR-DEV и использовать нотацию Pascal Case, если это подходит для согласованности.
Имена рабочих процессов приложения логики
Ресурс приложения логики потребления всегда сопоставляется только с одним рабочим процессом, поэтому вам нужно только одно имя. Ресурс приложения логики уровня "Стандартный" может включать несколько рабочих процессов, поэтому создайте соглашение об именовании, которое также можно применить к рабочим процессам членов. Для этих рабочих процессов рассмотрим соглашение об именовании на основе имени процесса, например:
Process-<*process-name*>
Таким образом, если у вас был рабочий процесс, реализующий задачи подключения сотрудников, например создание записи сотрудника, можно присвоить имя рабочему процессу Process-EmployeeOnboarding.
Ниже приведены дополнительные рекомендации по проектированию соглашения об именовании рабочих процессов:
- Следуйте шаблону родительского дочернего элемента для рабочих процессов, в которых необходимо выделить связь между одним или несколькими рабочими процессами.
- Учитывайте, публикуется ли рабочий процесс или использует сообщение.
Имена операций рабочего процесса
При добавлении триггера или действия в рабочий процесс конструктор автоматически назначает универсальное имя по умолчанию для этой операции. Однако имена операций должны быть уникальными в рабочем процессе, поэтому конструктор добавляет последовательные числовые суффиксы в последующих экземплярах операций, что затрудняет удобочитаемость и расшифровку исходного намерения разработчика.
Чтобы сделать имена операций более понятными и понятными, можно добавить краткий дескриптор задачи после текста по умолчанию и использовать нотацию Pascal Case для согласованности. Например, для действия Parse JSON можно использовать имя, например Parse JSON-ChangeEmployeeRecord. При таком подходе или других аналогичных подходах вы будете помнить, что действие является анализом JSON и конкретной целью действия. Таким образом, если вам нужно использовать выходные данные этого действия позже в подчиненных действиях рабочего процесса, вы можете легко определить и найти эти выходные данные.
Примечание.
Для организаций, которые широко используют выражения, рассмотрите соглашение об именовании, которое не способствует использованию пробелов ('). Язык выражений в Azure Logic Apps заменяет пробелы символами ('_') подчеркивания, что может усложнить разработку. Избегая заранее пробелов, вы помогаете сократить трение при создании выражений. Вместо этого используйте дефис или дефис (-), который обеспечивает удобочитаемость и не влияет на разработку выражений.
Чтобы избежать последующих возможных переработок и проблем с подчиненными зависимостями, которые создаются при использовании выходных данных операций, переименуйте операции немедленно при их добавлении в рабочий процесс. Как правило, подчиненные действия автоматически обновляются при переименовании операции. Однако Azure Logic Apps не переименовывает пользовательские выражения, созданные перед выполнением переименования.
Имена подключений
При создании подключения в рабочем процессе базовый ресурс подключения автоматически получает универсальное имя, например SQL или Office365. Как и имена операций, имена подключений также должны быть уникальными. Последующие подключения с тем же типом получают последовательный числовый суффикс, например sql-1, sql-2 и т. д. Такие имена не предоставляют никакого контекста, что делает разными и сопоставляющими подключения к рабочим процессам крайне сложно, особенно для разработчиков, которые не знают пространство решения и должны поддерживать эти рабочие процессы.
Поэтому значимые и согласованные имена подключений важны по следующим причинам:
- Удобочитаемость
- Упрощение передачи знаний и поддержки
- Система управления
Опять же, наличие соглашения об именовании имеет решающее значение, хотя формат не слишком важен. Например, можно использовать следующий шаблон в качестве руководства:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
В качестве конкретного примера можно переименовать подключение служебная шина в рабочем процессе приложения логики OrderQueue в формате CN-ServiceBus-OrderQueue в качестве нового имени. Дополнительные сведения см. в записи блога Turbo360 (ранее Serverless360), рекомендации по использованию приложения логики, советы и рекомендации: соглашение об именовании соединителей #11.
Обработка исключений с областями и параметрами "Запуск после"
Области предоставляют возможность группировать несколько действий, чтобы реализовать поведение Try-Catch-Finally. В конструкторе можно свернуть и развернуть содержимое области для повышения производительности разработчика.
При реализации этого шаблона можно также указать, когда следует выполнять действие "Область" и действия внутри на основе состояния выполнения предыдущего действия, которое может быть успешно выполнено, сбой, пропущено или время ожидания. Чтобы настроить это поведение, используйте параметры запуска действия области после (runAfter) :
- Успешно
- Произошел сбой
- Пропущено
- Истекло время ожидания
Консолидация общих служб
При создании решений интеграции рассмотрите возможность создания и использования общих служб для распространенных задач. Вы можете создать командную сборку и предоставить коллекцию общих служб, которые могут использовать ваша команда проектов и другие. Все получают повышение производительности, единообразия и возможности обеспечения управления решениями вашей организации. В следующих разделах описаны некоторые области, в которых можно рассмотреть возможность внедрения общих служб:
| Общая служба | Причины |
|---|---|
| Централизованное ведение журналов | Предоставьте общие шаблоны для того, как разработчики инструментирует свой код с соответствующим ведением журнала. Затем можно настроить диагностические представления, которые помогут определить работоспособность интерфейса и возможность поддержки. |
| Мониторинг бизнес-отслеживания и бизнес-активности | Сбор и предоставление данных, чтобы специалисты по вопросам бизнеса могли лучше понять состояние своих бизнес-транзакций и выполнять самостоятельные аналитические запросы. |
| Данные конфигурации | Отделите данные конфигурации приложения от кода, чтобы упростить перемещение приложения между средами. Обязательно предоставьте единый и легко реплицируемый подход для доступа к данным конфигурации, чтобы команды проектов могли сосредоточиться на решении бизнес-проблемы, а не тратить время на конфигурации приложений для развертывания. В противном случае, если каждый проект приблизился к этому разделению уникальным образом, вы не можете воспользоваться экономией масштаба. |
| Настраиваемые соединители | Создайте настраиваемые соединители для внутренних систем, которые не имеют предварительно созданных соединителей в Azure Logic Apps, чтобы упростить работу группы проектов и других пользователей. |
| Общие наборы данных или веб-каналы данных | Предоставление общих наборов данных и веб-каналов в качестве API-интерфейсов или соединителей для использования команд проектов и избегайте повторного создания колесика. У каждой организации есть общие наборы данных, необходимые для интеграции систем в корпоративной среде. |
Следующие шаги
Теперь вы узнали больше о доступных подходах к миграции и рекомендациях по перемещению рабочих нагрузок BizTalk Server в Azure Logic Apps. Чтобы предоставить подробные отзывы об этом руководстве, можно использовать следующую форму: