Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => SE37 - Построитель функций => Тема розпочата: Uukrul від Травень 12, 2008, 03:47:52 ПП
В общем для работы с классификацией в системе написано довольно много всяких функций, полезных и местами не очень, но как мне кажется самым кошерным в данном случае является группа функций:
CLBPA - BAPIs Klassifizierung
Который содержит в себе следующие функции:
"BAPI_OBJCL_CREATE
"BAPI_OBJCL_CHANGE
"BAPI_OBJCL_CONCATENATEKEY
"BAPI_OBJCL_DELETE
"BAPI_OBJCL_EXISTENCECHECK
"BAPI_OBJCL_GETDETAIL
"BAPI_OBJCL_GETOBJECTS
"BAPI_OBJCL_GETSTATUS
"BAPI_OBJCL_SPLITKEY
"BAPI_OBJCL_GETCLASSES
"BAPI_OBJCL_GET_KEY_OF_OBJECT
"BAPI_OBJCL_GET_OBJECT_OF_KEY
"BAPI_OBJCL_CHANGE_KEY
"BAPI_OBJCL_CREATE_KEY
"BAPI_OBJCL_EXISTENCECHECK_KEY
"BAPI_OBJCL_GETCLASSES_KEY
"BAPI_OBJCL_GETDETAIL_KEY
"BAPI_OBJCL_GETOBJECTS_KEY
"BAPI_OBJCL_GETSTATUS_KEY
"BAPI_OBJCL_DELETE_KEY
"BAPI_OBJCL_SPLITKEY_KEY
"BAPI_OBJCL_CONCATENATEKEY_KEY
"CLBPA_DISPLAY_ALLOWED_VALUES
"ALE_OBJCL_CREATE_KEY
"IDOC_INPUT_CLASSIFICATION_CREA
Мне пока всем этим хозяйством, пользоваться не доводилось, так сказать нужды не было ::) пока. Но по мере востребования, примеры постараюсь выкладывать. Ну или если кто сам чего нароет, то может выкладывать.
Так сказать из последнего и наиболее часто используемого модуля BAPI_OBJCL_GETCLASSES. Полезного в нем не только то, что он читает класс, но так же может прочитать и значения признаков классификации объекта. В примере представлен вызов для чтения классификации CO-заказа.
DATA: l_aufk LIKE aufk,
l_count LIKE sy-tabix,
l_lvalues TYPE tabelle,
l_classtype_imp LIKE bapi1003_key-classtype,
l_objectkey_imp LIKE bapi1003_key-object,
lt_alloclist LIKE bapi1003_alloc_list OCCURS 1 WITH HEADER LINE,
lt_allocvalueschar LIKE bapi1003_alloc_values_char
OCCURS 1 WITH HEADER LINE,
lt_return LIKE bapiret2 OCCURS 1 WITH HEADER LINE.
cls_table: pt_anka.
SELECT SINGLE * INTO l_aufk
FROM aufk WHERE aufnr = 'Номер CO-заказа'.
IF sy-subrc <> 0. <заказ CO-не существует> ENDIF.
l_classtype_imp = '013'.
l_objectkey_imp = l_aufk-objnr.
l_lvalues = 'AUFK'.
CALL FUNCTION 'BAPI_OBJCL_GETCLASSES'
EXPORTING
objectkey_imp = l_objectkey_imp
objecttable_imp = l_lvalues
classtype_imp = l_classtype_imp
read_valuations = 'X'
TABLES
alloclist = lt_alloclist
allocvalueschar = lt_allocvalueschar
return = lt_return.
READ TABLE lt_return WITH KEY type = 'S'
id = 'CL'
number = '741'.
IF sy-subrc = 0. <Классификация к заказу прочитана> ENDIF.
Цитата: Uukrul від Травень 12, 2008, 04:42:52 ПП
Так сказать из последнего и наиболее часто используемого модуля BAPI_OBJCL_GETCLASSES. Полезного в нем не только то, что он читает класс, но так же может прочитать и значения признаков классификации объекта. В примере представлен вызов для чтения классификации CO-заказа.
а вот названия классов партий тоже можно или не к этой классификации?
Цитата: NachDenken від Травень 21, 2008, 11:00:48 ДП
а вот названия классов партий тоже можно или не к этой классификации?
Думаю можно... судя по всему группа функций общего назначения. Поиграюсь пример выложу.
Типа пришла зима, надо было этими ФМ-ками почитать классификацию партий. Ну что можно сказать, что таки работают
TABLES: mcha.
PARAMETERS: p_matnr LIKE mcha-matnr,
p_werks LIKE mcha-werks,
p_charg LIKE mcha-charg.
DATA: l_objectkey LIKE bapi1003_key-object,
l_classnum LIKE bapi1003_key-classnum,
l_status LIKE bapi1003_key-status,
l_standardclass LIKE bapi1003_key-stdclass.
DATA: lt_allocvaluesnum LIKE bapi1003_alloc_values_num
OCCURS 1 WITH HEADER LINE,
lt_allocvalueschar LIKE bapi1003_alloc_values_char
OCCURS 1 WITH HEADER LINE,
lt_allocvaluescurr LIKE bapi1003_alloc_values_curr
OCCURS 1 WITH HEADER LINE,
lt_return LIKE bapiret2
OCCURS 1 WITH HEADER LINE.
****
DEFINE ext_to_int.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = &1
importing
output = &2.
END-OF-DEFINITION.
****
* Имя класса партии значения которого хотим получить
l_classnum = 'BATCH_CLASS'.
* Сформировать ключ объекта партии
ext_to_int: p_matnr l_objectkey(18),
p_werks l_objectkey+18(4),
p_charg l_objectkey+22(10).
CALL FUNCTION 'BAPI_OBJCL_GETDETAIL'
EXPORTING
objectkey = l_objectkey
objecttable = 'MCHA'
classnum = l_classnum
classtype = '022'
keydate = sy-datum
unvaluated_chars = ' '
language = sy-langu
IMPORTING
status = l_status
standardclass = l_standardclass
TABLES
allocvaluesnum = lt_allocvaluesnum
allocvalueschar = lt_allocvalueschar
allocvaluescurr = lt_allocvaluescurr
return = lt_return.
READ TABLE lt_return WITH KEY type = 'S'
id = 'CL'
number = '731'.
IF sy-subrc = 0. WRITE: / 'Класс считан!'. ENDIF.
Собственно говоря в таблицах признаки и значения для объекта...
Работать то эти BAPI(особенно по чтению данных) работают, но на практике они применимы для небольшого количества вызовов в рамках одной программы.
Как часто это бывает у индусов, внутренние таблицы в функциях для внутреннего применения не очищаются.
Более того, внутренние таблицы не являются сортированными.
Как будет время побаловаться с SE30 - выложу примеры как для чтения данных классификации, так и для записи.
У меня получилась следующая оптимальная схема работы:
Чтение: напрямую из INOB + AUSP, если нужны текстовые значения из признаков - с помощью связки CAWN+CAWNT
Запись: через BAPI, для ускорения работы при большом объеме вводимых данных используется запуск ФМ в режиме STARTING NEW TASK ...PERFORMING ..
Цитата: Удав від Лютий 08, 2009, 11:27:59 ПП
Работать то эти BAPI(особенно по чтению данных) работают, но на практике они применимы для небольшого количества вызовов в рамках одной программы.
Ну никто не спорит, практически любая BAPI по чтению данных будет медленнее, чем чтение данных из таблицы внутри своей программы, так же это относится и к BAPI по записи данных, хотя конечно запись на несколько порядков сложнее, но в принципе тоже реализуема, хотя конечно вероятность повредить данные при прямой записи очень большая и можно легко отгрести от гнезда, за такие вещи ::), что касается вообще BAPI то конечно все зависит от требований, если нет массовой обработки данных, т.е. это диалоговая транзакция, то тут все равно основное время занимает ожидание ввода от пользователя, а BAPI это удобно, но если вам надо пройтись по всем классам, то... SELECT это ваш инструмент.
PS: Результаты сравнений производительности, хотелось бы конечно на посмотреть... думаю информация к размышлению будет полезная, да и тема уже есть подходящая http://sapforum.biz/index.php/topic,174.0.html (Оптимизация ABAP), так что будет время, ждем-с примеров.
Ну вот и результаты:
Чтение 1500 классификаций:
1. через BAPI ~ 20 с.
2. через SELECT из INOB + AUSP + CAWN + CAWNT ~6 c.
Изменение 190 классификаций партий через BAPI_OBJCL_CHANGE:
1. В цикле - 730 с.
2. В цикле с использованием STARTING NEW TASK в синхронном режиме с PERFORMING NEW TASK(количество процессов для классификации - 1) - 760 с.
3. В цикле с использованием STARTING NEW TASK в синхронном режиме с PERFORMING NEW TASK(количество процессов для классификации - 5) - 260 с.
ЗЫ: Как файлы измерений выкладывать - через файлообменники?
Цитата: Удав від Лютий 10, 2009, 05:24:49 ПП
ЗЫ: Как файлы измерений выкладывать - через файлообменники?
Не понял вопрос... имеется в виду как прицепить файл к сообщению?
Ну да :)
Цитата: Удав від Лютий 10, 2009, 05:55:11 ПП
Ну да :)
Ну тут все просто... мышаком клик в поле, дополнительный опции (выделено красным), дальше или руками или кнопка обзор для выбора пути к вложению. Если вложений несколько тогда мышкой по ссылке "Вложения", выделено черным, будут добавляться поля ввода. Пока можно 20 вложений, размером кажется не более 2 мб на один файл.
Результат SE30 по чтению классификации:
а) через BAPI (READ_BAPI...),
б) через SELECT (READ_AUSP)
в)по изменению классификации через BAPI(SAVE_BAPI...). Нужно заметить, что для очистки внутренних таблиц перед BAPI_OBJCL_CHANGE вызывается ФМ VB_INIT. Без него время выполнения было бы значительно хуже на большом количестве изменяемых классификаций.
Цитата: Удав від Лютий 10, 2009, 07:33:22 ПП
Результат SE30 по чтению классификации:
а) через BAPI (READ_BAPI...),
б) через SELECT (READ_AUSP)
в)по изменению классификации через BAPI(SAVE_BAPI...). Нужно заметить, что для очистки внутренних таблиц перед BAPI_OBJCL_CHANGE вызывается ФМ VB_INIT. Без него время выполнения было бы значительно хуже на большом количестве изменяемых классификаций.
Если не сложно, можно примеры выложить
save_bapi_head-44 партии.htm (10.96 Кб - загружено 40 раз.)
SAVE_BAPI-44 партии.htm (413.75 Кб - загружено 99 раз.)
Цитата: Uukrul link=topic=170.msg2411#msg2411 date=1231757741
Типа пришла зима, надо было этими ФМ-ками почитать классификацию партий. Ну что можно сказать, что таки работают
TABLES: mcha.
PARAMETERS: p_matnr LIKE mcha-matnr,
p_werks LIKE mcha-werks,
p_charg LIKE mcha-charg.
DATA: l_objectkey LIKE bapi1003_key-object,
l_classnum LIKE bapi1003_key-classnum,
l_status LIKE bapi1003_key-status,
l_standardclass LIKE bapi1003_key-stdclass.
DATA: lt_allocvaluesnum LIKE bapi1003_alloc_values_num
OCCURS 1 WITH HEADER LINE,
lt_allocvalueschar LIKE bapi1003_alloc_values_char
OCCURS 1 WITH HEADER LINE,
lt_allocvaluescurr LIKE bapi1003_alloc_values_curr
OCCURS 1 WITH HEADER LINE,
lt_return LIKE bapiret2
OCCURS 1 WITH HEADER LINE.
****
DEFINE ext_to_int.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = &1
importing
output = &2.
END-OF-DEFINITION.
****
* Имя класса партии значения которого хотим получить
l_classnum = 'BATCH_CLASS'.
* Сформировать ключ объекта партии
ext_to_int: p_matnr l_objectkey(18),
p_werks l_objectkey+18(4),
p_charg l_objectkey+22(10).
CALL FUNCTION 'BAPI_OBJCL_GETDETAIL'
EXPORTING
objectkey = l_objectkey
objecttable = 'MCHA'
classnum = l_classnum
classtype = '022'
keydate = sy-datum
unvaluated_chars = ' '
language = sy-langu
IMPORTING
status = l_status
standardclass = l_standardclass
TABLES
allocvaluesnum = lt_allocvaluesnum
allocvalueschar = lt_allocvalueschar
allocvaluescurr = lt_allocvaluescurr
return = lt_return.
READ TABLE lt_return WITH KEY type = 'S'
id = 'CL'
number = '731'.
IF sy-subrc = 0. WRITE: / 'Класс считан!'. ENDIF.
Собственно говоря в таблицах признаки и значения для объекта...
Небольшое уточнение, следует учитывать уровень партии, таблица TCUCH
" Определяем уровень партии (OMCT) spro- Общая логистика - Управление партиями - Уровень партии"
У меня например уровень партии "1 - Партия однозначно ведется на уровне материала", а в коде привязывается к уровню партии, как то не кошерно ;) (сказал же настроить на уровне завода, а мои настройщики настроили, по крайней мере в тестовом манданте.... ) .....
и так, код выглядит следующим образом (ссори, переделывать не стал, выдернул с BADi, думаю кому надо ls_ximseg-matnr поменяют на p_matnr)
DATA: l_objectkey TYPE bapi1003_key-object,
l_classnum TYPE bapi1003_key-classnum,
l_status TYPE bapi1003_key-status,
l_standardclass TYPE bapi1003_key-stdclass.
DATA: lt_allocvaluesnum TYPE STANDARD TABLE OF bapi1003_alloc_values_num,
lt_allocvalueschar TYPE STANDARD TABLE OF bapi1003_alloc_values_char,
ls_allocvalueschar TYPE bapi1003_alloc_values_char,
lt_allocvaluescurr TYPE STANDARD TABLE OF bapi1003_alloc_values_curr,
lt_return TYPE STANDARD TABLE OF bapiret2.
DATA: ls_ximseg TYPE LINE OF shp_imsegvb_t.
DATA: ls_ausp TYPE ausp.
************************************************
DEFINE ext_to_int.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = &1
importing
output = &2.
END-OF-DEFINITION.
************************************************
l_classnum = 'ZMM_BATCH_SEARCH'.
" Определяем уровень партии (OMCT) spro- Общая логистика - Управление партиями - Уровень партии
" 0 - Партии однозначно ведутся на уровне завода
" 1 - Партия однозначно ведется на уровне материала
" 2 - Партия однозначно ведется на уровне манданта
DATA: l_kzdch TYPE kzdch.
SELECT SINGLE kzdch INTO l_kzdch from TCUCH.
LOOP AT ct_ximseg INTO ls_ximseg.
" Сформировать ключ объекта материала
" !!! Внимание, зависит от уровня партии !!!*
CASE l_kzdch .
WHEN 0. " 0 - Партии однозначно ведутся на уровне завода
ext_to_int: ls_ximseg-matnr l_objectkey(18),
ls_ximseg-werks l_objectkey+18(4),
ls_ximseg-charg l_objectkey+18(10).
WHEN 1. " 1 - Партия однозначно ведется на уровне материала
ext_to_int: ls_ximseg-matnr l_objectkey(18),
* ls_ximseg-werks l_objectkey+18(4),
ls_ximseg-charg l_objectkey+18(10).
WHEN 2. " 2 - Партия однозначно ведется на уровне манданта
ext_to_int: ls_ximseg-charg l_objectkey+18.
ENDCASE.
CALL FUNCTION 'BAPI_OBJCL_GETDETAIL'
EXPORTING
objectkey = l_objectkey
" objecttable = 'MCHA' " При уровне партии на уровне мандата
objecttable = 'MCH1' " Партии (при межзаводском управлении партиями)
classnum = l_classnum
classtype = '023'
keydate = sy-datum
unvaluated_chars = ' '
language = sy-langu
IMPORTING
status = l_status
standardclass = l_standardclass
TABLES
allocvaluesnum = lt_allocvaluesnum
allocvalueschar = lt_allocvalueschar
allocvaluescurr = lt_allocvaluescurr
return = lt_return."lt_return.
" ..................
Дополнительно, как я понимаю, при межзаводском уровне партий вместо MCHA надо использовать табличку MCH1, т.е.
0 - Партии однозначно ведутся на уровне завода - таблица MCH1
1 - Партия однозначно ведется на уровне материала - таблица MCHA
2 - Партия однозначно ведется на уровне манданта - вот тут не ясно, скорее всего MCHA?
что то не вьяжется .... при "1 - Партия однозначно ведется на уровне материала" выборку надо делать с MCH1.
Цитата: Паганель від Вересень 06, 2010, 03:08:09 ПП
Дополнительно, как я понимаю, при межзаводском уровне партий вместо MCHA надо использовать табличку MCH1, т.е.
0 - Партии однозначно ведутся на уровне завода - таблица MCH1
1 - Партия однозначно ведется на уровне материала - таблица MCHA
2 - Партия однозначно ведется на уровне манданта - вот тут не ясно, скорее всего MCHA?
что то не вьяжется .... при "1 - Партия однозначно ведется на уровне материала" выборку надо делать с MCH1.
Немного не правильно, разберусь - отпишусь.
А для програм лучше использовать ФМ "VB_BATCH_DEFINITION"
DATA: gv_batch_level LIKE tcuch-kzdch. "Batch-Level
CALL FUNCTION 'VB_BATCH_DEFINITION'
IMPORTING
kzdch = gv_batch_level.
Цитата: Паганель від Вересень 06, 2010, 03:08:09 ПП
Дополнительно, как я понимаю, при межзаводском уровне партий вместо MCHA надо использовать табличку MCH1, т.е.
0 - Партии однозначно ведутся на уровне завода - таблица MCH1
1 - Партия однозначно ведется на уровне материала - таблица MCHA
2 - Партия однозначно ведется на уровне манданта - вот тут не ясно, скорее всего MCHA?
что то не вьяжется .... при "1 - Партия однозначно ведется на уровне материала" выборку надо делать с MCH1.
Разобрался
0 - Партии однозначно ведутся на уровне завода - таблица MCHA
1 - Партия однозначно ведется на уровне материала - таблица MCHA
2 - Партия однозначно ведется на уровне манданта - вот тут не ясно, скорее всего MCH1
P.S. Меня ввело в заблуждение название таблички MCH1 - "Партии (при межзаводском управлении партиями)", т.е. подразумевался уровень материала или манданта, не данные партии для завода
Как пример выборки и использования функции http://sapforum.biz/index.php/topic,1293.msg7719.html#msg7719
Цитата
REPORT zmm_test.
SELECTION-SCREEN BEGIN OF BLOCK 01.
PARAMETERS: p_matnr TYPE matnr.
PARAMETERS: p_charg TYPE charg_d.
PARAMETERS: p_werks TYPE werks_d.
SELECTION-SCREEN END OF BLOCK 01.
* 0 - Партии однозначно ведутся на уровне завода
* 1 - Партия однозначно ведется на уровне материала
* 2 - Партия однозначно ведется на уровне манданта
CONSTANTS: client LIKE tcuch-kzdch VALUE '2',
material LIKE tcuch-kzdch VALUE '1',
plant LIKE tcuch-kzdch VALUE '0'.
DATA: gv_batch_level LIKE tcuch-kzdch. "Batch-Level
DATA: gt_mch1 TYPE STANDARD TABLE OF mch1 WITH HEADER LINE.
DATA: gt_mcha TYPE STANDARD TABLE OF mcha WITH HEADER LINE.
START-OF-SELECTION.
CALL FUNCTION 'VB_BATCH_DEFINITION'
IMPORTING
kzdch = gv_batch_level.
CASE gv_batch_level.
WHEN client.
SELECT * FROM mch1
INTO CORRESPONDING FIELDS OF TABLE gt_mch1
WHERE
charg EQ p_charg.
WHEN material.
SELECT * FROM mch1
INTO CORRESPONDING FIELDS OF TABLE gt_mch1
WHERE
matnr EQ p_matnr
AND charg EQ p_charg.
WHEN plant.
SELECT * FROM mcha
INTO CORRESPONDING FIELDS OF TABLE gt_mcha
WHERE
matnr EQ p_matnr AND
charg EQ p_charg AND
werks EQ p_werks.
ENDCASE.
Небольшой примерчик использования BAPI_OBJCL_CHANGE
и ФМ для получения уровня партии и таблиц VB_BATCH_DEFINITION.
Оформлен как FORM fill_classifications, на вход передаются 2 структуры (данные позиции материала, в т.ч. партия и материал, и данные значений признаков).
" Значения признаков
DATA: BEGIN OF items.
DATA: dhsdat TYPE string.
DATA: lifnr type lifnr.
DATA: END OF items.
DATA: gt_mseg TYPE STANDARD TABLE OF mseg WITH HEADER LINE.
DATA: l_mseg type mseg.
START-OF-SELECTION.
items-dhsdat = '01.10.2010'.
SELECT * FROM mseg
INTO CORRESPONDING FIELDS OF TABLE gt_mseg
WHERE mblnr = '4900000591'
LOOP AT gt_mseg INTO ls_mseg.
PERFORM fill_classifications USING ls_mseg items.
ENDLOOP.
FORM do_fill_classifications
USING rs_mseg LIKE mseg
rs_items type items.
DATA: git_bapi1003 TYPE TABLE OF bapi1003_alloc_values_num,
git_values_char TYPE TABLE OF bapi1003_alloc_values_char,
git_values_curr TYPE TABLE OF bapi1003_alloc_values_curr,
git_bapiret2 TYPE TABLE OF bapiret2,
ls_bapiret2 TYPE bapiret2.
DATA: gs_bapi1003 TYPE bapi1003_alloc_values_num,
gs_values_char TYPE bapi1003_alloc_values_char,
gs_values_curr TYPE bapi1003_alloc_values_char,
gc_flag_x(1) TYPE c VALUE 'X'.
DATA: l_objectkey TYPE bapi1003_key-object.
* CHARACT Имя признака
* VALUE_CHAR Значение признака
* VALUE_NEUTRAL Значение признака
* CHARACT_DESCR Название признака
" Определяем уровень партии (тр. OMCT) spro- Общая логистика - Управление партиями - Уровень партии
" 0 - Партии однозначно ведутся на уровне завода - MCHA
" 1 - Партия однозначно ведется на уровне материала - MCH1
" 2 - Партия однозначно ведется на уровне манданта - MCH1
" KZDCH Уровень TCUCH-KZDCH
" KLART Класс TCLA-KLART
" OBTAB Таблица TCLT-OBTAB
DATA: l_objecttable TYPE bapi1003_key-objecttable. " OBTAB Таблица TCLT-OBTAB
DATA: gv_batch_level LIKE tcuch-kzdch. "Batch-Level
DATA: classtype TYPE tcla-klart.
CALL FUNCTION 'VB_BATCH_DEFINITION'
IMPORTING
kzdch = gv_batch_level
klart = classtype
obtab = l_objecttable.
CASE gv_batch_level.
WHEN 0.
"l_objecttable = 'MCHA'.
ext_to_int: rs_mseg-matnr l_objectkey(18),
rs_mseg-werks l_objectkey+18(4),
rs_mseg-charg l_objectkey+18(10).
WHEN 1.
"l_objecttable = 'MCH1'.
ext_to_int: rs_mseg-matnr l_objectkey(18),
rs_mseg-charg l_objectkey+18(10).
WHEN 2.
"l_objecttable = 'MCH1'.
ext_to_int: rs_mseg-charg l_objectkey+18.
ENDCASE.
REFRESH git_values_char.
gs_values_char-charact = 'ZMM_BATH_DHSDAT'.
gs_values_char-value_neutral = rs_items-dhsdat.
APPEND gs_values_char TO git_values_char.
gs_values_char-charact = 'ZMM_LIFNR'.
gs_values_char-value_neutral = rs_items-lifnr.
APPEND gs_values_char TO git_values_char.
APPEND gs_values_char TO git_values_char.
CALL FUNCTION 'BAPI_OBJCL_CHANGE'
EXPORTING
objectkey = l_objectkey
objecttable = l_objecttable " MCHA или MCH1
classnum = 'ZMM_BATCH_SEARCH' "Class Number
classtype = classtype " 022, 023
* STATUS = '1'
* STANDARDCLASS =
* CHANGENUMBER =
* KEYDATE = SY-DATUM
* NO_DEFAULT_VALUES = ' '
* IMPORTING
* CLASSIF_STATUS =
TABLES
allocvaluesnumnew = git_bapi1003
allocvaluescharnew = git_values_char
allocvaluescurrnew = git_values_curr
return = git_bapiret2.
IF sy-subrc NE 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'
IMPORTING
return = ls_bapiret2.
ENDFORM. " DO_CHANGE_CHARACTERISIC
Цитата: Удав від Лютий 10, 2009, 05:24:49 ПП
Ну вот и результаты:
Чтение 1500 классификаций:
1. через BAPI ~ 20 с.
2. через SELECT из INOB + AUSP + CAWN + CAWNT ~6 c.
Изменение 190 классификаций партий через BAPI_OBJCL_CHANGE:
1. В цикле - 730 с.
2. В цикле с использованием STARTING NEW TASK в синхронном режиме с PERFORMING NEW TASK(количество процессов для классификации - 1) - 760 с.
3. В цикле с использованием STARTING NEW TASK в синхронном режиме с PERFORMING NEW TASK(количество процессов для классификации - 5) - 260 с.
ЗЫ: Как файлы измерений выкладывать - через файлообменники?
Последовательность INOB + AUSP + CAWN + CAWNT не всегда правильно сработает. Там есть один подводный камень. Правильнее последовательность INOB + AUSP + KSSK + KSML, и на основании значений 2 столбцов из KSML тащить уже CAWN + CAWNT. BAPI этот момент учитывает, вы нет. Соответственно и результат тестирования будет другим.
Цитата: Паганель від Вересень 27, 2010, 12:03:16 ПП
Небольшой примерчик использования BAPI_OBJCL_CHANGE
и ФМ для получения уровня партии и таблиц VB_BATCH_DEFINITION.
Оформлен как FORM fill_classifications, на вход передаются 2 структуры (данные позиции материала, в т.ч. партия и материал, и данные значений признаков).
" Значения признаков
DATA: BEGIN OF items.
DATA: dhsdat TYPE string.
DATA: lifnr type lifnr.
DATA: END OF items.
DATA: gt_mseg TYPE STANDARD TABLE OF mseg WITH HEADER LINE.
DATA: l_mseg type mseg.
START-OF-SELECTION.
items-dhsdat = '01.10.2010'.
SELECT * FROM mseg
INTO CORRESPONDING FIELDS OF TABLE gt_mseg
WHERE mblnr = '4900000591'
LOOP AT gt_mseg INTO ls_mseg.
PERFORM fill_classifications USING ls_mseg items.
ENDLOOP.
FORM do_fill_classifications
USING rs_mseg LIKE mseg
rs_items type items.
DATA: git_bapi1003 TYPE TABLE OF bapi1003_alloc_values_num,
git_values_char TYPE TABLE OF bapi1003_alloc_values_char,
git_values_curr TYPE TABLE OF bapi1003_alloc_values_curr,
git_bapiret2 TYPE TABLE OF bapiret2,
ls_bapiret2 TYPE bapiret2.
DATA: gs_bapi1003 TYPE bapi1003_alloc_values_num,
gs_values_char TYPE bapi1003_alloc_values_char,
gs_values_curr TYPE bapi1003_alloc_values_char,
gc_flag_x(1) TYPE c VALUE 'X'.
DATA: l_objectkey TYPE bapi1003_key-object.
* CHARACT Имя признака
* VALUE_CHAR Значение признака
* VALUE_NEUTRAL Значение признака
* CHARACT_DESCR Название признака
" Определяем уровень партии (тр. OMCT) spro- Общая логистика - Управление партиями - Уровень партии
" 0 - Партии однозначно ведутся на уровне завода - MCHA
" 1 - Партия однозначно ведется на уровне материала - MCH1
" 2 - Партия однозначно ведется на уровне манданта - MCH1
" KZDCH Уровень TCUCH-KZDCH
" KLART Класс TCLA-KLART
" OBTAB Таблица TCLT-OBTAB
DATA: l_objecttable TYPE bapi1003_key-objecttable. " OBTAB Таблица TCLT-OBTAB
DATA: gv_batch_level LIKE tcuch-kzdch. "Batch-Level
DATA: classtype TYPE tcla-klart.
CALL FUNCTION 'VB_BATCH_DEFINITION'
IMPORTING
kzdch = gv_batch_level
klart = classtype
obtab = l_objecttable.
CASE gv_batch_level.
WHEN 0.
"l_objecttable = 'MCHA'.
ext_to_int: rs_mseg-matnr l_objectkey(18),
rs_mseg-werks l_objectkey+18(4),
rs_mseg-charg l_objectkey+18(10).
WHEN 1.
"l_objecttable = 'MCH1'.
ext_to_int: rs_mseg-matnr l_objectkey(18),
rs_mseg-charg l_objectkey+18(10).
WHEN 2.
"l_objecttable = 'MCH1'.
ext_to_int: rs_mseg-charg l_objectkey+18.
ENDCASE.
REFRESH git_values_char.
gs_values_char-charact = 'ZMM_BATH_DHSDAT'.
gs_values_char-value_neutral = rs_items-dhsdat.
APPEND gs_values_char TO git_values_char.
gs_values_char-charact = 'ZMM_LIFNR'.
gs_values_char-value_neutral = rs_items-lifnr.
APPEND gs_values_char TO git_values_char.
APPEND gs_values_char TO git_values_char.
CALL FUNCTION 'BAPI_OBJCL_CHANGE'
EXPORTING
objectkey = l_objectkey
objecttable = l_objecttable " MCHA или MCH1
classnum = 'ZMM_BATCH_SEARCH' "Class Number
classtype = classtype " 022, 023
* STATUS = '1'
* STANDARDCLASS =
* CHANGENUMBER =
* KEYDATE = SY-DATUM
* NO_DEFAULT_VALUES = ' '
* IMPORTING
* CLASSIF_STATUS =
TABLES
allocvaluesnumnew = git_bapi1003
allocvaluescharnew = git_values_char
allocvaluescurrnew = git_values_curr
return = git_bapiret2.
IF sy-subrc NE 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'
IMPORTING
return = ls_bapiret2.
ENDFORM. " DO_CHANGE_CHARACTERISIC
А чем вас не устроил VB_CHANGE_BATCH ? Он тоже позволяет классифицировать партию. Более того, у вас каждая партия обрабатывается отдельным LUW, а VB_CHANGE_BATCH позволяет запихнуть все обновления в один LUW.
Цитата: nick_papkov від Вересень 15, 2013, 02:49:20 ДП
А чем вас не устроил VB_CHANGE_BATCH ? Он тоже позволяет классифицировать партию. Более того, у вас каждая партия обрабатывается отдельным LUW, а VB_CHANGE_BATCH позволяет запихнуть все обновления в один LUW.
Ну вообще-то это разные функции, приведенная в качестве примера BAPI_OBJCL_CHANGE глобальная BAPI для изменения классификации любых объектов, а вот это VB_CHANGE_BATCH работает только с партиями, а тема называлась "Работа с классификацией в системе" без привязки к объекту классификации.
Цитата: Uukrul від Вересень 15, 2013, 10:27:01 ДП
Ну вообще-то это разные функции, приведенная в качестве примера BAPI_OBJCL_CHANGE глобальная BAPI для изменения классификации любых объектов, а вот это VB_CHANGE_BATCH работает только с партиями, а тема называлась "Работа с классификацией в системе" без привязки к объекту классификации.
Я не оспариваю, что BAPI_OBJCL_CHANGE - это универсальный инструмент на все случаи жизни :-). Но гайки можно закручивать как разводным ключом, так и ключом определенного размера под конкретную гайку :-). И в хозяйстве хорошего мастера есть и тот, и другой ключ. Поэтому и стоит упомянуть, что в частном случае можно использовать специализированные non-BAPI ФМ, если этого требует постановка задачи. Но вам как adminу виднее стоит это упоминать или нет.
Цитата: Uukrul від Травень 12, 2008, 03:47:52 ПП
В общем для работы с классификацией в системе написано довольно много всяких функций, полезных и местами не очень, но как мне кажется самым кошерным в данном случае является группа функций:
CLBPA - BAPIs Klassifizierung
Который содержит в себе следующие функции:
"BAPI_OBJCL_CREATE
"BAPI_OBJCL_CHANGE
"BAPI_OBJCL_CONCATENATEKEY
"BAPI_OBJCL_DELETE
"BAPI_OBJCL_EXISTENCECHECK
"BAPI_OBJCL_GETDETAIL
"BAPI_OBJCL_GETOBJECTS
"BAPI_OBJCL_GETSTATUS
"BAPI_OBJCL_SPLITKEY
"BAPI_OBJCL_GETCLASSES
"BAPI_OBJCL_GET_KEY_OF_OBJECT
"BAPI_OBJCL_GET_OBJECT_OF_KEY
"BAPI_OBJCL_CHANGE_KEY
"BAPI_OBJCL_CREATE_KEY
"BAPI_OBJCL_EXISTENCECHECK_KEY
"BAPI_OBJCL_GETCLASSES_KEY
"BAPI_OBJCL_GETDETAIL_KEY
"BAPI_OBJCL_GETOBJECTS_KEY
"BAPI_OBJCL_GETSTATUS_KEY
"BAPI_OBJCL_DELETE_KEY
"BAPI_OBJCL_SPLITKEY_KEY
"BAPI_OBJCL_CONCATENATEKEY_KEY
"CLBPA_DISPLAY_ALLOWED_VALUES
"ALE_OBJCL_CREATE_KEY
"IDOC_INPUT_CLASSIFICATION_CREA
Мне пока всем этим хозяйством, пользоваться не доводилось, так сказать нужды не было ::) пока. Но по мере востребования, примеры постараюсь выкладывать. Ну или если кто сам чего нароет, то может выкладывать.
Есть еще одна полезная функция CLAF_CLASSIFICATION_OF_OBJECTS. Позволяет считывать классификацию любого объекта при чем в зависимости от одного входного параметра выдает либо значение, либо код значения в случае ведения справочника данных. Более того по сравнению с BAPI_OBJCL_GETDETAIL позволяет сразу получить список заранее указанных признаков класса, а не все.
Цитата: nick_papkov від Вересень 15, 2013, 03:31:27 ПП
Поэтому и стоит упомянуть, что в частном случае можно использовать специализированные non-BAPI ФМ, если этого требует постановка задачи. Но вам как adminу виднее стоит это упоминать или нет.
Я не возражаю, просто предлагаю отдельно сделать тему где расписать использование этого ФМ: VB_CHANGE_BATCH на каком-то примере. Как в прочем и CLAF_CLASSIFICATION_OF_OBJECTS 8)
Цитата: nick_papkov від Вересень 15, 2013, 02:42:53 ДП
Последовательность INOB + AUSP + CAWN + CAWNT не всегда правильно сработает. Там есть один подводный камень. Правильнее последовательность INOB + AUSP + KSSK + KSML, и на основании значений 2 столбцов из KSML тащить уже CAWN + CAWNT. BAPI этот момент учитывает, вы нет. Соответственно и результат тестирования будет другим.
Никто не заставляет CAWN+CAWNT в JOIN с AUSP использовать. ;)
Для работы со справочными значениями оптимальнее искать значения справочников в цикле с последующим кэшированием.
Пример работы с классификацией, когда нужно выполнить классификацию объекта в своей программе. Стандартно SAP когда выполняет такие операции, то вы всегда переходите на стандартные экраны классификации, где выбираете класс и затем заполняете свойства признаков. Следовательно можно организовать вызов стандартных экранов для классификации объектов из своей программы. Данная программа небольшой пример классификации ОЗМ для вида класса 001. В принципе можно использовать любые допустимые в системы виды классов. Комментарии, по использованию вызываемых функциональных модулей в данном примере, в коде программы.
Внимание: Из особенностей работы, нужно понимать, что объект классификации и создаваемый объект системы, в данном случае ОЗМ, это разные вещи. Поэтому например кода материала '000000000500003609' в системе может и не существовать,но это не помешает сделать объект классификации с таким кодом объекта.
REPORT z_test_clas_mara.
DATA: l_updateflag LIKE rmclk-updat,
l_ok_code LIKE sy-ucomm,
l_object LIKE rmclf-objek,
l_objtxt LIKE rmclf-obtxt.
* Вызвать классификацию объекта
l_object = '000000000500003609'. "Код объекта, для 001 типа класса = полный номер ОЗМ
l_objtxt = 'Термометр 200'. "Крактий текст наименования, обычно текст ОЗМ
CALL FUNCTION 'CLFM_OBJECT_CLASSIFICATION'
EXPORTING
table = 'MARA' "Объект/таблица классификации
object = l_object
objtxt = l_objtxt
classtype = '001' "Вид класса
status = '1' "1 - создание, 2 - изменение, 3 - просмотр
initflag = 'X'
ref_datuv = sy-datum
IMPORTING
updateflag = l_updateflag "Требуется обновление, были изменения в классе
ok_code = l_ok_code "Команда выбранная пользователм на экране классификация
EXCEPTIONS
classification_not_found = 1
class_not_valid = 2.
* Получить параметры класса и значения признаков, заданные на экране классификации
DATA: lt_exp_ausp_tab TYPE rmclausp OCCURS 1 WITH HEADER LINE,
lt_exp_kssk_tab TYPE rmclkssk OCCURS 1 WITH HEADER LINE.
CALL FUNCTION 'CLFM_GET_INTERNAL_TABLES'
EXPORTING
i_allausp = 'X'
i_allkssk = 'X'
TABLES
exp_ausp_tab = lt_exp_ausp_tab "Данные признаков для классов, указанные на экране
exp_kssk_tab = lt_exp_kssk_tab. "Данные классов указаннные на экране классификации
* Если пользователь выбрал сохранить или стрелка далее на экране классификации и были изменения
* тогда вызвать сохранение объекта классификации.
IF ( l_ok_code = 'SAVE' OR l_ok_code = 'WEI1' ) AND l_updateflag = 'X'.
* Сохранить изменения классификации
CALL FUNCTION 'CUOB_COMMIT_WORK'
EXPORTING
on_commit = 'X'. "X - Сохранение в общем процессе обновления иначе немедленное сохранение
COMMIT WORK AND WAIT.
ENDIF.
* После выполнения COMMIT WORK данные вунтри функций рабоыт с классами очищаются, это занчит что функция
* CLFM_GET_INTERNAL_TABLES больше не будет возвращать значений параметров класса и признаков, поэтому
* необходимо по новму считать во внутренние структуры значения классификации объекта и признаков объекта
DATA: l_object_read LIKE rmclf-objek,
lt_allocations LIKE api_kssk OCCURS 1 WITH HEADER LINE.
* Прочитать имена классов которым классифицирован объект. В общем виде это может быть
* несколько классов для типа класса, в данном случае тип класса = 001 - ОЗМ
l_object_read = '000000000500003609'. "Код объекта, для 001 типа класса = полный номер ОЗМ
CALL FUNCTION 'CLAP_DDB_GET_CLASSIFICATION'
EXPORTING
object = l_object_read
obtab = 'MARA'
date_of_change = sy-datum
classtype = '001'
sort_posnr = 'X'
TABLES
allocations = lt_allocations
EXCEPTIONS
no_allocation = 1
foreign_lock = 2
system_failure = 3
set_aennr = 4
change_nr_not_exist = 5
date_in_past = 6
error_class = 7
error_date_restriction = 8
error_status = 9
OTHERS = 10.
* Прочитать параметры классификации объекта для кажадого класса
LOOP AT lt_allocations.
CALL FUNCTION 'CLAP_DDB_SHOW_CLASSIFICATION'
EXPORTING
class = lt_allocations-class
object = l_object
classtype = lt_allocations-klart
EXCEPTIONS
allocation_not_available = 1
class_not_found = 2
OTHERS = 3.
ENDLOOP.
* Теперь функция CLFM_GET_INTERNAL_TABLES будет возвращать данные классификации, значения признаков и т.д.
Транзакция MIGO, Post_Documetn и там я вызываю все рекомендованные Вами FM-ы.
Так вот один из всех, параметр LOBM_LIFNR не хочет добавляться в новую партию - не сталкивались с такой ситуацией и что можете посоветовать?
Цитата: nikitinas від Листопад 09, 2018, 09:14:21 ДП
Так вот один из всех, параметр LOBM_LIFNR не хочет добавляться в новую партию - не сталкивались с такой ситуацией и что можете посоветовать?
Так это вроде как системные признаки, они должны вестись автоматически при настройке соответствующих операций. Вам именно нужен точно этот LOBM_* или может создадите свой типа Z_LIFNR
К сожалению хотят список признаков в точности, как в партии ссылочного документа.
Цитата: nikitinas від Листопад 09, 2018, 03:06:11 ПП
К сожалению хотят список признаков в точности, как в партии ссылочного документа.
Я конечно допускаю, что может все таки причина в другом, но это специализированные признаки которые начинаются на LOBM_* и боюсь, что таки система их блокирует, но это только в отладке можно убедится так оно или нет. Ну чтобы ответить на их "хотят", как-то аргументировано.
Спасибо, так и придется делать.
Цитата: nikitinas від Листопад 09, 2018, 03:59:56 ПП
Спасибо, так и придется делать.
Хотелось бы конечно узнать результат, точнее подтверждение выдвинутой версии.