ax7: SysOperationSandbox - пример использования. почему именно такая архитектура?

[mazzy]

Нашел пример использования SysOperationSandbox хоть с каким-то описанием

https://community.dynamics.com/enter...ations-in-ax-7

проект выложен на gitHub
https://github.com/sertanyaman/SertanDevAXExamples

=====================
мне одному кажется, что логика Sandbox вывернута наизнанку? (как и у всегда SysOperation)
раньше отображением прогресса и информированием пользователя занимался сам процесс-обработчик. теперь информировать должен вызывающий класс, а процесс-обработчик должен молчать в тряпочку...


Как вы думаете, почему выбрали именно такую архитектуру: за информирование должен отвечать вызывающий класс, а не сам процесс? может, я чего не понимаю?

[trud]

а кстати о каком информировании идет речь?
можно ли вообще делать прогресс бар? вроде бы нет(я так сходу не нашел). тогда и информирование не нужно. или все же как-то можно?

[mazzy]

Цитата:

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

а кстати о каком информировании идет речь?

да, не точно сформулировал.
информирование пользователя о том, что выполняется процесс.
в приведенной выше статье есть скриншоты


пример того, где подобное информирование нужно - импортирование GER отчетов.

Цитата:

Сообщение от Ace of Database

Наверное для того, чтобы не блокировать пользовательский интерфейс. Пытаются сделать из Аксапты Андроид.

техническая сторона понятна.
это единственная причина?

меня больше интересует - почему за информирование должна отвечать вызывающая сторона, а не сам процесс?

ну, да. сейчас процесс на серверной стороне.
но ведь это не мешает ему вызвать что-нибудь клиентское.
разве не так?

Цитата:

Сообщение от Ace of Database

Так как внешняя обработка работает не в главном потоке, то она не может отображать инфолог, прогресс или делать еще-какие-то телодвижения с пользовательским интерфейсом.

А почему, собственно? Что мешает?
Такое ощущение, что я чего-то не понимаю.

[Ace of Database]

Цитата:

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

д
меня больше интересует - почему за информирование должна отвечать вызывающая сторона, а не сам процесс?

ну, да. сейчас процесс на серверной стороне.
но ведь это не мешает ему вызвать что-нибудь клиентское.
разве не так?

Наверное из-за того, что сервер теперь в облаке, а не в локальной сети, в целях оптимизации убрали перерисовку клиентского интерфейса из кода, выполняющегося на сервере.
Это как GPS - вы со спутника можете принять информацию, а обратно передать не можете. Вызывать клиентский код с сервера из облака наверное посчитали неэффективным.

[mazzy]

Цитата:

Сообщение от Ace of Database

в целях оптимизации убрали перерисовку клиентского интерфейса из кода, выполняющегося на сервере.

в целях оптимизации чего?
для прогрессбаров есть куча примеров хоть на React, хоть на Angular, хоть на чистом jQuery.

Это именно то, чего я не понимаю - ЗАЧЕМ?

нискольно не сомневаюсь в то, что при этом говорились красивые слова "оптимизация", продуктивность и снижение стоимости ))))

Цитата:

Сообщение от Ace of Database

Это как GPS - вы со спутника можете принять информацию, а обратно передать не можете.

не считаю аналогию адекватной.
в нашем случае нет ассиметрии канала.

Цитата:

Сообщение от Ace of Database

Вызывать клиентский код с сервера из облака наверное посчитали неэффективным.

Наверняка.
А почему? Чем обосновывали то?

[Ace of Database]

Цитата:

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

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

Наверное для того, чтобы не блокировать пользовательский интерфейс. Пытаются сделать из Аксапты Андроид.

To run our program code asynchronously in the background without blocking the user interface, we use the new runasync methods of FormRun and Global classes.
This code will run the static class method on the background and call the callback function passing an AsyncTaskResult object to the method. From that object we can check the return value of the async method call (must be a container) and get the infolog result of the async execution.
You can click other buttons in the form and do other things as well without waiting for the code execution to complete, and we receive information messages as soon as the execution is finished.

[Ace of Database]

В Андроиде можно работать с пользовательским интерфейсом только в главном потоке приложения. В Аксапте сделали по аналогии. Так как внешняя обработка работает не в главном потоке, то она не может отображать инфолог, прогресс или делать еще-какие-то телодвижения с пользовательским интерфейсом.

[belugin]

Я вижу кучу использований SysOperationProgress в коде, но не знаю, как выглядит вызов таких сервисов.

[mazzy]

Цитата:

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

SysOperationProgress

???
это ж старый добрый прогресс бар.
даже в акс7 остался класс Tutorial_Progress и форма tutorial_Progress.


я про SysOperationSandbox.
см. статью, ссылку на которую я привел в первом сообщении.

