Сортировать:

Новое Популярное

Комментарий от Виталий Лупина 09 июня 2021, 23:50

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

Комментарий от Вячеслав Шиболов 07 июня 2021, 10:59

Добрый день коллеги,
1) Подскажите когда ждать SAP GUI 7.70 для MAC ?
2) Не могу поставить SAP Hana Studio на Big Sur, не подскажите как это сделать ? Прочитал все ноты но не смог запустить установку.

Александр, добрый день!
 
1) На Mac возможна установка только версии SAP GUI for Java, которая несколько отличается от версии для Windows. На текущий момент существует только версии 7.50. Как установить эту версию на Mac можно прочитать тут - sappro.sapland.ru/blogs/shibolov

Комментарий от Александр Кондратов 07 июня 2021, 00:39

Добрый день коллеги,
1) Подскажите когда ждать SAP GUI 7.70 для MAC ?
2) Не могу поставить SAP Hana Studio на Big Sur, не подскажите как это сделать ? Прочитал все ноты но не смог запустить установку.

Комментарий от Вячеслав Шиболов 29 апреля 2021, 21:41

Антон Муханин 11 апреля 2018, 00:20

дополнительно:
в системе DEV устанавливал SAP Note не из 000 Манданта и языком RU. В общем то именно это меня и насторожило сейчас )))

Коллеги, извините, что не ответил сразу. Не заметил комментариев.
Установка SAP notes через 000 мандант под языком EN на данный момент действительно ни чем не подкреплена. Такая рекомендация была в начале появления инструмента SAP Note Assistant в системах версии SAP R/3 4.6 и около них. Сейчас такой рекомендации нет. Можно устанавливать в рабочем манданте и под языком RU, если нет отдельных рекомендаций.

Комментарий от Михаил Сидорочкин 26 апреля 2021, 15:50

Хорошая библиотека и статья интересная. Если кому-то интересно, еще одна версия реализации без SPTA на базе aRFC: github.com/MikeSidorochkin/ABAP-Simple-Async-Framework

Комментарий от Михаил Сидорочкин 25 апреля 2021, 14:14

Михаил Сидорочкин 25 апреля 2021, 14:11

Чуть дополню. Функциональный метод в ABAP это именно метод с RETURNING параметром, это важно, т.к. результат работы функциональных методов можно использовать как READ позицию для передачи результата например в другие методы.
 
Т.е. метод с одним EXPORTING параметром не является функциональным. Подробнее тут: help.sap.com/doc/abapdocu_latest_index_htm

http:// help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/abenfunctional_method_glosry.htm

Комментарий от Михаил Сидорочкин 25 апреля 2021, 14:11

Чуть дополню. Функциональный метод в ABAP это именно метод с RETURNING параметром, это важно, т.к. результат работы функциональных методов можно использовать как READ позицию для передачи результата например в другие методы.
 
Т.е. метод с одним EXPORTING параметром не является функциональным. Подробнее тут: help.sap.com/doc/abapdocu_latest_index_htm

Комментарий от Александр Разинкин 21 апреля 2021, 06:10

Александр Носов 19 апреля 2021, 14:11

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

В финальном примере код выглядит так:
 
METHOD get_value_plus_one.
    DATA lv_value TYPE i.
 
    lv_value = if_ztable1_reader->read_value_by_doc_id( iv_doc_id ).
    IF lv_value IS NOT INITIAL.
      return_value = lv_value + 1.
    ENDIF.
  ENDMETHOD.
 
Бизнес-логика одна, она в коде представлена один раз и проходит по одному сценарию:
Шаг 1. Считать значение по ID;
Шаг 2. Прибавить 1.

Комментарий от Екатерина Баронина 19 апреля 2021, 15:36

Добрый день! В шаге1 Вы создаёте RMS_ID параметр ZSRM_DEMO_RMS_ID, а на рисунке 9  это уже Z_DEMO_RMS_ID. Это опечатка?

Комментарий от Александр Носов 19 апреля 2021, 14:11

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

Комментарий от Виктор Избитский 14 апреля 2021, 21:10

Олег Точенюк 14 апреля 2021, 19:59

