Отладка в D365FO

[Vadik]

Вот она, пожалуйста
Notice of upcoming change: Removing RDP access to Tiers 2, 3, 4, and 5 Standard Acceptance Test (or Sandbox) environments deployed in Microsoft subscription

[fed]

А еще в summit EMEA есть смысл посмотреть про сессию: "Microsoft Feedback: Next Generation Microsoft Dynamics 365 for Finance and Operations Online Services"
"Join this session to share your thoughts directly with Microsoft. We are moving into new Service Fabric based architecture that will increase reliability of deployments, enable reduced deployment times, scaling with no downtime, reduced maintenance windows and increased efficiency. Come hear about the architecture and provide feedback on direction.

This session is a roundtable conversation and not a presentation. There will be a maximum of 12 attendees and will be first come, first serve on attendance."
P.S. Я на этом мероприятии не был. Очень надеюсь что они записи треков выложат.

[Ivanhoe]

https://blogs.msdn.microsoft.com/axs...mote-debugger/

Получается, в он прем можно дебажить рабочую?

[sukhanchik]

Так он-прем и отличается от облачной тем что он как бы локален. И по идее - можно...
Как обычно - осталось только это проверить ))
Другое дело, что в момент отладки IIS монопольно занимается отлаживающим, т.о. остальные пользователи терпеливо ждут, когда отладка закончится. Но в целом - этот вариант все же лучше, чем облачный, когда для отладки на проде нужно сначала попросить индусов его скопировать в тест

[Ivanhoe]

Раз можно тут, значит и в облаке можно было бы при желании.
Пишут, что нужно оставить один аос, чтобы точно на нем ловить исполнение. В он-прем нет варианта входа конкретного пользователя на конкретный аос?

[sukhanchik]

Я тут увы не подскажу. Может fed даст более развернутый ответ. Я пока еще с On Premise не сталкивался настолько, чтобы развернуто ответить

[fed]

Цитата:

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

Раз можно тут, значит и в облаке можно было бы при желании.
Пишут, что нужно оставить один аос, чтобы точно на нем ловить исполнение. В он-прем нет варианта входа конкретного пользователя на конкретный аос?

По крайней мере - мне о таком способе не известно. Вообще - похоже что этот Azure Service Fabric - это такая среда исполнения контейнеров типа Docker. При этом - ax там работает не в контексте IIS (который может быть даже не установлен),а где-то в контексте своего собственного процесса (axservice.exe), который где-то на каком-то хосте Service Fabric крутится. При этом, Service Fabric, вроде бы, может реплицировать состояние каких-то областей памяти между процессами на разных узлах кластера и из за этого, последовательные запросы одного и того же пользователя могут, в теории, вообще обрабатываться разными физическими серверами. Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Теоретически про архитектуру Service Fabric рассказано вот здесь, но у меня времени видео смотреть не было, а просто в тексте там не все технические подробности механизмов state replication рассказаны.

[AlexeyS]

Цитата:

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

Вообще - похоже что этот Azure Service Fabric - это такая среда исполнения контейнеров типа Docker. При этом - ax там работает не в контексте IIS (который может быть даже не установлен),а где-то в контексте своего собственного процесса (axservice.exe), который где-то на каком-то хосте Service Fabric крутится. При этом, Service Fabric, вроде бы, может реплицировать состояние каких-то областей памяти между процессами на разных узлах кластера и из за этого, последовательные запросы одного и того же пользователя могут, в теории, вообще обрабатываться разными физическими серверами. Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Заинтересовался, полез читать: Service Fabric - это оркестратор контейнеров, который развертывает микрослужбы в кластере виртуальных машин. Микрослужбы это, например, ASP.Net Core или приложение любого типа.

Единицей развертывания является не сервис, а совокупность сервисов, называемая приложением — в манифесте приложения можно, кроме прочего, определить партиционирование сервиса для поддержания масштабируемости, а для отказоустойчивости в случае выхода из строя серверов ASF каждая партиция может иметь несколько экземпляров сервисов. И сервисы и приложения версионируются независимо, что позволяет обновлять приложение, не обновляя в нем все сервисы разом. Для развернутого приложения ASF создает нужное количество экземпляров сервисов, размещает на нодах кластера, запускает, синхронизирует состояние между экземплярами, пересоздает экземпляры для балансировки нагрузки.