или можешь раскрыть связь между SysOperationProgress и SysOperationSandbox подробнее?

[belugin]

Цитата:

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

???
это ж старый добрый прогресс бар.
даже в акс7 остался класс Tutorial_Progress и форма tutorial_Progress.

Ну да это я о том, что "почему за информирование должна отвечать вызывающая сторона,". Я не вижу чтобы она была собственно "должна". Я вижу кокретный пример в блоге.

Цитата:

я про SysOperationSandbox.
см. статью, ссылку на которую я привел в первом сообщении.

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

Интересно было бы вызвать сервисы с SysOperationProgress и посмотреть реализовали это или нет.

[mazzy]

Цитата:

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

SysOperationProgress в AX7 не работает. код ниже ничего не отображает

Будем справедливы - это разные утверждения. )
SysOperationProgress в АX7 - работает. Но при этом ничего не отображает.

Цитата:

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

Tutorial_Progress отображает вместо прогресса - Please wait. We're processing your request.

И кто скажет, что это не информирование пользователя, пусть первый бросит в меня камень ))))
https://www.youtube.com/watch?v=yp8cBcc3jd0

Цитата:

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

Ну да это я о том, что "почему за информирование должна отвечать вызывающая сторона,". Я не вижу чтобы она была собственно "должна". Я вижу кокретный пример в блоге.

Хм... резонно.
Может подскажешь пример как добавить информирование в сам процесс?

Цитата:

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

В блоге я вижу просто обзор способов асинхронного вызова и не вижу, собственно, информирование о прогрессе.

Наверное я плохо написал. Но в этой ветке я нигде не писал о "прогрессе".
максимум что было "информирование пользователя о том, что выполняется процесс"

но если подскажешь как информировать о прогрессе, то буду очень признателен.

Цитата:

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

Когда мы делали асинхронную загрузку конфигураций прогрессабара еще не было и я не знаю есть ли он сейчас.

1.
Макс, вот нисколько не в укор написал.
Просто пример, где можно посмотреть.

2.
это не повод не исправить )
текущее поведение ГЕРа при импорте на самом деле вымораживает.

повторюсь - сейчас это пример места, где можно и нужно применить SysOperationSandbox вместо текущей реализации. Просто это место может посмотреть каждый в публичной и доступной для людей версии.

Цитата:

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

Интересно было бы вызвать сервисы с SysOperationProgress и посмотреть реализовали это или нет.

ты снова говоришь SysOperationProgress
SysOperationProgress ничего не выводил, не выводит и не знаю планов, чтобы с ним начинали что-то делать.
Если у тебя есть инфа - поделись. Интересно.

Ветка про SysOperationSandbox. Это другой класс. Совсем другой.

[belugin]

Цитата:

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

ты снова говоришь SysOperationProgress
SysOperationProgress ничего не выводил, не выводит и не знаю планов, чтобы с ним начинали что-то делать.
Если у тебя есть инфа - поделись. Интересно.

Ветка про SysOperationSandbox. Это другой класс. Совсем другой.

Дык ты делаешь обобщения "что логика Sandbox вывернута наизнанку? (как и у всегда SysOperation)" я просто показал место, где информирование находится в вызываемом коде.

Я не вижу особово интформирования в клиентском коде в примере с sandbox - вижу что параметры передаются во фреймворк, так что информированием занимается он. Судя по XML комментарию (там употреблено слово internal) создатели считают этот класс частью внутренней реализации SysOP FW.

[trud]

SysOperationProgress в AX7 не работает. код ниже ничего не отображает
поскольку контрола для отображения прогресса бара нет, то собственно твой вопрос не особо имеет смысла - если нет технической возможности отобразить прогресс то без разницы какой класс будет отображать ожидание

Tutorial_Progress отображает вместо прогресса - Please wait. We're processing your request.

SysOperationProgress  sp =    SysOperationProgress::newGeneral('', "test", 100);
        int                   i;
        for(i = 1; i <= 20; i++)
        {
            sleep(1000);
            sp.incCount();
        }

[belugin]

Еще в Ax2012 убрали ссылки с сервера на клиент (до этого был распределенный сборщик мусора, который был медленный и доставлял проблемы). А progress на сервере был объектом, который не знал про клиентский и клиентский его периодически опрашивал, насколько я помню.

Но это к делу не относится потому, что в приведенном коде показаны примитивы вызова асинхронного кода. Разумеется в части из них UI надо выводить самостоятельно. Потому, что они примитивы.

[mazzy]

Цитата:

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

Еще в Ax2012 убрали ссылки с сервера на клиент (до этого был распределенный сборщик мусора, который был медленный и доставлял проблемы). А progress на сервере был объектом, который не знал про клиентский и клиентский его периодически опрашивал, насколько я помню.

Но это к делу не относится...

