Коллеги приветствую.
В общем проблема вроде бы простая - быстро сохранить записи инфотипа (менее 5 минут).
Есть записи инфотипа (порядка 5-10 на каждого сотрудника), сотрудников порядка 1,5 тыс.
нужно эти ~10000 записей сохранить.
1. Есть HR_INFOTYPE_OPERATION - отрабатывает больше 5 минут.
2. Есть cl_hrpa_infotype_container - отрабатывает ~5 минут.
3. Пакетный ввод даже не пробовал.
Другими средствами оперировать не умею.
Можно написать ФМ и отправить его в JOBу, но я как-то смутно представляю как можно потом проверить результат.
Кто-то может поделится нужным заклинанием?

Сап на аудите написал, что пользовать hr_.oper.. некошерно, надо через пакетник.
Незаконченные джобы в sm35 болтаются.
Дальше встает вопрос между трусами и крестиком, как у батюшки на нудистком пляже
В смысле, между прямыми инсертами в дб и тем самым пакетником.
Еще можно через idoc в xml попробовать, но вряд быстрее будет

Проблема с вылетанием по тайм-ауту или просто в том, что просто долго работает?
Если первое (по тайм-ауту), то, например viewtopic.php?f=13&t=27185& (по крайней мере у меня номано SAPGUI_PROGRESS_INDICATOR работает, опять же полосу выполнения показывает).
Если второе, то использование пакет.ввода навряд-ли существенно ускорит процесс по сравнению с HR_INFOTYPE_OPERATION.

Проблема первая и это WDA .

а какая изначальная задача, почему необходимо загонять себя в такие рамки, возможно, можно что-то распараллелить?

Фоновый режим (пакетный ввод) избавляет от проблемы вылета по таймауту. Мало того, в большой системе удобно обрабатывать ошибки типа "ТН блокирован" или "ЕдРасчета блокирована для ведения данных". Успешно обработанные ТН из задания удаляются, ошибочные - нет. Через некоторое время достаточно перезапусть задание

вот меня как раз и смущает что их надо кому-то перезапускать. Т.е. uname возможно уже не тот будет

Не понял. Если кто-то делает какую-то работу, в данном случае загружает данные, то важно ведь не то, что он запустил какую-то программу, а то, что данные загружены. Нужно ведь и проконтролировать результат. И это действие не зависит от способа загрузки, хоть в диалоговом, хоть в фоновом.
Если при загрузке возникли проблемы, то в диалоговом режиме их исправлять сложнее. Диалог может вылетить по таумауту (нужно понять где остановились и перезапустить с этог места). Загрузка может быть не выполнена по части данным (нужно понять из-за чего, выявить эту часть и перезапустить).
В пакетном вводе таумаута не будет. Если часть загрузки не выполнена, то она остается в задании, и если проблема какая-то внешняя, то достаточно перезапустить задание, так как там останется только невыполненая часть.

Пример. Система большая с подразделениями по всей стране. Мне нужно для запуска какой-то подсистемы загрузить данные в ИТ. Практически гарантирую, что на момент загрузки какой-то ТН будет блокирован каким-то пользователем, а возможно что какие-то ЕдРасчета будут заблокированы. С фоновой загрузкой все просто. Запускаю. Для части ТН загрузка будет выполнена (они уйдут из задания), для части - нет. Мне не нужно их искать для запуска загрузки еще раз, я просто перезапускаю задание.

Сбрасывайте буфер, при работе через HR_INFOTYPE_OPERATION
http://www.google.ru/#hl=ru&source=hp&biw=1276&bih=789&q=HR_PSBUFFER_INITIALIZE+HR_INFOTYPE_OPERATION&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=19a74332505fda1a

В нашем случае скорость увеличилась в ~100 раз.

Главный признак тормозов из-за буфера - быстрая деградация скорости обработки в зависимости от объема выборки. Я когда с этим в первый раз столкнулся, производил такие замеры. Программа производила обработку табельных номер. При ограничении выборки в 100 ТН программа работала со скоростью 1 ТН в секунду, 500 ТН работали со скоростью 1 ТН в 3 секунды, а 1000 ТН - 1 ТН в 10 секунд.

Спасибо всем кто откликнулся. Решил реализовать следующую схему.
При запуске вставки сохраняю в данные в таблицу БД. Для того чтобы не плодить таблиц (возможно еще для каких-то инфотипов понадобться) создам таблицу на подобие INDX и буду работать через import/export.
После сохранения запускаю прогу в JOB (будет отрабатывать под этим же пользователем). (запуск с 1 повтором через 30 минут)
Если какие-то табельные будут блокированы, то оправляю письмо:
1. Инициатору изменений - о том, что определенный список табельных был блокирован.
2. Тем кто блокирует с просьбой освободить условно говоря например через 30 минут.

При повторном запуске та же рассылка с требованием повторно повторить по указанному списку операцию.

Есть какие-то замечания?
Спасибо.

Что дальше делать инициатору, если что-то не загрузилось со второй попытки?

Зря усложняете систему, увеличиваете TCO.
Я бы остановился на пакетниках или, в зависимости от конкретной задачи, на прямом вводе в БД.

Инициатору придется связываться с блокирующими табельные пользователями.
ТСО - расшифруйте пожалуйста.
Прямой ввод БД - однозначно нет.

TCO - общая стоимость владения, поддержу sn

Кстати, lsmw еще неплохо использовать. Очень быстро загружает входные данные и по ним готовит пакетник. На этапе подготовки данных можно даже писать обработку на ABAP. Потом останется только пакетник запустить и проконтролировать.