Biztalk против API для уровня данных

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

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

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

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

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

2 ответа

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

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

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

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

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

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


При взгляде на интерфейс BizTalk существует одна важная истина:

'Интерфейс отсутствует

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

Входящее сообщение "опубликовано" в BizTalk (по тому, что мы называем комбинацией "Receive Port" + "Receive location" ). Вы можете использовать Orchestration (часть бизнес-логики) или SendPort (подключение к внешней системе → выход) для подписки на сообщения. Эта подписка может быть основана на информации контекста или информации о контенте (хотя позже требуется, чтобы информация была поднята из содержимого сообщения в контекст сообщения).

BizTalk позволяет вам подключать любую систему в любой момент времени, становясь "Publisher" или "Subscriber" для сообщений. Это можно сделать даже в том случае, если система полностью запущена и работает в процессе производства.

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

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

licensed under cc by-sa 3.0 with attribution.