|
![]() |
#1 |
Участник
|
Для России это реально проблема. Я работал в одной компании, у которой головной офис со всей инфраструктурой для AX находился в Новосибирске, а один из филиалов находился в Магадане. После запуска проекта в Магадане обнаружилось, что работать через существующий выделенный канал невозможно, так как между нажатием клавиши и откликом проходило 2-3 секунды. В итоге, компания перешла на выделенный спутниковый канал. Стоимость владения таким каналом была колоссальной. Задержка, разумеется, сократилась, но всё равно была, около 150-200 милисекунд. Однако, Магадан это ещё цивилизация :-) А вот в городе Удачном, где расположена знаменитая кимберлитовая трубка, со связью ещё хуже. И в России есть очень много ГОКов и других производств в таких местах, куда Макар телят не гонял и где связь может очень плохая даже через спутник. Обычно на таких ГОКах стоит SAP.
|
|
|
За это сообщение автора поблагодарили: EVGL (1), Logger (3). |
![]() |
#2 |
Участник
|
Цитата:
![]() Кстати, а что мешало аксаптовский портал развернуть ? |
|
![]() |
#3 |
Участник
|
Под портал субъективно куда более трудоемко разрабатывать пользовательские формы, из коробки же очень много форм, которые есть под виндового клиента, в портальном варианте просто не реализованы. Выходит, чтобы запустить банальные складские журналы, надо с нуля изобретать все соотв. формы с их тучей презентационной логики. Например, как сделать в вебе форму строк складского журнала с блокировкой шапки при открытии и примочками по снятию этой блокировки?
В итоге внедрение в портальном варианте может привести к существенному увеличению бюджета и сроков проекта - на этом фоне дорогой спутниковый канал дает более быстрое решение с фиксированной стоимостью, не зависящей от объема внедряемого функционала. К слову, о веб-интерфейсе - вспомним тему 6-летней давности Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL: Цитата:
Peter Villadsen: мы не пытаемся моделировать тут те возможности клиент-серверного взаимодействия, которые сейчас поддерживаются ядром Dynamics AX. В X++ у вас может быть объект на одном уровне (клиенте или сервере), который ссылается на объекты на другом уровне и вызывает методы этих объектов, и так далее. По целому ряду причин это плохая модель. Мы в любом случае хотим уйти от этой модели, потому что не хотим поддерживать слишком много информации о состоянии на каждом из уровней (клиенте и сервере). Мы, напротив, хотим прийти к более облегченной модели, как, например, модель на базе веб-сервисов, где не было бы подобных недостатков.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), Logger (3), AP-1055D (1). |