Да нет,, просто не часто приходится переписывать систему, так что ну совсем не хватает производительности. Если случился дамп, то вряд ли перезапуск поможет, так как это что-то серьзное, ну у меня так обычно происходит. Осталное если честно времени особо не занимает, обычно больше времени, опять же у меня, занимает, это перепроектирование программы, которая изначально была расчитана на одни поток, чтобы она стало многопоточной.  Ну или изначальное проектирование мультипоточной программы.
 
Опять же если у вас все время пишутся мультипоточные программы, то конечно предложенный вариант удобен. Мне просто, за последние 3 года, адЫн раз пришлось такое делать и то связано это не с ускорением работы, а там просто параллельно процессы в мультимандантной среде запускались из мастер манданта, ну чтобы не тормозить процесс, все запускалось в параллельных процессах.
 
Но еще раз, в целом если вы делаете это раз в зеленую луну, как я например, то  проще выучить синтаксис стандарта и этого вполне достаточно.

Олег, я с вами согласен. Разумеется, если необходимость в параллельных вычислениях появляется один раз в пятилетку, то можно (и, наверное, нужно) использовать стандартные средства и благополучно забыть об этом.
У меня в то же время несколько другой опыт. Довольно часто приходится прибегать к распараллеливанию, чтобы обеспечить разумное время выполнения программы. Отсюда и создание этого API.

Комментарий от Олег Точенюк 14 апреля 2021, 19:59

Виктор Избитский 14 апреля 2021, 14:24

Олег, да, перед созданием этого API мне действительно не нравилось то, что вы назвали: для каждого нового отчета приходится создавать RFC ФМ, писать метод/процедуру, обработку ошибок, попытку перезапуска задачи, если, например, случился дамп.
Т.е. каждый раз приходится реализовывать процесс распараллеливания заново. А если использовать предложенную разработку, этого делать уже не нужно. По большому счету нужно только описать бизнес логику и все.
Может быть как раз из-за описанных проблем вы и использовали параллельное выполнение не так часто? ;-)

Да нет,, просто не часто приходится переписывать систему, так что ну совсем не хватает производительности. Если случился дамп, то вряд ли перезапуск поможет, так как это что-то серьзное, ну у меня так обычно происходит. Осталное если честно времени особо не занимает, обычно больше времени, опять же у меня, занимает, это перепроектирование программы, которая изначально была расчитана на одни поток, чтобы она стало многопоточной.  Ну или изначальное проектирование мультипоточной программы.
 
Опять же если у вас все время пишутся мультипоточные программы, то конечно предложенный вариант удобен. Мне просто, за последние 3 года, адЫн раз пришлось такое делать и то связано это не с ускорением работы, а там просто параллельно процессы в мультимандантной среде запускались из мастер манданта, ну чтобы не тормозить процесс, все запускалось в параллельных процессах.
 
Но еще раз, в целом если вы делаете это раз в зеленую луну, как я например, то  проще выучить синтаксис стандарта и этого вполне достаточно.

Комментарий от Александр Носов 14 апреля 2021, 16:38

Виктор Избитский 14 апреля 2021, 14:37

Текст вывода процента выполненных задач можно изменить, в отчете ZCONCURRENCY_API. Ищите вызов метода cl_progress_indicator=>progress_indicate.
Если в zif_capi_callable~call будет вызов MESSAGE TYPE 'S' ***, то статус будет отображаться корректно. Мерцаний и прочего нет. Т.е. все выглядит так, как-будто сообщения TYPE 'S' игнорируются.

Благодарю за ответы. Попробую библиотеку как будет подходящая задача.

Комментарий от Виктор Избитский 14 апреля 2021, 14:37

Александр Носов 14 апреля 2021, 14:02

А где настраивается текст вывода процента выполненных задач?
И еще вопрос, если в zif_capi_callable~call будет вызов MESSAGE TYPE 'S' ***, корректно ли будет статус отображаться (не будут ли мерцания или сброс текста)?

Текст вывода процента выполненных задач можно изменить, в отчете ZCONCURRENCY_API. Ищите вызов метода cl_progress_indicator=>progress_indicate.
Если в zif_capi_callable~call будет вызов MESSAGE TYPE 'S' ***, то статус будет отображаться корректно. Мерцаний и прочего нет. Т.е. все выглядит так, как-будто сообщения TYPE 'S' игнорируются.

