RunBase vs SysOperationFramework для Excel отчета

[kitty]

Пользователям нужен экселевский отчет (именно Excel, а не стандартный, который можно в эксель потом сохранить)
При запуске должны запрашиваться параметры и критерии запроса.
(Пока в batch его не просят запускать)

Как лучше делать Через SysOperationFramework или через RunBase
Преимущество RunBase - там progressBar есть + все в одном классе
С другой стороны он морально(хоть и не практически) устарел и , вроде как рекоммендуется использовать теперь SysOperationFramework. (с оговоркой, что в основном для batch process-ов)

Спасибо

Ax2012 R2

[ZVV]

>> Преимущество RunBase - там progressBar есть + все в одном классе
В SysOperationFramework тоже есть прогресбар, только его нужно уметь готовить

По существу вопроса, если вы всё равно не планируете переносить исполнение класса (и заполнение Excel) на сервер, то нет особых оснований для использования SysOperationFramework, Imho.
По крайней мере я бы делал через RunBase.

[kitty]

Цитата:

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

>>
В SysOperationFramework тоже есть прогресбар, только его нужно уметь готовить .

Где найти рецепт готовки?

[ZVV]

Цитата:

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

Где найти рецепт готовки?

Готового рецепта не нашёл, готовил эксперементальным путём.
В чём конкретно проблема у вас? Что не получается? Что вы делали?

[gl00mie]

Цитата:

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

Пользователям нужен экселевский отчет (пока в batch его не просят запускать)
Как лучше делать Через SysOperationFramework или через RunBase

Если предполагается запускать потом отчет в пакете, то надо сразу делать не на RunBase, а на RunBaseBatch, иначе при смене родительского класса потом могут повылезать проблемы.
По-моему, даже при большей трудоемкости стоит попробовать реализовать отчет на SysOperation framework - хотя бы для собственного развития. Заодно можно будет разобраться с Open XML SDK и научиться формировать Excel-файлы без самого Excel

Цитата:

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

вроде как рекоммендуется использовать теперь SysOperationFramework. (с оговоркой, что в основном для batch process-ов)

Я лично не замечал таких оговорок - про пакетные задания. Зато были оговорки, что RunBase - кандидат на вылет в следующих версиях. Одно из удобств SysOperation framework в том, что сервисная операция из клиента может запускаться в асинхронном режиме: она будет работать в отдельном потоке, при этом пользователь сможет продолжить работу в Аксапте, а не будет вынужден пялиться на градусник. При завершении же операции контроллер сервисной операции получит обратный вызов и сможет как-то просигналить пользователю, что результат готов, например - открыть отчет в Excel.

[Napalm]

Проблема с SysOperation framework в том, что он выполняется на сервере. А некоторые задачи импорта/экспорта требуют выполнения на клиенте.

[kitty]

Цитата:

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

Я лично не замечал таких оговорок - про пакетные задания. .

https://msdn.microsoft.com/en-us/library/gg862488.aspx
"You use the SysOperation framework (formerly known as the Business Operation framework, or BOF) when you extend Microsoft Dynamics AX by adding new functionality that may require batch processing. The SysOperation framework replaces the RunBase Framework and provides infrastructure for creating user interaction dialog boxes and integration with the batch server for batch processing. "

Цитата:

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

Зато были оговорки, что RunBase - кандидат на вылет в следующих версиях.

Собственно, отсюда и дилемма

Я уже сделала по новой религии, те SysOperation, рассчитывая, что, если одумаются и захотят нормальный отчет, то будет легко переделать, оставив те же Contract&UIBuilder( или запускать нужный отчет по выбору). Но... это невозможно, тк в принципе наследование от srsReport* классов сразу должно быть(и как следстви, например, запросы передаваться будут различным образом ) .

[gl00mie]

По-моему, любой нормальный импорт, работающий с клиентскими данными, должен идти примерно так:

• запуститься на сервере;
• запустить "нечто" на клиенте (возможно, 2-й экземпляр себя же по аналогии с RunBase.promptPrim()), чтобы считать "сырые" данные на клиенте и вернуть их на сервер;
• прогнать на сервере цикл разбора/проверки/сохранения импортированных данных со всей сопутствующей бизнес-логикой.

для экспорта - аналогично, но с чуть иной последовательностью шагов.
От импортов/экспортов/отчетов в Excel, которые всё делают на клиенте, меня лично коробит.

[kitty]

Цитата:

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

От импортов/экспортов/отчетов в Excel, которые всё делают на клиенте, меня лично коробит.

