[sukhanchik]

На одном из прошлых проектов (а может даже на двух - нюансы не помню) рисовали портал на ASP.NET (+С#) и используя бизнес-коннектор - подключались к АХ (3.0, затем 4.0). Т.е. от встроенного веб-интерфейса отказались сразу. Основная причина - специалистов по ASP.NET (C#) гораздо больше, нежели специалистов по встроенному веб-интерфейсу в АХ. С АХ связывались следующим образом - разработчик по АХ писал класс (в АХ) с пачкой методов, которые принимали те параметры, которые ему (разработчику АХ) требовались от разработчика портала. Разработчик портала в свою очередь ваял портал не заморачиваясь на архитектуру АХ. Основное назначение портала было предоставление отчетности (фактически аналог Reporting Services) с вводом параметров. Хотя изначально и предполагалось что кто-то что-то будет вводить.

Такая схема позволила нарисовать портал с интерфейсом "под клиента", а также в дальнейшем его достаточно эффектно демонстрировать на продажах. Главной особенностью такого портала (да и вообще - бизнес-коннектора) является то, что независимо от количества людей, пользующихся порталом - требуется только одна лицензия на бизнес-коннектор (хотя у МС можно купить несколько лицензий на бизнес-коннектор - на 5, 10 "COM-пользователей" - технически эта цифра представляет собой количество компьютеров, с которых бизнес-коннектор будет подключаться к АХ. Т.е. обычно достаточно лицензии на одного "COM-пользователя")

В Микрософте это понимают и конечно без энтузиазма относятся к применению таких схем (пытаются доказать - что такая схема является схемой уклонения от покупки большего количества лицензий). Аргументом клиента в этом случае может служить следующее сравнение:
Был 1 пользователь, вводящий данные в АХ, которому все носили бумажки, чтобы он вбил данных в АХ. Была куплена честно одна лицензия - т.к. он один работал.
Его рабочее место автоматизировали. Теперь вместо этого пользователя сидит робот (=бизнес-коннектор), который вбивает те же бумажки. Количество пользователей АХ в этом смысле не увеличилось.

Собственное говоря - дальнейший диалог с Микрософтом зависит от возможности клиента убедить Микрософт что применение портала не является целью уменьшить количество требуемых лицензий. Железобетонным аргументом со стороны клиента будет в этом случае наличие оффлайновости. Т.е. если клиент может себе позволить (по бизнес-процессам) работу портала автономно от АХ, связываясь с ней периодически (1-2 раза в сутки) для синхронизации данных.