Сервисы в ASF могут быть statefull и stateless, и судя по сценарию приложений для statefull, запросы одного пользователя будут обрабатываться на одном сервисе. Но на каком именно - неизвестно, это определяет балансировщик, поэтому и должен остаться только один.
С другой стороны, непонятно, как тонко разделено приложение на сервисы.
Например модуль Sales это приложение (в терминах ASF) как совокупность сервисов или нет? Создание заказа это отдельный сервис или нет? А создание нового клиента по ходу создания заказа это отдельный сервис?

[fed]

Цитата:

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

Сервисы в ASF могут быть statefull и stateless, и судя по сценарию приложений для statefull, запросы одного пользователя будут обрабатываться на одном сервисе. Но на каком именно - неизвестно, это определяет балансировщик, поэтому и должен остаться только один.
С другой стороны, непонятно, как тонко разделено приложение на сервисы.
Например модуль Sales это приложение (в терминах ASF) как совокупность сервисов или нет? Создание заказа это отдельный сервис или нет? А создание нового клиента по ходу создания заказа это отдельный сервис?

Ну там сейчас вся старая добрая аксапта живет как один Service Type - AXSF. Так что не так уж оно чтобы и очень микро-сервис
Кроме того - мне не очень понятно как именно они сделали поддержку репликации и масштабирования stateful service. Они там что-то пишут по поводу репликации, но конкретики не так чтобы уж очень много. Я правильно понимаю, что в случае если у меня один из серверов остановлен, все пользователи просто магически переедут на другой сервер, не заметив подмены ?

[Logger]

Цитата:

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

Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Получается что по живой уже не отладишься. Всех придется выгонять. Или может есть какой-нить аналог -aos2 ?

[AlexeyS]

Цитата:

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

Ну там сейчас вся старая добрая аксапта живет как один Service Type - AXSF. Так что не так уж оно чтобы и очень микро-сервис
Кроме того - мне не очень понятно как именно они сделали поддержку репликации и масштабирования stateful service. Они там что-то пишут по поводу репликации, но конкретики не так чтобы уж очень много. Я правильно понимаю, что в случае если у меня один из серверов остановлен, все пользователи просто магически переедут на другой сервер, не заметив подмены ?

Ответа на этот вопрос не нашел, но в целом, создалось впечатление, что нет. Чтобы работало именно так, то один экземпляр сервиса должен уметь передавать состояние клиента другому экземпляру сервиса. Это подразумевает постоянное сохранение состояния в каком-то хранилище. В каком-нибудь google docs это на уровне архитектуры, умеет ли это аксапта - не знаю.

[MikeR]

Мне думается, что отладка какая она именно была в Dynamics уходит в прошлое, в облачных системах остается только смотреть log.

system.debug();
console.log();

будет что-то вроде этого. Или запись в какую нить сессию профайлера и запуск этой самой сессии.

[trud]

Цитата:

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

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

Вот такое прочитаешь и непонятно, откуда взялось 3 часа полной остановки системы при любой заливке нового кода
т.е. то-ли разработчики ах не разобрались, то ли сервис фиговой
Кстати помимо АХ есть ведь еще Data management service который работает с локальными папками, он вряд ли отказ узла переживет

[AlexeyS]

Цитата:

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

Вот такое прочитаешь и непонятно, откуда взялось 3 часа полной остановки системы при любой заливке нового кода
т.е. то-ли разработчики ах не разобрались, то ли сервис фиговой
Кстати помимо АХ есть ведь еще Data management service который работает с локальными папками, он вряд ли отказ узла переживет

Так это для приложений, которые написаны в полном соответствии с концепцией Service Fabric. А на сегодня ASF выступает просто контейнером для сервиса Аксапты. Возможно в будущем, когда основное ядро будет закрыто для изменений, AOS порежут на тысячи мелких сервисов, собранных в приложения-пакеты по функциональным областям и любой бизнес-процесс будет набором сервисов, выстроенных в цепочки, по типу WorkFlow. Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