именно. аргументы нулевой значимости.
потому что есть инфолог.
а это значит есть способ сделать так, чтобы информация с сервера отобразилась на клиенте.

Цитата:

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

Разумеется в части из них UI надо выводить самостоятельно. Потому, что они примитивы.

Почему это "разумеется"? Кому надо?

Почему разработчики сделали примитивы?
Есть ли не примитивный фреймворк в Аксапте?

===================
Ребяты, это раньше можно было говорить "это в САПе так" и глазами так УУУУ
https://www.youtube.com/watch?v=IrdVZ32Wl4M
теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

"разумеется" "они примитивы" и прочие УУУУ не канают, когда можно вгуглить вопрос, добавить jQuery и получить кучу ссылок с ответами и примерами как это уже сделано.

для примера погуглите "jQuery progress bar".

===================
так вот, вопрос собственно - ПОЧЕМУ изо всех возможных вариантов реализации, разработчиками аксапты выбран именно такой "кучерявый наизнанку"?

опять же таки! "кучерявый наизнанку" в мире программирования UI уже есть - React. Это настолько наизнанку, что поначалу оторопь берет. Но "наизнанку" там обладает своей логикой и приводит к тому, что вот там, там и там становится намного легче. А также рендеринг на сервере.

А в Аксапте в чем плюсы "кучерявого наизнанку SysOperation"? MVC, говорите?
Но это замена одного термина другим. А в чем плюсы MVC в Аксапте?
Юнит-тестирование и моки, говорите? А в чем плюсы юнит-тестирования и моков в Аксапте, при условии, что юнит-тесты не поставляются партнерам и клиентам?
Form Adapter и Task Recorder, говорите? А не слишком ли высокая цена за то, чтобы получить только Task Recorder?

Зачем?

[macklakov]

Цитата:

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

теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

Ты уже почти ответил на свой вопрос Какая из этих технологий пренадлежит MS? Даст ли использование этих подходов приемущество в патентных войнах?

[belugin]

Цитата:

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

именно. аргументы нулевой значимости.
потому что есть инфолог.
а это значит есть способ сделать так, чтобы информация с сервера отобразилась на клиенте.

Да, теоретически такая возможность есть. Не все теоретические возможности на практике реализованы.

Цитата:

Почему это "разумеется"? Кому надо?

Потому, что они примитивы. Если не надо, то можно ничего не делать.

Цитата:

Почему разработчики сделали примитивы?

Потому, что их сделать проще и вообще что-то сложное состоит из примитивов.

Цитата:

Есть ли не примитивный фреймворк в Аксапте?

SysOperation наверное (если делать полностью сервис и запускать его контроллером).

Цитата:

Ребяты, это раньше можно было говорить "это в САПе так" и глазами так УУУУ
https://www.youtube.com/watch?v=IrdVZ32Wl4M
теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

При всем уважении, аксапта не является JS библиотекой а использует их. Это как сказать, что раньше аксапта была на рынке WinApi рядом с офисом и WinAmp.

Цитата:

для примера погуглите "jQuery progress bar".

Я еще добавил server side

Цитата:

А в Аксапте в чем плюсы "кучерявого наизнанку SysOperation"? MVC, говорите?

Я уже высказал свое мнение по этому поводу в соответсвующем треде.

[mazzy]

Цитата:

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

Да, теоретически такая возможность есть. Не все теоретические возможности на практике реализованы.
...
Я уже высказал свое мнение по этому поводу в соответсвующем треде.

Ясно. Спасибо, Макс, за твое очень ценное мнение.
Если собираешься продолжать в таком же духе подмены понятий, то, пожалуйста, воздержись от участия в этой ветке. Буду очень признателен.

Для тех же, кто хотел бы разобраться. Вопрос:
ПОЧЕМУ? ЗАЧЕМ сделано или не сделано именно так?

Цитата:

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

Ты уже почти ответил на свой вопрос Какая из этих технологий пренадлежит MS? Даст ли использование этих подходов приемущество в патентных войнах?

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

===================
Из личных обсуждений у меня возникает стойкое ощущение, что я плохо сформлировал "что есть" и "что могло бы быть" - народ просто не врубается.

Итак, старый добрый SysOperationProgress:
* одна операция один класс
* в одном классе замешаны хранилище данных, маршаллинг данных, диалог, собственно обработка
* допускается наследование классов-обработок
* предоставляется фреймворк, от которого надо унаследовать свой класс и встроиться в фреймворк
* отлаживать надо один класс
* класс полностью управляет своим состоянием, инициализацией и восстановлением параметров, отображенем себя в UI. В частности, сам занимается отображением своего прогресса и прочим информированием пользователя о своем состоянии.


