Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => Тема начата: Sly от Апрель 03, 2013, 10:30:32 am
-
Задача на самом деле следующая: избавиться от дампов, возникающих по причине превышения лимита времени. Программой вызывается BAPI, так что вариант оптимизировать код или резать данные на куски отпадает. Я решил разделить программу на две и отправлять часть с вызовом BAPI в фоновый режим (SUBMIT … VIA JOB …). Но тут же встал вопрос - как передавать данные в программу. Обычный EXPORT / IMPORT … TO MEMORY ID … здесь уже не работает, ибо разные сессии. Сейчас передаю данные через БД, это работает, но как-то оно всё-таки через одно место, хотелось бы организовать по-нормальному. Help даёт вариант EXPORT / IMPORT … TO SHARED MEMORY … ID …, но там есть проблема в том, что нужно указывать таблицу БД, которую система будет использовать в качестве структуры передачи данных. А вот с ней непонятно. Сделал свою таблицу, при активации программа выдаёт сообщение «Die Tabelle zpp_mwo_tab ist nicht EXPORT/IMPORT-fähig.». Попробовал ради эксперимента поменять тип данных и таблицу, взял стандартную саповскую. Та же ошибка. Help про таблицу даёт только фразу «For dbtab, you have to specify a database table from ABAP dictionary that has the same structure if stored in the database table itself.». То есть, нет никаких особых указаний, что за таблица должна быть. Может ли кто-нибудь подсказать, как правильно делать передачу данных через память в случае разных сессий? Есть ли другие способы избежать лимита по времени, не отправляя в фоновое задание?
-
Комментарий от Василия Ковальского (если кто не знает, не страшно)
Обычная ошибка при использовании команды IMPORT TO DATABASE – неверное использование таблице INDX. Таблица INDX весьма широко используется в стандартных программах. «Неискушенные АБАПеры»™, кладут в эту таблицу свои данные, а вот чистить за собой забывают. В результате таблица INDX заполнятеся всякой ерундой, расет и растет в размерах, что со временем может привести к снижению производительности стандартных программ. Поэтому при использовании IMPORT TO DATABASE можно рекомендовать создать свою собственную копию таблицы INDX, назвать ее, например ZTEST_INDX, и в ней хранить свои данных. Но убирать за собой нужно и в ней.
Созадать свою таблицу как копию INDX не проблема, пример на экране. Так что используем этот метод.
-
Прошу простить за ламерство, но для чего мне эта таблица? Это и есть та самая таблица, которую нужно указывать в EXPORT / IMPORT … TO SHARED MEMORY … ID …? Опять же, если там реально идёт сохранение данных, то зачем мне вообще таблица с такой структурой, когда я могу читать и сохранять данные в собственной таблице со своей структурой? Нет ли возможности просто передать что-то через память, не сохраняя ничего в БД?
-
Прошу простить за ламерство, но для чего мне эта таблица? Это и есть та самая таблица, которую нужно указывать в EXPORT / IMPORT … TO SHARED MEMORY … ID …?
Используйте операции EXPORT / IMPORT TO DATABASE. Вот для этой операции и нужна эта таблица чтобы не исползовать системную, которую активно используют стандартные программы системы. Ну это рекомендации лучших собаководов, ну чтобы не городить свою Z-таблицу нужной стрктуры, опять же если она одна то ладно, а если вам надо передвать 10 внутренних таблиц данных? Будем делать 10 Z-таблиц?
-
Ага, мысль я понял. Но получается, что SAP вообще не умеет в общую память передавать данные, не используя таблиц БД?
И ещё, прошу прощения, вернусь к изначальному вопросу: есть ли другие способы избежать лимита по времени, не используя SUBMIT … VIA JOB?
-
И ещё, прошу прощения, вернусь к изначальному вопросу: есть ли другие способы избежать лимита по времени, не используя SUBMIT … VIA JOB?
Ну если это не один длинный запрос и возможно вызвать COMMIT WORK, то вставляй его по тексту, оно приводит к сбросу счетчика времени работы процесса. Мне в длинных отчетах помогало. Базис правда может возражать 8).
-
Ага, мысль я понял. Но получается, что SAP вообще не умеет в общую память передавать данные, не используя таблиц БД?
Я честно говоря EXPORT / IMPORT … TO SHARED MEMORY не использовал, но думаю что должно работать. Просто не разобрались с вызовами.
-
Большое спасибо за информацию!
-
Я честно говоря EXPORT / IMPORT … TO SHARED MEMORY не использовал, но думаю что должно работать. Просто не разобрались с вызовами.
Я использовал, когда пришлось однажды UPDATE ФМ-ник расширять (процесс уже другой). Все нормально работало, без тормозов. Можно еще на классе сделать...
-
Есть ли другие способы избежать лимита по времени, не отправляя в фоновое задание?
Есть:
1.Запуск самой программы обработки в фоновом режиме. При этом разбивать ее на части не понадобится.
2.Вызов ФМ TH_REDISPATCH. Но базисники, как уже сказали, такому не обрадуются.
3.Вызов ФМ параллельно с помощью ..STARTING NEW TASK
-
Прошу простить за некропостинг, но проблемма, которую я считал решённой, таковой не оказалась.
От конструкции SUBMIT ... VIA JOB я отказался из-за проблем с передачей данных.
CALL FUNCTION ... STARTING NEW TASK запускает новый процесс, я думал, что это помогает, но, как оказалось в итоге, процесс тоже валится по таймауту.
CALL FUNCTION ... IN BACKGROUND TASK просто не работает. Хотя, возможно, я что-то не так делаю.
Попробовал вставить в программу TH_REDISPATCH. При однократном запуске не помогает. Запуск надо, видимо, в процесс (в циклы) вставлять, а у меня весь процесс одно большое BAPI. Последний факт накладывает существенное ограничение: я не могу ни разбить программу на части, ни оптимизировать по скорости.
У кого-нибудь будут ещё идеи, как обойти time-limit?
-
Небольшое добавление к предыдущему посту: CALL FUNCTION ... IN BACKGROUND TASK работает, процесс виден в SM58, но точно так же валится по time limit.
-
у меня весь процесс одно большое BAPI. Последний факт накладывает существенное ограничение: я не могу ни разбить программу на части, ни оптимизировать по скорости.
Ну так как вы не имеете доступа внутри BAPI, тогда обратись к вашему базису, пусть увеличивают время выполнения на процесс. Хотя не понятно почему при запуске в фоне падает? Там вроде как ограничений по времени нет.
-
Сам удивляюсь. Но падает, факт. Смотрел через SM58, потом через ST22. Настройки системы? Жду ответа от нашего базиса.
-
Настройки системы? Жду ответа от нашего базиса.
А в самом дампе на параметр rdisp/max_wprun_time посмотреть никак?
Там что-то типа такого текста:
The maximum runtime of a program is limited by the system profile
parameter "rdisp/max_wprun_time". The current setting is ХХХХ seconds.
-
В дампе мне его предлагают поменять. Циферок к нему нет, но я и так знаю, что лимит времени у нас 10 минут.
Я написал письмо базису с описанием проблемы, но он у нас в другой стране, реагирует обычно медленно, а сейчас вообще перестал реагировать.
Соответственно, мой вопрос: все ли средства ли я испробовал? Возможно, есть другой вариант обойти временной лимит, не меняя настройки системы?
-
Соответственно, мой вопрос: все ли средства ли я испробовал? Возможно, есть другой вариант обойти временной лимит, не меняя настройки системы?
Ну какой другой, если доступа к долго выполняющейся процедуре (BAPI) ты не имеешь. Похожу других методов у нас нет. :-\
-
К первому в базис тогда, однозначно, учиццо! Нефиг здесь некромунгировать 8).