[fed]

Цитата:

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

Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

Опыт показывает, что время для честного переноса (и редизайна) любой крупной программной системы на принципиально новую технологию заметно превышает длительность hype cycle. Так что я думаю Аксапточка так и останется одиноким statefull service type AXSF. А там глядишь либо опять менеджмент в микрософте сменится или DEVOPS выйдет из моды и будет заменен Waterfall 4.0 или еще чего-нить подобное случится. В общем - в полном соответствии со старой притчей про Насреддина, бухарского эмира и осла...
P.S. Кстати - не могу не вспомнить как при том же Наделлле, в Ax 4.0 старый сетевой протокол имени Damgaard был заменен на Windows RPC (с большой помпой и вынужденный интеграцией с доменной системой windows). Но при этом единственная вызываемая по RPC функция принимала в качестве параметра, BLOB в формате старого дамгаардовского сетевго протокола.

[trud]

Цитата:

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

Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

Почему фантазии? это уже есть, т.е. все приложения умеют хранить данные в Common Data Service(уже чуть ли не 2 версия выходит), плюс пользователь сам создает недостающие компоненты через PowerApps мышкой

[AlexeyS]

Цитата:

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

Почему фантазии? это уже есть, т.е. все приложения умеют хранить данные в Common Data Service(уже чуть ли не 2 версия выходит), плюс пользователь сам создает недостающие компоненты через PowerApps мышкой

Как это работает на примере, можете пояснить?
Это способ интеграции между приложениями, каким в свое время выступил XML или что-то большее?

[Ivanhoe]

Цитата:

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

По крайней мере - мне о таком способе не известно.

При этом есть сервер Windows, на котором стоит IIS и сайт AOSService. Что нам мешает локально на этом сервере запускать браузер и подключаться к Аксапте по локальному адресу? Или Аксапта настолько умная, что может перевести подключение на физически другой сайт / IIS / Windows server?

[fed]

Цитата:

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

При этом есть сервер Windows, на котором стоит IIS и сайт AOSService. Что нам мешает локально на этом сервере запускать браузер и подключаться к Аксапте по локальному адресу? Или Аксапта настолько умная, что может перевести подключение на физически другой сайт / IIS / Windows server?

Так в том то и дело, что нету там IIS и сайта AOSService. Как я уже сказал, все это дело живет в Service Fabric. В требованиях к конфигурации кластера там написано что у тебя DNS-имя ax.contoso.com должно разрешаться на список ip тех хостов, где стоят AOSы. При этом сам URL там выглядит как https://ax.contoso.com/namespaces/AXSF/ Я так понимаю, клиент полезет к первому попавшемуся из AOS, клиенту ответит на первом уровне Service Fabric (возможно - перенаправляя его на другой AOS). Потом уже на втором уровне пойдет соединение к самому axService.exe, на этом же хосте или на каком-то еще.
Когда я пробовал образаться к адресу конкретного хоста (типа https://ax1.contoso.com/namespaces/AXSF/) соединение не устанавливалось из за каких-то граблей с сертификатами. Возможно, там можно было бы настроить и на использование сертификата для конкретного хоста. Возможно при этом даже удалось бы как-то отключить балансировщик нагрузки Service Fabric, который клиента как-то (вероятно) редиректит на конкретный IP. Проблема в том, что никакой документации на эту тему нет. Кроме того документа, на который я уже давал ссылочку, ничего другого найти не удалось. А сам этот документ - это смесь concept guide и tutorial по разработке "Hello world"-приложения....

[belugin]

https://docs.microsoft.com/en-us/azu...ic-application

Вообще не очень понятно

The debugger will attach to all nodes running the process.

In the case where you are debugging a stateless service, all instances of the service on all nodes are part of the debug session.
If you are debugging a stateful service, only the primary replica of any partition will be active and therefore caught by the debugger. If the primary replica moves during the debug session, the processing of that replica will still be part of the debug session.
In order to only catch relevant partitions or instances of a given service, you can use conditional breakpoints to only break a specific partition or instance.

Conditional breakpoint

Note

Currently we do not support debugging a Service Fabric cluster with multiple instances of the same service executable name.