Новый SysOperation (уже обсужался неоднократно):
* несколько формально и синтаксически независимых, но при этом очень сильно семантически связанных классов
* наследовать от базовых классов не нужно (нет базовых классов)
* встраивание во фреймворк происходит через атрибуты (и соответственно, через рефлекшн)
* создание классов-наследников от собственного происходит с трудом (потому что атрибуты не наследуются)
* класс обработка (в стандарте) не занимается своим состоянием, инициализацией и восстановлением параметров, не имеет доступа к UI. В частности, не может отображать прогресс и не может информировать пользователя о своем состоянии.

по сути изменений два:
1. вместо наследования - не наследуемые атрибуты
2. вместо все-в-одном - группа очень тесно связанных классов
3. вместо обычного класса - обязательно сервис

Супер-новая штука в ax7 SysOperationSandBox (не обсуждался):
* класс-обертка для фреймворка SysOperation
* позволяет написать один вызов, чтобы вызывать обработку фреймворка SysOperation произвольный статический метод произвольного класса.
* отображает на экране инфо-окно специального вида.


===================
Собственно какие альтернативы были:
например, миксины
вместо атрибутов (и рефлекшн) пойти в interface и наследование от интерфейсов.
другими словами, написать интерфейсы для datacontract, service, controller

не требовать, чтобы это были отдельные классы, а позволить создавать любые классы, которые имплементируют интерфейсы. в старой доброй аксапте уже начали ходить в эту сторону. См. runbase, enumerator и прочие. (см. скриншот ниже)

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

почему не пошли дальше?
зачем сменили курс?

===================
я абсолютно не верю в то, что между клиентом и сервером невозможно передать данные. потому что вижу примеры других систем, где эти данные вполне передаются. также вижу и аксапту с ее "новым" инфологом.
поэтому не катит.

я абсолютно не верю в то, что на передачу данных идут какие-то большие накладные расходы. извините.

я абсолютно не понимаю, почему нельзя было отрисовать форму на клиенте в рамках старого доброго SysOperationProgress.

однако вижу, что кто-то принял решение - SysOperationProgress не нужен.
лично меня абсолютно не устраивает "объяснение" в стиле "Не все теоретические возможности на практике реализованы."
Меня не интересуют ВСЕ теоретические возможности.
И возможности SysOperationProgress вовсе не теоретические.
Считаю ответ в таком стиле чистой воды демагогией.

Я хочу понять логику этого товарища (или группы товарищей) в отношении SysOperationProgress, SysOperation, SysOperationSandbox.
Я хочу понять ПОЧЕМУ?

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

[macklakov]

Цитата:

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

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

У меня сложилось впечатление, что разработчки и консультанты на партнерах и клиентах не рассматриваются как клиент. Поэтому язык и инструментарий делаются под нужды продуктовой команды. И поэтому ими очень неудобно пользоваться на внедрежах.
Т.е. если нужен инструментарий удобный для внедренца, его надо писать отдельно. Но т.к. удобство внедренца в приоритетах не значится, систему неожиданно изменят и инструмент придется преписывать заново. По этой причине хороших инструментов на рынке мало. И по этой причине на внедрежи в бюджет не укладываются и бывают проблемы с прохождением аудита. И поэтому продукт агонизирует. И поэтому на замену AX выстраивается линейка 365 компонент.

[ax_mct]

Цитата:

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

...
Как вы думаете, почему выбрали именно такую архитектуру: за информирование должен отвечать вызывающий класс, а не сам процесс? может, я чего не понимаю?

В конце статьи

Цитата:

After you run the code you will realize that you do not receive the information message in time although the operation is completed. This is because the asynchronous execution and callback is done outside the form and form handler does not know about it. You need to refresh the form to see the result of the execution in messages after it is finished. In Formrun version you do not need to do it and get the messages as soon as they are placed in the infolog.

В комментариях

Цитата:

Tayfun Sertan Yaman
JULY 24, 2017 AT 1:25 PM
Nothing I know yet. In data import/export form it has some kind of progress display but you need to refresh the webpage to update it.

https://sertandev.wordpress.com/2017...ations-in-ax7/

Tommy Skaue в 2013 про AX2012 SysOperationFramework

Цитата:

Getting feedback to the UI is not easy. Your operation might not be running on the same thread as the UI, making it hard to get the UI and the progress in sync

https://community.dynamics.com/ax/f/33/t/116700

Можно было бы предположить что в AX7 так в силу некой сложности, но судя по всему такой подход тянется с AX2012. Основная причина эта необходимость некого threading и сообщения между потоками. Все это сделать можно и делается на всех языках.
При этом при наличии DB возможности языка вообще паралельны - через DB прекрасно можно координировать процесс в другом потоке и вызывающем интерфейсе. Судя по всему именно так и возможно обновление Infolog. Сделать так же для прогресс-бара - вопрос только желания.

Вот это мне кажется важным

Цитата:

в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

Именно что ожидания пользователей от web-интерфейса.