Клиенту нужны бантики и рюшечки, которые только в экселе можно сделать
Т.е спец оформление таблиц, фиксация колонок и тд.

Вопрос:
Есть класс собирающий данные (MyCalcClass, RunOn:Server), есть класс выгрузки всего в эксель(MyExcelClass, RunOn:Client)
Если мы используем SysOperation framework, то как лучше организовать вызовы:

1) Контроллер вызывает серверный MyCalcClass. Когда данные рассчитались, MyCalcClass внутри себя вызывает MyExcelClass и передает ему рассчитанную таблицу.

2) Контроллер вызывает клиентский MyExcelClass , который внутри вызывает серверный MyCalcClass. MyCalcClass возвращает рассчитанную таблицу и MyExcelClass ее использует для выгрузки.

Мне кажется, второй вариант совсем сводит на нет возможные преимущества sysoperation, тк по сути клиентский код управлет всем. Может, правда , и нет вообще разницы.

[gl00mie]

Цитата:

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

Есть класс собирающий данные (MyCalcClass, RunOn:Server), есть класс выгрузки всего в эксель(MyExcelClass, RunOn:Client)
Если мы используем SysOperation framework, то как лучше организовать вызовы?

Можно применить шаблон Model-View-Controller (MVC). В приведенном описании MyCalcClass можно классифицировать как модель (данные), MyExcelClass - как представление (вывод собранных данных в Excel, а не, скажем, в html или визуализация в виде диаграммы). Координацию их работы логично возложить на контроллер (как в терминах MVC, так и в терминах SysOperation framework), передачу же собранных данных из модели в представление можно реализовать через выходной контракт класса, собирающего данные. Если в этом контракте реализовать сериализацию, то можно будет существенно сэкономить на RPC-вызовах.

[Napalm]

Цитата:

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

По-моему, любой нормальный импорт, работающий с клиентскими данными, должен идти примерно так:

• запуститься на сервере;
• запустить "нечто" на клиенте (возможно, 2-й экземпляр себя же по аналогии с RunBase.promptPrim()), чтобы считать "сырые" данные на клиенте и вернуть их на сервер;
• прогнать на сервере цикл разбора/проверки/сохранения импортированных данных со всей сопутствующей бизнес-логикой.

На RunBase так сделать очень просто. А с SysOperationFramework есть хоть один пример такого решения?

[CDR]

Цитата:

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

Пользователям нужен экселевский отчет (именно Excel, а не стандартный, который можно в эксель потом сохранить)

Как лучше делать Через SysOperationFramework или через RunBase

Ax2012 R2

Использовать XmlExcelReport_RU.

[Ned]

Как это ни неожиданно, но SysOperation framework убран из АХ7

[maldini]

Все довольно просто. Формируем Excel файл на сервере, используя XMLExcelDocument_RU, передаем файл на клиент через BinData и открываем его.

Цитата:

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

Как это ни неожиданно, но SysOperation framework убран из АХ7

А что взамен?

[belugin]

Цитата:

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

Как это ни неожиданно, но SysOperation framework убран из АХ7

По каким признакам вы это определили?

[Ned]

Э, belugin, это попытка наезда?
Если отвечать в стиле вопроса, то:
1. По коду. Я работаю с АХ7 с весны, было время определить. Есть желание - можете проверить
2. По документации и по словам сотрудников Майкрософт на конференциях по АХ7 для участников программы TAP

Я не могу сейчас подкрепить своё утверждение документами и цитатами - на сайте Майкрософт этих указаний не нашёл, а виртуалки с АХ7 под рукой нет, удалил с ноутбука. Если кто-то зайдёт в систему и подтвердит по поводу RunBase - было бы хорошо.

Цитата:

А что взамен?

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

[belugin]

Цитата:

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

1. По коду. Я работаю с АХ7 с весны, было время определить. Есть желание - можете проверить

Вероятно, так как он перенесен из приложения в платформу в рамках разделения на модули поэтому его нельзя найти в исходниках Application Suite.

Но можно найти его использование.

Цитата:

2. По документации и по словам сотрудников Майкрософт на конференциях по АХ7 для участников программы TAP

А в какой именно документации - я по быстрому не смог найти упоминание в wiki

[Logger]

Цитата:

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

Вероятно, так как он перенесен из приложения в платформу в рамках разделения на модули поэтому его нельзя найти в исходниках Application Suite.

Но можно найти его использование.

А самим найденные баги возможно править ?

[belugin]

Цитата:

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

А самим найденные баги возможно править ?

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