AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.11.2011, 19:26   #1  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Классы от RunBaseReport и класс Thread
Добрый вечер, Уважаемые коллеги.
У меня возникает интерес, узнать Ваше мнение в связи с тем, чем мне пришлось в последнее время заниматься.
У нас много отчетов, которые используют стандартный базовый класс RunBaseReport. Многие бухгалтера, экономисты и т.д. недовольны тем, что после запуска отчета Система зависает.Я, понимаю, есть архив печати, запуск в пакете и т.д.Но им хочется простоты. Для этого можно использовать класс Thread. Если весь алгоритм выполнения запустить в его(Thread) Run, то Axapta становится доступна, т.е. проще говоря, диалоговое окно исчезает, и делай что хочешь.Бегай по справочникам, запускай другие отчеты.Отчет сам выйдет на экран, когда отработает. А все дело в том, что открывается новая сессия с типом - Рабочая.
Это очень удобно пользователям.Плюс экономит время.Если в отчете есть независимые от себя блоки получения информации, то вместо последовательного режима выполнения, они будут выполняться в параллельном.
Правда есть нюанс : после каждого Thread создается новая сессия с типом Рабочая.
(я надеюсь она не влияет на лицензии?). И только тогда, когда Thread завершится, сессия закроется.
Интересно узнать Ваше мнение, рационально ли использовать такой подход для большинства отчетов, ради удобства работы пользователей?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 18.11.2011, 20:11   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Было несколько тем на форуме по thread
Описание функций класса Thread
Визульное сравнение различных алгоритмов сортировки
Threads

Из них для себя вынес, понимание того что в 3-ке этот класс был достаточно глючным и пользоваться им на клиенте не рекомендовалось самими разработчиками MS. Только на сервере. Плюс глючило в двухзвенке. Как обстоит дело в 2009-й не знаю.

Как-то мне этот класс не нравится. Не принято им пользоваться, поэтому зачем изобретать велосипед ?
Я бы предложил вам лучше ставить построение отчетов в пакет, с уведомлением которое покажет пользователю всплывающее окно. Можно это дело навернуть как нить, например сделать формочку, которая по таймеру аналогично sidax будет показывать прогресс выполнения отчета в фоне, пока пользователь делает остальные дела.
За это сообщение автора поблагодарили: Pustik (1).
Старый 18.11.2011, 20:22   #3  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Logger Посмотреть сообщение
Как-то мне этот класс не нравится. Не принято им пользоваться, поэтому зачем изобретать велосипед ?
Почему ?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 18.11.2011, 21:39   #4  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Pustik Посмотреть сообщение
Почему ?
Потому что сами программисты MS избегали им пользоваться.
Потому что нет большого опыта его использования. А для пакетов - есть.
Старый 18.11.2011, 22:20   #5  
Diman is offline
Diman
Участник
Сотрудники Microsoft Dynamics
 
166 / 35 (2) +++
Регистрация: 27.06.2003
Адрес: Москва
Цитата:
Сообщение от Pustik Посмотреть сообщение
Почему ?
Как мне кажется, из-за потенциальных багов в реализации, увеличение стоимости разработки и тестирования и увеличение сроков выпусков.
-потому что надо редизайнить реализацию алгоритмов (при том что не все хорошо поддаются распраллеливанию)
-необходимо иметь обертки над примитивами синхронизации, представлять работу процессора, памяти, ОС, взаимодействие с GUI, COM и т.п. Т.е. заниматься низкоуровневой разработкой, для чего Аксапта совсем не предназначена.

Но правильное использование класса Thread позволяет довольно эффективно решать проблему производительности на конкретной инсталляции.
__________________
Sapere aude

Последний раз редактировалось Diman; 18.11.2011 в 22:29.
Старый 19.11.2011, 00:37   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Pustik Посмотреть сообщение
RunBaseReport. Многие бухгалтера, экономисты и т.д. недовольны тем, что после запуска отчета Система зависает.Я, понимаю, есть архив печати, запуск в пакете и т.д.Но им хочется простоты. Для этого можно использовать класс Thread. Если весь алгоритм выполнения запустить в его(Thread) Run, то Axapta становится доступна, т.е. проще говоря, диалоговое окно исчезает, и делай что хочешь.
Буквально вчера Blog bot выдал пару занятных заметок про то, как поддержка MS набирает сотрудников и о чем спрашивают кандидатов. Вот, к примеру:
Цитата:
Сообщение от Blog bot Посмотреть сообщение
A customer runs into a situation where the functionality that they receive through AX is not what they expected. This piece of functionality is key for the customer and they aren't happy that the product was designed in this manner. You realize that this is important to the customer, but the chances of the product being changed to accommodate this request are extremely small. In your opinion, what's the best way to handle this?

