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

[Александр Ермаков]

Друзья,

13.12.2018 состоится очередной митап российской юзер группы Dynamics 365 - теперь в Москве.

Будут выступать крутые докладчики из Columbus и Awara IT:

1. Новая Axapta: Microsoft Dynamics 365 for Finance & Operations как часть единой эко-системы Microsoft Azure, Александр Пирогов - Операционный директор Awara IT, эксперт по Dynamics 365 F&O

2. D365O On-Premises: как инфраструктура Service Fabric помогает сократить или вовсе устранить простои при обновлении системы, Денис Патраков - системный архитектор отдела разработки, Columbus

3. Омниканальность в D365. Объединение клиентского опыта с процессами компании, Ринат Сафиянов - бизнес архитектор практики Retail, Columbus

Мероприятие как всегда бесплатное, еда и напитки планируются, помещение тоже хорошее, обязательно приходите, качнём :-).

Ссылка для регистрации:
https://www.meetup.com/Dynamics365RU/events/256745154/

[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

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

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

[gl00mie]

Объекты на сервере при падении AOS'а, разумеется, очищаются, но в D365FO пользовательский интерфейс (то, что выполняется в браузере) гораздо меньше связан с ними, нежели в той же AX 2012, поэтому потеря подключения к одному AOS'у и переподключение к другому проходят для пользователей куда быстрее и проще. В том числе это достигается за счет выноса аутентификации вовне - в ADFS для On-Premises либо Azure AD, соответственно, для Azure-версии. Получается, что у пользователя в браузере остаются актуальные cookies для аутентификации, которые без лишних вопросов принимает другой AOS.
В адресной строке браузера остается URL с кодом компании и пунктом меню. При обновлении страницы по F5 открывается та же форма, однако, в ней может не быть связей по dynalink, которые были прежде (если текущая форма открывалась из другой), поэтому придется снова выбирать, к примеру, нужный заказ или журнал. Также есть функционал т.н. deep links, позволяющий создавать для произвольной формы URL с сохранением текущих фильтров запроса (Query), в т.ч. с точностью до конкретной записи на форме. При открытии формы через такую ссылку сохранится и позиционирование.
Что касается данных - тут всё работает так же, как в предыдущих версиях: если нажал Ctrl-S или перешел на другую запись, то данные сохраняются. Впрочем, в отличие от предыдущих версий, в D365FO несохраненные данные еще можно выудить из полей веб-формы в браузере, тогда как раньше клиент при потере подключения просто показывал MsgBox и потом закрывался, не давая ничего скопировать.