13.12.2018 - Dynamics 365 for Finance and Operations митап в Москве

[gl00mie]

Много лет назад Peter Villadsen рассказывал - еще до выхода AX 2012 - про выполнение кода X++ в IL, недетерминированный сборщик мусора в CLR и клиент-серверное взаимодействие:

Цитата:

В X++ у вас может быть объект на одном уровне (клиенте или сервере), который ссылается на объекты на другом уровне и вызывает методы этих объектов, и так далее. По целому ряду причин это плохая модель. Мы в любом случае хотим уйти от этой модели, потому что не хотим поддерживать слишком много информации о состоянии на каждом из уровней (клиенте и сервере). Мы, напротив, хотим прийти к более облегченной модели, как, например, модель на базе веб-сервисов, где не было бы подобных недостатков. Таким образом, код, который мы переводим в IL, будет в общем случае выполняться на одном уровне (серверном или клиентском).

В AX 2012 часть кода может выполняться на сервере в IL, так что клиенту не нужно хранить много информации о состоянии, однако, падение одного из AOS'ов является весьма заметным для пользователей событием. Работа всех сессий одномоментно прерывается, нужно заново запускать клиента, ждать, пока он загрузится, заново открывать нужную форму и т.д. Для веб-сервисов требуется предварительно настроить NLB, а потом еще как-то оповестить ее о том, что на данном хосте сервисы AOS'а более недоступны (потому что NLB в общем случае отслеживает доступность хостов, а не отдельных сервисов).
В D365FO озвученные идеи, наконец, воплотились в полной мере: код X++ стал серверным, он выполняется полностью в IL, клиент теперь не хранит информацию о состоянии объектов на сервере, и модель взаимодействия стала облегченной до такой степени, что пользователи практически не замечают падения одного из AOS'ов в кластере. Может появиться окно о потере подключения, но достаточно перезагрузить страницу в браузере - и можно продолжить работу почти с того же места. Это тем более применимо к веб-сервисам на стороне D365FO, вызываемым извне.
В On-Premises версии такая гладкая отказоустойчивость обеспечивается, помимо прочего, инфраструктурой Service Fabric, распределяющей нагрузку на кластеры приложений, отслеживающей доступность отдельных узлов в кластере и в случае недоступности одного из них оперативно перераспределяющей запросы на другие. Но механизмы, обычно используемые для обеспечения отказоустойчивости при сбоях, точно так же могут работать и при плановых простоях узлов во время обновления...

[Logger]

Цитата:

Сообщение от gl00mie

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

Но серверные объекты при этом должны очиститься, так ?
Когда мы говорим о продолжении работы почти с того же места, то имеется в виду открытая форма и положение выбранной текущей записи ? Или удается спасти что-то еще?