Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => SE37 - Построитель функций => Тема розпочата: Uukrul від Липень 31, 2008, 12:17:50 ПП
SAPGUI_PROGRESS_INDICATOR - Выводит ход выполнения процесса, именуемый многими часиками в нижнем левом углу. В общем-то иногда полезно бывает показать пользователю сколько данных уже обработано, а сколько еще осталось ему подождать. ФМ доволно простой:
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = 20
TEXT = 'Текст'.
Т.е. шкала 100% мы задаем процент, фактически это будет процент закрашенного синим сектора часов и поле пояснительного текста. Я для себя чтобы не считать процент каждый раз завернул вызов в свой собственный ФМ вида:
FUNCTION ZZ_SHOW_PROGRESS.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*" IMPORTING
*" VALUE(STR) TYPE C OPTIONAL
*" VALUE(PROGRESS) TYPE I
*" VALUE(MAX) TYPE I
*"----------------------------------------------------------------------
DATA: INDICATOR_TXT(120),
INDICATOR_PRC TYPE I.
INDICATOR_TXT = STR.
INDICATOR_PRC = ( PROGRESS * 100 ) / MAX.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = INDICATOR_PRC
TEXT = INDICATOR_TXT
EXCEPTIONS
OTHERS = 1.
ENDFUNCTION.
А теперь про подводные камни:
1. Каждый вызов данного ФМ выполняет процесс отдачи данных от сервера приложений к клиентской машинке, а это значит, что если ФМ, например при обновлении 1000 записей, дергать на каждое обновление одной строки, то скорость выполнения программы упадет в разы, иногда до 10 раз, т.е. как совет, обновление индикатора нужно выполнять например с шагом в 100-200 записей, т.е. вызвать его от 10 до 5 раз за процесс, т.е. приблизительно оцениваете объемы выборки и смотрите с каким шагом дергать индикатор процесса.
2. Данный ФМ блокирует за пользователем один из диалоговых процессов сервера приложений, которых и так не много. Соответственно если у нас в системе например 10 диалоговых процессов, то запустив программку с индикатором хода выполнения процесса 10 раз, пока программа не завершиться, никто живым в систему не войдет и не выйдет, за что можно получить по голове от администраторов системы.
Uukrul
а что по поводу вот этого (http://abap-blog.ru/abap/abap-osnovi/user-interface/indikator-vypolneniya-zadachi/)
там тоже такие же Цитатаподводные камни
???
при использовании в цикле у меня почему-то она исчезает и появляется...появется и все..потом еще пару раз..разглядеть что там написано невозможно...Вы не работали с ней?
Цитата: jacknk88 від Жовтень 01, 2012, 01:34:16 ПП
Uukrul
а что по поводу вот этого (http://abap-blog.ru/abap/abap-osnovi/user-interface/indikator-vypolneniya-zadachi/)
Ну там внутри используется вот это вот:
call function 'SAPGUI_PROGRESS_INDICATOR'
exporting
percentage = last_progress
text = l_text.
Приватный метод: VISUALIZE. так что ограничения те же...
Цитата: jacknk88 від Жовтень 01, 2012, 01:34:16 ПП
при использовании в цикле у меня почему-то она исчезает и появляется...появется и все..потом еще пару раз..разглядеть что там написано невозможно...Вы не работали с ней?
Ну если у тебя цикл отрабатывает один проход за какие-то 1000 или 10 000 миллисекунд, то что ты хочешь? Оно за это время по сети не успевает на клиента передаться и отрисовать данные, а ты уже новый вызов толкаешь. Общая рекомендация показать эту радость 4-6 раз за все время работы цикла, т.е. если у вас 10 000 шагов, то покажите индикатор прогресса выполнения через каждый 2000 шагов цикла. ВСЕ!
запуская индикатор даже через каждые 10% он мерцает, т.е. появляется и исчезает.
Uukrul, я все сделал как в вашем примере, кроме wait up to 1 seconds, разумеется...может ли вызов подпрограмм пакетного ввода прерывать визуализацию индикатора?
или может из-за этого
call transaction 'PA30' using bdcdata mode 'E' update 'A' MESSAGES INTO msg_tab.
Цитата: jacknk88 від Жовтень 03, 2012, 10:17:20 ДП
Uukrul, я все сделал как в вашем примере, кроме wait up to 1 seconds, разумеется...может ли вызов подпрограмм пакетного ввода прерывать визуализацию индикатора?
Может конечно. потому что пакетный ввод это фактически эмуляция запуска программы, а там могут быть свои виды на индикатор и на процессы, поэтому и мигает. Боюсь эту проблему можно обойти только если есть BAPI-функции подходящие для ввода требуемой информации. тогда мигать не будет. Ну по крайней мере проверил, если карточку ОС делать через BAPI, то все красиво идет, а если через вызов пакетника, то индикатор пропадает и снова появляется, я так понимаю у вас аналогичный эффект выходит.
Цитата: Uukrul від Жовтень 03, 2012, 12:45:27 ПП
я так понимаю у вас аналогичный эффект выходит.
а что, есть возможность заменить пакетный ввод в инфотип BAPI функциями?
вот это BAPI_PR_CREATE ?
если да, то какие +/- ?
и где можно почитать про них?
Uukrul ...Как Вы думаете: если заменить пакетник на BAPI функции можно ли уменьшить время работы программы?
Цитата: jacknk88 від Жовтень 04, 2012, 08:24:51 ДП
Uukrul ...Как Вы думаете: если заменить пакетник на BAPI функции можно ли уменьшить время работы программы?
Да BAPI существенно быстрее, как минимум не происходит эмуляции вызова экранов. Так же плюс BAPI функций, делать или нет COMMIT остается в вашем ведении, в отличии от пакетного ввода. Так же вы, в общем случае, получаете более развернутый журнал ошибок, типа почему не получилось что-то сделать. В общем если есть BAPI, то лучше использовать ее, чем пакетный ввод. Кстати, на транзакции с компонентами типа ALV и т.д., иногда пакетный ввод вообще не реально сделать.
PS: Как нибудь надо будет проверить скорость ввода, например создания карточек ОС через BAPI и пакетник.
спасибо....еслиЦитатаBAPI существенно быстрее
то в свободное время надо поискать их...программа работает реально долго с пакетником...
ЦитатаPS: Как нибудь надо будет проверить скорость ввода, например создания карточек ОС через BAPI и пакетник.
это я так понимаю через SE30 делается...
Цитата: jacknk88 від Жовтень 04, 2012, 02:26:16 ПП
это я так понимаю через SE30 делается...
Можно и так, но я наверное буду делать как это описано тут: http://sapforum.biz/index.php/topic,174.msg713.html#msg713
кстати, если использовать ФМ 'HR_INFOTYPE_OPERATION' (http://www.sapdev.co.uk/fmodules/fms_HR_INFOTYPE_OPERATION.htm), то индикатор работает лучше...исчезает правда, но зато можно следить за процентами))
возвращаясь к теме хотелось бы уточнить кое-какие моменты:
есть 2 способа программирования:
процедурное программирование
call function 'SAPGUI_PROGRESS_INDICATOR'
exporting
percentage = last_progress
text = l_text.
и
Объектно-ориентированное программирование
DATA:
go_progress TYPE REF TO CL_AKB_PROGRESS_INDICATOR.
CONSTANTS:
co_max_times TYPE i VALUE 100000.
INITIALIZATION.
IF go_progress IS NOT BOUND.
go_progress = CL_AKB_PROGRESS_INDICATOR=>get_instance( ).
ENDIF.
START-OF-SELECTION.
WRITE 'TEST'.
DO co_max_times TIMES.
go_progress->display(
EXPORTING
total = co_max_times
processed = sy-index
message = 'В процессе..' ).
ENDDO.
в первом случаи не надо мучаться с объектами, классами и методами..вставил ФМ и все.
во втором, надо немного повозиться...
так в чем плюс и минус использования этих методов в ABAP....??????
я так понимаю это влияет и на быстродействие, и на маштабируемость....вроде проще первый, но рекомендуют для командной работы использовать второй....вы Uukrul как человек с большим стажем в ABAP возможно даже сталкивались с проблемами связанными с этим и чтобы Вы порекомендовали?
кстати,
в первом случаи, есть небольшое ограничение - вызов ФМ осуществляется только если разница между текущим и последним процентом больше 10%...может это специально сделали??
Цитата2. Данный ФМ блокирует за пользователем один из диалоговых процессов сервера приложений, которых и так не много. Соответственно если у нас в системе например 10 диалоговых процессов, то запустив программку с индикатором хода выполнения процесса 10 раз, пока программа не завершиться, никто живым в систему не войдет и не выйдет, за что можно получить по голове от администраторов системы.
method display .
data: p type f,
t type f,
q type f,
qi type i,
d type i,
l_display type abap_bool.
get time stamp field time_stamp.
if message is not initial and message ne text.
text = message.
l_display = abap_true.
endif.
if total > 0.
p = processed.
t = total.
q = p / t * 100.
qi = q.
if qi > 100. qi = 100. endif.
d = qi - last_progress.
if abs( d ) > 10.
l_display = abap_true.
last_progress = qi.
else.
l_display = abap_false.
endif. endif.
check l_display = abap_true or force_display eq abap_true.
visualize( ).
endmethod.
и еще момент,
если ФМ блокирует диалоговый процесс, то разблокировка происходит только после завершения работы программы или самого ФМ?....т.е. если вызов ФМ установить на каждые 20%, то все равно процесс будет заблокирован на время работы всей программы?
Цитата: jacknk88 від Жовтень 19, 2012, 12:04:46 ПП
и еще момент,
если ФМ блокирует диалоговый процесс, то разблокировка происходит только после завершения работы программы или самого ФМ?....т.е. если вызов ФМ установить на каждые 20%, то все равно процесс будет заблокирован на время работы всей программы?
В том то и проблема, что процесс блокируется за программой в которой идет вызов ФМ: SAPGUI_PROGRESS_INDICATOR. Причем пока программа что-то считает, например мы вызываем индикатор через каждый 20%, то статус процесса будет в статусе ожидает, причина GUI. Поэтому пока программа не завершит обработку, процесс будет заблокирован за программой на все время.
Цитата: jacknk88 від Жовтень 19, 2012, 09:36:34 ДП
в первом случаи, есть небольшое ограничение - вызов ФМ осуществляется только если разница между текущим и последним процентом больше 10%...может это специально сделали??
Вполне возможно, это сделано с целью минимизации обмена между рабочей станцией и сервером приложения.
Цитата: jacknk88 від Жовтень 19, 2012, 09:17:41 ДП
есть 2 способа программирования:
процедурное программирование
и
Объектно-ориентированное программирование
Да какие там проблемы, что кому ближе, тот такую методику и использует. Опять же давайте рассмотрим тот вариант, что я не занимался в этой жизни разработками типа IS ххх (т.е. писать решение например для гостиничного бизнеса в SAP, мне не приходилось), а все остальное в принципе, когда участвует 1-3 разработчика, пишущие какие-то локальные упрощения для работы с системой (варианты переписывания стандартной логики я не рассматриваю), с точки зрения быстродействия или дальнейшего сопровождения разницы не имеет. Нечитаемый код или сложный для сопровождения код, можно написать как процедурный так и объектно-ориентированный, все только зависит от разработчика.
понятно...спасибо
Цитата: jacknk88 від Жовтень 19, 2012, 09:36:34 ДП
кстати,
в первом случаи, есть небольшое ограничение - вызов ФМ осуществляется только если разница между текущим и последним процентом больше 10%...может это специально сделали??
Точнее не ФМ а вызов класса, как я понимаю.
На самом деле это сделано очень правильно и удобно. Так как,например у вас выбрано для обработки, например, 1000 записей. Выводить индикатор хода выполнения процесса после каждой записи будет замедлением выполнения обработки, а если выводить данные после каждых 100 записей, то это надо у себя в коде дополнительно напрягаться и считать эти шаги, а тут все за вас сделает класс, так что то, что там реализован шаг 10% очень правильно. Другое дело, что если бы класс писал я, то вот этот вот шаг я бы сделал с помощью параметра, т.е. хочешь 10% а хочешь 5%, а вообще хочешь и будет выполнятся обновление через, скажем каждый 25 записей, вот тогда бы эта штука была бы полностью универсальной. А так как обычно нет в жизни счастья 8)