Комментарий от Виктор Избитский 14 апреля 2021, 14:24

Олег Точенюк 14 апреля 2021, 11:58

"избежать существующих сложностей, возникающих при распараллеливании программ в ABAP" - А какие сложности то? Оформить вызов RFC и возвратную процедуру/метод написать? Честно не понял в чем біыли найдены сложности сложности? Ни разу не возникало если честно. Хотя в реальности раза 3 использовал параллельное выполнение.

Олег, да, перед созданием этого API мне действительно не нравилось то, что вы назвали: для каждого нового отчета приходится создавать RFC ФМ, писать метод/процедуру, обработку ошибок, попытку перезапуска задачи, если, например, случился дамп.
Т.е. каждый раз приходится реализовывать процесс распараллеливания заново. А если использовать предложенную разработку, этого делать уже не нужно. По большому счету нужно только описать бизнес логику и все.
Может быть как раз из-за описанных проблем вы и использовали параллельное выполнение не так часто? ;-)

Комментарий от Александр Носов 14 апреля 2021, 14:02

Виктор Избитский 14 апреля 2021, 13:32

Александр, спасибо за хорошие вопросы.
На счет примеров задач:
Могу привести примеры из модуля HCM. Пожалуй одна из самых распространенных задач это сбор какой-либо информации по сотрудникам и вывод ее, например, в MS Excel. Т.е. необходимо создать отчет. Время выполнения отчета в основном будет зависеть от количества задействованных процессов, количества обрабатываемых сотрудников и алгоритма считывания информации. Поэтому строгих цифр выигрыша в производительности привести не получится. Все очень зависит от конкретной ситуации. На практике был отчет, который до распараллеливания выполнялся более 4 часов, после распараллеливания ~15 минут.
По вопросам:
1. Да, процент выполненных задач выводится

2. На сколько я понял, вы имеете в виду ноты 734205 и 710920.
Я посмотрел код SPTA Framework'а, который используется в API и в нем, перед вызовом CALL FUNCTION STARTING NEW TASK нет проверки того, что еще есть свободные сеансы пользовательского интерфейса. Т.е. это ограничение стандартного фреймворка, и расширять его пока кажется плохой идеей. Добавил описание этого ограничения в документацию на GitHub.

А где настраивается текст вывода процента выполненных задач?
И еще вопрос, если в zif_capi_callable~call будет вызов MESSAGE TYPE 'S' ***, корректно ли будет статус отображаться (не будут ли мерцания или сброс текста)?

Комментарий от Виктор Избитский 14 апреля 2021, 13:32

Александр Носов 14 апреля 2021, 09:31

Интересная библиотека, Виктор, спасибо. Хочется еще услышать примеры реальных задач и цифр в выигрыше в производительности. Также есть несколько вопросов:
1. Может ли библиотека выводить в строке состояния процент выполненных задач?
2. Как насчет распараллеливания пакетного ввода? Там помимо ограничения максимального количества задач нужно проверять еще доступные диалоги, иначе будут дампы если пользователь решит открыть еще один режим во время выполнения параллельных операций.

Александр, спасибо за хорошие вопросы.
На счет примеров задач:
Могу привести примеры из модуля HCM. Пожалуй одна из самых распространенных задач это сбор какой-либо информации по сотрудникам и вывод ее, например, в MS Excel. Т.е. необходимо создать отчет. Время выполнения отчета в основном будет зависеть от количества задействованных процессов, количества обрабатываемых сотрудников и алгоритма считывания информации. Поэтому строгих цифр выигрыша в производительности привести не получится. Все очень зависит от конкретной ситуации. На практике был отчет, который до распараллеливания выполнялся более 4 часов, после распараллеливания ~15 минут.
По вопросам:
1. Да, процент выполненных задач выводится

2. На сколько я понял, вы имеете в виду ноты 734205 и 710920.
Я посмотрел код SPTA Framework'а, который используется в API и в нем, перед вызовом CALL FUNCTION STARTING NEW TASK нет проверки того, что еще есть свободные сеансы пользовательского интерфейса. Т.е. это ограничение стандартного фреймворка, и расширять его пока кажется плохой идеей. Добавил описание этого ограничения в документацию на GitHub.
1 2 3 4 5
...
120