Here I'm trying to see how quickly they go to "make customizations". I want them to communicate the truth to the customer and exhaust other options before moving to creating the customization
Т.е. с одной стороны можно сказать, мол, любой каприз за ваши деньги, а с другой, для бизнеса в целом это, по-моему, - пустые траты, потому что есть штатный пакетный сервер и есть в штатном движке отчетов штатная возможность отсылки готовых отчетов по почте, а в 2009-й той же - еще и механизм уведомлений, если в аутлуке они вдруг не всплывают. Впрочем, у всех свой об'ем нерешенных пользовательских хотелок, и если ничего серьезнее больше нет, почемы бы для самообразования не поиграться с классом Thread.
Старый 19.11.2011, 01:30   #7  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Еще, пакетными обработчиками удобно управлять и перезапускать при какой либо ошибке. Для потоков ничего этого нет и придется самим все это написать.
Старый 19.11.2011, 04:17   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Поделюсь одним изысканием по поводу Thread

Недавно обнаружил, что при изменении данных сторонними средствами в EntireTable кешируемых табличках или при выполнении к таким табличкам прямых запросов SQL на обновление - кеш не только видит этих изменений, но и не хочет сбрасываться обычными способами. (Подчеркну - речь идет именно о прямых запросах SQL к базе, формируемых например при дублировании компаний класом SysSqlCopyCompany)
Эта особенность в 2009-й Аксапте особено опасна тем что аосы можно долго не перестартовывать (в отличие от трешки). У нас, например, пакетный сервер неделями может без перестарта жить.

Попробовал сбрасывать кеш вызовом Меню-Сервис-Средства разработки-Объекты приложения-Обновить данные

Не работает. После некоторых разбирательств выяснилось, что необходимо сбрасывать именно серверный кеш. Поправили менюитем SysFlushData -на одном аосе все ок. А в кластере аосов все равно кеш не сбрасывается.

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

Но как видно из этого примера, ожидаемой обработки лога SysEvent не происходит.

После некоторых разбирательств удалось понять, что при старте АОСа он создает 2 системные сессии с SessionID равным 1 и 2.
В каждой из этих сессий при вызове Application.new() происходит вызов SysEventHandler::initialize();

Далее идет попытка создать отдельный поток при помощи класса Thread и в нем запустить на выполнение статический метод SysEventHandler::runHandler таким вызовом
X++:
    thread.run(classnum(SysEventHandler),staticmethodstr(SysEventHandler,runHandler));
Но этого, к сожалению не происходит ! Код метода runHandler не исполняется (проверял по записи в файл на диске. Добавил в метод runHandler пару строк кода, пишущих лог на диск.)
Т.е. обработчик событий не работает и кеши на аосах в кластере не сбрасываются. (Также возможно не сбрасывается кеш AOT и словаря и настройки логирования sysDatabaseLog - детально проверить руки не дошли.)

Если же извратиться и из джоба запустить таки описанный обработчик, например так
SysEventHandler::initialize(true);
то все же можно заставить работать данный обработчик. В этом случае при вызове
X++:
    thread.run(classnum(SysEventHandler),staticmethodstr(SysEventHandler,runHandler));
отдельный поток на сервере создается и код в нем исполняется. И текстовый лог на диске тоже пишется. (Чтобы код работал без ошибок пришлось еще сделать некоторые добавления в метод runHandler, связанные с permission.assert(); но это непринципиально)

Но! Работает он все равно как-то глючно.
Например если в SysEvent послать событие SysEventType::EventHandlerPing то оно успешно обработается и в ответ отправится событие SysEventType::EventHandlerAlive
Так что если из 3-ки в 2009-й поднять форму SysEventManagement, то в ней как раз можно увидеть результаты использования этих событий - она успешно опрашивает все работающие аосы в кластере и выводит их перечень.

Но если послать событие SysEventType::FlushData - а именно оно и отправляется при сбросе кеша, то почему-то в силу невыясненных причин кеш не сбрасывается. Т.е. код работает но как то "не до конца" Т.е. если на сервере запускается код
X++:
Dictionary::dataFlush();
из под обычной пользовательской сессии, то все в порядке - кеш табличек сбрасывается. А если этот же код запускается на сервере в отдельном потоке, созданном при помощи класса Thread - то кеш не сбрасывается. Чудеса...

