Biztalk vs API для уровня брокера данных

Question

Моя компания собирается осуществить крупный проект, в рамках которого наш клиент хочет иметь большой клиентский портал с внедрением cms, crm. Это потребует взаимодействия с данными из нескольких источников по всему бизнесу наших клиентов, в число которых входят бэкэнд-системы для офисов XML, базы данных sql, веб-сервисы и т. Д.

Нашим предлагаемым решением было бы написать API на c # для обеспечения общего интерфейса со всеми этими системами. Это будет масштабируемым для будущих и параллельных проектов в компании.

Наш клиент выразил заинтересованность в использовании Biztalk, а не пользовательского API для этой интеграции, поскольку он считает, что это корпоративное решение, которое любой из его поставщиков может подобрать и использовать, и оно получит лучшую поддержку.

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

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

Answer 1

Читая ваши требования, я бы сказал, что вы хотели бы сосредоточиться на основных бизнес-частях. То есть как использовать вышеупомянутые услуги вместе. Тема, где вы хотите потратить как можно меньше, это «сантехника» этого.

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

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

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

Из вышеприведенного описания я бы сказал; «BizTalk, вероятно, лучший вариант для выбора».

Надеюсь, это поможет,

Answer 2

При взгляде на интерфейс BizTalk есть одна важная истина, которую нужно осознать;

'Нет интерфейса'

BizTalk не указывает конкретные интерфейсы. Он позволяет вам установить «шаблон обмена именованными сообщениями» (например, запрос-ответ, OneWay и т. Д.).

Входящее сообщение «публикуется» в BizTalk (так называемая комбинация «Порт приема» + «Место получения»). Вы можете иметь Orchestration (часть бизнес-логики) или SendPort (соединение с внешней системой -> out), «подписываться» на сообщения. Эта подписка может быть основана на информации о контексте или информации о содержимом (хотя в последующем требуется, чтобы информация была перенесена из содержимого сообщения в контекст сообщения).

Таким образом, BizTalk позволяет вам подключиться к любой системе в любой момент времени, став «Издателем» или «Подписчиком» на сообщения. Это может быть сделано даже тогда, когда система полностью запущена и работает в рабочем состоянии.

Любой проект BizTalk может по-прежнему использовать полный API .Net во многих местах, что дает вам полную возможность писать «все, что вы можете в обычном .Net» также внутри BizTalk.

Я хотел бы посоветовать одну вещь, хотя; «Пожалуйста, убедитесь, что по крайней мере один или два человека в вашей проектной команде пройдут курс / курс по BizTalk». BizTalk похож на скрытый пистолет; Чрезвычайно мощный, но опасный в чужих руках.