На моем последнем месте работы я использовал BTS совсем немного. Тем не менее, я заметил, что менеджеры часто хотят использовать его для неправильных вещей, и разработчики не решаются принять его.
Итак, мне просто интересно, как используется BTS? Пожалуйста, отправляйте опыт, а не теории. Спасибо!
Я работал консультантом одной из крупнейших нефтегазовых компаний в Европе, и они в основном используют BizTalk для всех своих приложений для обмена сообщениями/интеграции. Примерами являются: Счета-фактуры (электронные счета-фактуры), отправленные от партнеров и в разных форматах, синхронизирующие задания между AD и сторонним программным обеспечением, которые поддерживают его собственное имя пользователя db и интеграцию между системой поддержки и внешними клиентами по электронной почте. Таким образом, они имеют довольно широкое применение BizTalk и используют кластер из 5 серверов.
У нас есть несколько десятков приложений, которые необходимо взаимодействовать. У нас есть одно приложение на основе веб-службы, которое управляет передачей сообщений между системами. Другие системы разговаривают с ним и получают от него сообщения через BizTalk оркестровки и т.д.
Мы используем BizTalk для подключения к сторонней системе заказов. Я бы, вероятно, классифицировал это как полезный, но новичок подход к использованию огромных возможностей BizTalk, кажется, предлагает. Под этим я имею в виду, что мы используем только часть функциональности. Это происходит примерно так:
Решение оказалось довольно неплохим и уже несколько лет находится в производстве. Это одна из тех вещей, которая просто работает.
Одна вещь, которую я хотел бы отметить, это то, что, развивая это, мы попытались использовать инструмент Mapper, чтобы помочь нам с частью перевода. Наш перевод был довольно сложным, и сам инструмент был очень утомительным в использовании. Поскольку нам было удобно с xslt, мы закончили писать свои собственные и не использовали графический инструмент Mapper. Похоже, что инструмент Mapper был бы очень полезен для простых переводов, но что-либо из-за нескольких элементов начинает становиться кошмаром обслуживания (IMHO).
В прошлом я использовал BT (2004) для целей электронной торговли (заказ, подтверждение заказа, уведомление о доставке и т.д.) в среде B2B, и он работал очень хорошо. Это, вероятно, хлебное масло BT, потому что это наиболее очевидное место для сидения в организации.
В эти дни я (почти) участвую в полностью внутреннем проекте BT, который изначально обрабатывает массивную загрузку данных из старой системы в новое приложение, и в будущем мы будем обрабатывать обмен сообщениями между другим устаревшим приложением и тем же новая система. Вероятно, это не самое эффективное использование технологий, но инфраструктура теперь используется для реализации архитектуры типа Enterprise Service Bus, которая рассматривается как "спаситель нашего бизнеса". Однако я еще не убежден в этом мышлении.: S
В настоящее время мы используем BizTalk 2006 в нашей компании для обмена заказами с экземпляра Commerce Server 2007 и с множеством магазинов, на которых работает Dynamics RMS, на наш основной ERP, Dynamics NAV. BizTalk, безусловно, является мощным решением, но я считаю, что кривая обучения довольно крутая и согласуется с другими в StackOverflow, которые говорят, что это самый сложный сервер, созданный Microsoft.
Для того, что он делает, он устойчив к камню, и если когда-либо были проблемы с системой, он был на одном конце цепи или другой, но никогда не с BizTalk.
Мы используем BizTalk 2006 для импорта небольших и больших файлов данных из разных источников и различных типов (CSV, фиксированная ширина, XML). Я думаю, что одна из замечательных особенностей BizTalk - это плоский файловый дизассемблер. Вы можете описать макет плоского файла с помощью мастера, и это представление хранится в виде определения схемы XML (.XSD). Мастер даже позволяет расшифровать один файл, который может содержать строки различного типа (и, следовательно, длину), на основе некоторого индикатора на самой строке. Прохладный материал.
-Krip
В моей компании мы используем BizTalk как мощный механизм перевода документов. Мы выполняем обработку EDI, XML и Flat File для документации цепочки поставок. Мы действуем в сценарии брокера документов и используем BT для получения документов в любом формате, а затем преобразуем их в любой другой формат, который должен быть направлен на любого торгового партнера.
Таким образом, вместо каждой пары двух торговых партнеров, проходящих через упражнение EDI onboarding, мы размещаем каждого торгового партнера по их спецификациям, а затем используем наш механизм перевода, чтобы гарантировать, что они смогут отправлять и получать свои документы в статическом формате. Внутренне мы сопоставляем их формат с канонической схемой, а затем подключаем и играем торговых партнеров между собой. Подумайте о сети концентратора и переговорной документации.
Лично разработанные для:
Закупки: обработка запроса на покупку больницы для разных производственных компаний. Эти компании будут иметь разные запросы xml, отправленные различным компаниям, где каждое производство будет иметь свой собственный стиль. Затем все покупки были также сделаны в отчете html/xslt (в квитанции дома), показывающем, что было куплено по каким ценам.
HL7: обрабатывать огромное количество файлов HL7, обрабатываемых сразу (думаю, что это была настройка для обработки по 4 за раз), обработанных и помещенных в новую папку для этого дня.
Я разработал некоторые решения Hl7 с использованием ускорителя HL7, управляя рабочим процессом системы приложений претензий, интеграции между разрозненными системами с использованием общего подхода для маршрутизации сообщений и т.д.
Все хорошее развлечение и много работы...;-D