P.S.
Ax2009 build 4570 (RU7)
Приложение RU5

Кстати, кто-нибудь умеет гарантированно сбрасывать кеш табличек в кластере аосов ?
Поделитесь.

Последний раз редактировалось Logger; 19.11.2011 в 04:42.
За это сообщение автора поблагодарили: Wamr (10), fed (15), sukhanchik (8), lev (10), gl00mie (9).
Старый 19.11.2011, 21:56   #9  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Спасибо всем, я понимаю так, что это не лучшее решение.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 20.11.2011, 16:49   #10  
someOne is offline
someOne
Участник
Аватар для someOne
 
173 / 423 (15) +++++++
Регистрация: 11.12.2008
Адрес: Москва
Цитата:
Сообщение от Pustik Посмотреть сообщение
Я, понимаю, есть архив печати, запуск в пакете и т.д.Но им хочется простоты. ... Отчет сам выйдет на экран, когда отработает.
До кучи еще такой вариант. Вывести в диалог отчетов некий бокс.
Если бокс установлен - отправлять отчет на выполнение в пактный режим на определенную группу пакетов. Канал вывода при этом установить в "файл" или "архив печати". (в зависимости от предпочтительного способа визуализации).

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

При появлении в архиве печати новой записи для данного пользователя - вывести этот отчет пользователю на экран. (Если вывод в файл - скопировать его с сервера во временную папку клиента пользователя и открыть Word-ом или PDF - viewer - ом в зависимости от предпочтительного формата).

А еще можно отправлять готовые отчеты, по завершению пакетной обработки, пользователю на почту в виде файла.
(Делаю так с отчетами excel)

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

Последний раз редактировалось someOne; 20.11.2011 в 16:51.
За это сообщение автора поблагодарили: Pustik (3).
Старый 21.11.2011, 08:53   #11  
imir is offline
imir
Участник
 
159 / 161 (6) ++++++
Регистрация: 28.05.2010
Цитата:
Сообщение от someOne Посмотреть сообщение
А еще можно отправлять готовые отчеты, по завершению пакетной обработки, пользователю на почту в виде файла.
(Делаю так с отчетами excel)

Вообще, думаю тема построения отчетов в отдельном потоке актуальна. Встречал некоторые системы автоматизации, где так и сделано.
Можно было бы встроить поддержку этого и в стандартный функционал Аксапта...
Все перечисленное делает SSRS.
За это сообщение автора поблагодарили: Maxim Gorbunov (1).
Старый 21.11.2011, 10:15   #12  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
А вообще может ли серверный thread(я не говорю про клиентский из за которого приложение довольно часто виснет) вообще использовать что то связанное с вводом выводом на экран?
( я иногда в threade убирал не то что info("") я выброс ошибки убирал и все работало)
у меня не получалось ни разу, недавно серверный thread не выполнялся только из-за того что у меня в коде было написано appl.curTransactionId().
А так ф принципе каких-то проблем с серверным thread вообще не замечал, работает нормально.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 21.11.2011, 10:55   #13  
niksen is offline
niksen
Участник
Самостоятельные клиенты AX
 
284 / 28 (1) +++
Регистрация: 05.07.2011
Адрес: Татарстан
а зачем тогда вообще нужен этот thread??? распараллеливать вычисления типа всяких "ну очень крутых" алгоритмов? если зависать он зависает, работать с ним толком невозможно, для отчётов всё равно его приспособить нельзя. Смысл тогда его?
Старый 21.11.2011, 11:39   #14  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Murlin Посмотреть сообщение
А так ф принципе каких-то проблем с серверным thread вообще не замечал, работает нормально.
Странно, почему же при старте аоса не стартует поток.
Старый 21.11.2011, 11:49   #15  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Я тоже занимался разработкой мега-отчета, в котором я получаю информацию с разных уголков Аксапты. Приспособил класс thread распараллелил алгоритм и пока проблем никаких нет. Все просто летает. Увеличение производительности в n-крат раз.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 21.11.2011, 12:03   #16  
niksen is offline
niksen
Участник
Самостоятельные клиенты AX
 
