Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => SE37 - Построитель функций => Тема начата: jacknk88 от Октябрь 08, 2012, 09:56:54 am
-
какие BAPI функции можно использовать вместо пакетного ввода в инфотип? и где можно их найти ?
-
какие BAPI функции можно использовать вместо пакетного ввода в инфотип? и где можно их найти ?
Ну обычно бапи-функции ищутся в транзакции BAPI, а там уже по разделам ищем. Там процентов 85 наверное есть. Остальное ищем.. ну как-то ищем.. мне сложно сказать как ищутся те оставшиеся 15%
-
Зв BAPI не знаю, а вот универсальный ФМ могу подсказать
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
infty = '0105'
number = pernr
SUBTYPE = '0010'
* OBJECTID =
* LOCKINDICATOR =
* VALIDITYEND =
* VALIDITYBEGIN =
* RECORDNUMBER =
record = i0105
operation = 'INS'
* TCLAS = 'A'
* DIALOG_MODE = '0'
* NOCOMMIT =
* VIEW_IDENTIFIER =
* SECONDARY_RECORD =
IMPORTING
RETURN = return
KEY = key
-
а можно описание входных и выходных атрибутов?...там на немецком все((
-
по скорости что быстрее будет ФМ или пакетник?
-
вроде как разобрался....надо объявить таблицу типа как у нужного инфотипа и закидывать туда значения...потом в поле record написать эту таблицу...все-таки что быстрее-то?
а как можно проверить скорость обеих способов?..поподробнее..плиз...я только начал изучать abap
-
пакетник - это универсальный framework для загрузки вообще всего. Этот ФМ тоже универсален, но исключительно для инфотипов. Поэтому ФМ быстрее.
-
пакетник - это универсальный framework для загрузки вообще всего. Этот ФМ тоже универсален, но исключительно для инфотипов. Поэтому ФМ быстрее.
Ну вообще то ФМ быстрее, так как по минимуму не вызывается и не отрабатывает логика экранов, которая сама по себе не быстрая.
-
спасибо всем....только вот почему-то с одним параметром срабатывает, а в цикле не хочет)))....будем искать
огромное спасибо ysichov
-
Я сам в цикле не пробовал, но читал на форумах, что этот ФМ использует буферизацию. И время от времени ее нужно сбрасывать. Гуглите название ФМ - обязательно найдете полезную информацию
-
нашел вот (http://www.sapdev.co.uk/fmodules/fms_HR_INFOTYPE_OPERATION.htm)
надо до вызова ФМ сделать блокировку записи на изменения другими:
"This code is requred and locks the record ready for modification
CALL FUNCTION 'HR_EMPLOYEE_ENQUEUE'
EXPORTING
number = p_pernr.
а после разблокировать
"unlock record after modification
CALL FUNCTION 'HR_EMPLOYEE_DEQUEUE'
EXPORTING
number = p_pernr.
и так как объем записей большой,
этот ФМ использует буферизацию. И время от времени ее нужно сбрасывать.
то commit лучше сделать при вызове ФМ ....
nocommit = 'X'
-
а чем BAPI от ФМ отличаются?
-
а чем BAPI от ФМ отличаются?
в свойствах функционального модуля разрешен удаленный вызов из других программ: SAP, Java, Visual Basic и т.д.
-
в свойствах функционального модуля разрешен удаленный вызов из других программ: SAP, Java, Visual Basic и т.д.
Ну я бы не сказал что это так, от того что я напишу какой-то функциональный модуль и поставлю у него в параметрах разрешение удаленного вызова, он вряд ли станет носить гордое имя BAPI 8) Вообще расскажу так байку может быть. И так писали они систему SAP, ну кто как мог так и писал, одни когда писали, писали по типу.. логика экранов, логика проверки введенных данных, записи данных в таблицы и т.д. При этом это все там было так тяжело перепутано, что если мне надо было бы программно сохранить документ, например движения материала, то.. кроме как написать пакетный ввод, что долго, криво и... иногда невозможно, если там используется что-то типа активХ компонентов. А вот другие бойцы, которые писали WMS, пошли по другому пути, они написали обработку логики экранов, но нажав кнопку сохранения, вызывается функциональный модуль, в который передаются введенные на экране пользователем данные, после чего модуль проверяет данные и или возвращает ошибки или сохраняет документ, причем COMMIT, вы чаще всего можете задавать сами после вызова ФМ, если небыло ошибок, например. В общем мне чертовски нравится как это сделано при реализации WMS и абсолютно не нравится, как это было криво написано в ММ. В общем все как-то шло, не шатко не валко, пока в 4.5А появилась транзакция MIGO, на которую написать пакетный ввод в принципе не очень реально и тогда, тогда SAP родил функциональный модуль BAPI_GOODSMVT_CREATE, который конечно не используется в самой транзакции, но который по заявлениям позволяет создавать документы ММ, а про пакетный ввод, рекомендуется забыть. И тут SAP понял, что вот эту вот красоту, можно так сказать завернуть и назвать по новому, так с версии 4.5А, то что и так было до этого, а именно функциональные модули, вдруг стали почему-то называться, одни просто ФМ, а другие BAPI - как там Бизнес Апликейшен Программ Интерфейс. Разница, да никакой, например для WMS модули остались те же, что и были, но без приставки BAPI, зато новые правильные функции создающие объекты системы стали иметь приставку BAPI. В принципе их стало проще искать 8), хоть за это так сказать спасибо. В принципе BAPI это функциональный модуль который позволяет создать целостный объект системы, например выше приведенный BAPI_GOODSMVT_CREATE позволяет создать документ движения материала или сообщить о причинах, по которым это нельзя сделать, с другой стороны такой вот ФМ как FI_HEADER_UPDATE (http://sapforum.biz/index.php/topic,2209.0.html) ни в коем случае не является функцией BAPI, так как просто выполняет обновление таблицы базы данных без каких-либо проверок, что позволяет просто завалить систему. В общем деление между BAPI или не BAPI функциями, иногда очень условное...
-
даааа...интересно вышло....немного истории не помешает ;)...а то я думал почему для реалезации одной задачи можно воспользоваться как BAPI, так и ФМ или как я начинал пакетником :)...спасибо за историю
-
А не могли бы вы рассказать что такое BADI ?
-
А не могли бы вы рассказать что такое BADI ?
Ну если опять же пойти в историю, то SAP это не 1С и прежде всего не потому, что у него функций больше или меньше, а потому что SAP держит систему целостной в отличии от 1С и именно это преимущество дает возможность миграции с версии на версию, без написания каких-то загрузчиков данных из версии ХХХ в версию ZZZ. Ну да в общем это как бы лирика, а жизнь показала, что система кроме того что должна быть настраиваемая, так же должна быть и дописываемая пользователями, но тут сразу же есть противоречие, дать дописывать - потерять контроль на кодом бизнес-приложений системы, поэтому первое что придумали в SAP, не знаю когда я систему только с 3.0 видел, но это то что называется - пользовательское расширение (UswerExits) реализовано это было следующим образом в коде системы, в контрольных точках (по мнению разработчика кода) вставлялся код вида "call customer-function "001"", т.е. в этом месте происходил вызов пользовательского расширения, по факту разработчик передавал что-то в эту функцию, а на выходе ждал от вас например краткий текст документа, при этом вся эта кухня активировалась через специальные транзакции SMOD/CMOD, т.е. ведение так называемых проектов расширений.
Время шло, SAP переехал местами на объектный SAP, а имеющиеся расширения давно перестали удовлетворять многих, по простой причине, если расширение нужно было двум или трем разработчикам, то тут начинали возникать определенные проблемы, особенно при долгой жизни системы, т.е. код в экзите рос, писали его люди разные и часто как все понимают, чужая душа потемки, так и чужой код еще большие проблемы, да и не очень все читабельно я скажу вам выходило. Поэтому появились BADI - бизнес расширение, фактически тот же самый экзит, но реализованный через технику ООП, т.е пишется интерфейс, а уж его реализация это дело пользователя. В коде это все выглядит где-то так:
IF lref_badi_search IS INITIAL.
* Returns a reference to a generated exit class
CALL METHOD cl_exithandler=>get_instance
EXPORTING
exit_name = lv_exit_name
null_instance_accepted = true
CHANGING
instance = lref_badi_search.
ENDIF.
* call the BADI method.
CALL METHOD lref_badi_search->access_rap_asg
EXPORTING
IS_RAP_ASG = ls_pv
IV_DIRECTION = lc_direction
IMPORTING
EV_PERC = lv_threshold_percent.
т.е. первый вызов получает имя класса реализующего расширение и далее идет вызов самого расширения. С точки зрения работы, ну другая транзакция SE18/SE19, ну другая технология, но в целом, те же самые экзиты, только вид с боку, но одно большое преимущество, происходящее от использования классов, а именно фактически система давала вам возможность писать наследуемый интерфейс, каждому разработчику свой и далее вызывала их последовательно, при этом отключение одной реализации не затрагивало коды реализаций других разработчиков, что несомненный плюс.
А дальше, дальше появилась головная боль профессиональных разработчиков, технология энхансментов и... понеслось. Это уже дальнейшее развитие технологии: Экзит -> BADI -> Энхансмент инструмент мощный, но... как говорит народная пословица, револьвер в руках в руках дикаря - гибель всему племени. Так и энхансмент в руках, не очень скажем, так опытного разработчика - полный белый писец все системе.
-
Большооое спасибо за пояснение. Теперь стало понятно что это за зверь.
-
а если ФМ для вызова транзакции по нужным полям...
задача в следующем:
необходимо из ALV вызвать инфотип с конкретным подтипом и Таб.Номером....как определить ячейку я знаю Uukrul
показывал...а вот как провалиться в инфотип с подтипом не знаю...
есть вариат того же пакетника и потом CALL TRANSACTION...
хотелось бы знать если ФМ уже готовый
-
а если ФМ для вызова транзакции по нужным полям...
Одного ФМ на все в системе нет, для ММ например такой модуль есть для вызова некоторых транзакций. А вот с HR это надо искать или кто подскажет.
есть вариат того же пакетника и потом CALL TRANSACTION...
хотелось бы знать если ФМ уже готовый
Да сделайте CALL TRANSACTION с параметром SKIP FIRST SCREEN и заданием параметров через SET/GET, ну если это возможно, опять же я HR не знаю, но практически во всей ERP это работает.