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