284 / 28 (1) +++
Регистрация: 05.07.2011
Адрес: Татарстан
Цитата:
Сообщение от Pustik Посмотреть сообщение
Я тоже занимался разработкой мега-отчета, в котором я получаю информацию с разных уголков Аксапты. Приспособил класс thread распараллелил алгоритм и пока проблем никаких нет. Все просто летает. Увеличение производительности в n-крат раз.
вот оно что
значит он не просто неправильно работает, а его лишь неправильно применяют
Старый 21.11.2011, 12:39   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от niksen Посмотреть сообщение
вот оно что
значит он не просто неправильно работает, а его лишь неправильно применяют
Может я не совсем правильно понял вашу задумку, но мне кажется что возможности распараллеливания при помощи класса thread ограничено одним компом. А, например пакеты можно распараллелить на несколько аосов. Ну и сервер обычно помощнее чем клиентская тачка.

Хотя конечно если потребуется слишком много паралельных потоков, то есть смысл задуматься, а достаточно ли оптимально написан отчет. Может имеет смысл его построить на кубах и.т.п. Аксата все же скорее OLTP система, а не BI
Старый 21.11.2011, 13:05   #18  
niksen is offline
niksen
Участник
Самостоятельные клиенты AX
 
284 / 28 (1) +++
Регистрация: 05.07.2011
Адрес: Татарстан
Цитата:
Может я не совсем правильно понял вашу задумку, но мне кажется что возможности распараллеливания при помощи класса thread ограничено одним компом. А, например пакеты можно распараллелить на несколько аосов. Ну и сервер обычно помощнее чем клиентская тачка.

Хотя конечно если потребуется слишком много паралельных потоков, то есть смысл задуматься, а достаточно ли оптимально написан отчет. Может имеет смысл его построить на кубах и.т.п. Аксата все же скорее OLTP система, а не BI
есть просто одна задумка, никак не связанная с отчётами, в которой нужны эти потоки
Старый 21.11.2011, 13:22   #19  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от Logger Посмотреть сообщение
Странно, почему же при старте аоса не стартует поток.
Я же говорю, там очень много заморочек. Во первых у нити которую вы запускаете не должно вообще ничего быть такого связанного с вводом-выводом иначе она работает только до определенного шага, лучше написать сейчас попроще потом дописывать туда уже что-то, я именно так и делал, каждый раз запуская и проверяя отработает или нет.
Можно класс например проверить который у вас этот поток запускает, выполняется ли он точно на сервере, было у меня такое как-то.
Можно даже попробовать что-то вставлять в таблицу и выяснить на каком шаге у вас прерывается работа серверной нити, я так делал.
А вот клиентская нить, это вообще отдельная тема. Клиентское приложение если переключится с него, а потом снова попытаться включится - виснет.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
За это сообщение автора поблагодарили: Logger (5).
Старый 21.11.2011, 13:37   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Murlin Посмотреть сообщение
Я же говорю, там очень много заморочек. Во первых у нити которую вы запускаете не должно вообще ничего быть такого связанного с вводом-выводом иначе она работает только до определенного шага, лучше написать сейчас попроще потом дописывать туда уже что-то, я именно так и делал, каждый раз запуская и проверяя отработает или нет.
Можно класс например проверить который у вас этот поток запускает, выполняется ли он точно на сервере, было у меня такое как-то.
Можно даже попробовать что-то вставлять в таблицу и выяснить на каком шаге у вас прерывается работа серверной нити, я так делал.
А вот клиентская нить, это вообще отдельная тема. Клиентское приложение если переключится с него, а потом снова попытаться включится - виснет.
Обижаете

Я там все перепроверил.
Выше описано.
Причина "нерабочести" потока не в том что я заставляю его писать в файл на диск. Он и без моих кастомизаций не работает. Не откликается на сообщения в EventLog.

А если вручную на клиенте запустить, то откликается, то есть работает. И даже в файл на диск пишет.
Теги
sysevent, thread

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
В Стандартной АХ2009 не работает кнопка <Параметры> на диалоге класса унаследованного от RunBaseReport Pustik DAX: Программирование 3 11.05.2011 19:47
gatesasbait: Logging independently of transaction scope by using a separate thread in Dynamics AX Blog bot DAX Blogs 0 27.05.2009 23:16
axaptapedia: RunBaseReport Blog bot DAX Blogs 0 03.08.2008 20:10
Проблема с передачей контролов из формы в класс matew DAX: Программирование 0 28.04.2008 17:37
Удобные отчеты без лицензии на класс RunBaseReport ? Александр Зайцев DAX: Программирование 4 05.05.2003 23:19
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:45.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.