вот какая беда: вызываю call transaction 'FI02'...mode 'N' update 'S', потом делаю commit work and wait, затем хочу прочитать док-ты изменений по результатам вызова (транзакция отрабатывает без ошибок) черз ФМ CHANGEDOCUMENT_READ_HEADERS

Оно ессно их не видит (видимо изза асинхроннх обновлений) - под отладчиком видно, что документы ложатся в таблицу CDHDR гдето секунды через 3-5

Аналог ФМ enqueue-блабла-MKPF (см.схожую проблему http://www.sapboard.ru/forum/viewtopic.php?t=2571 ) не нашёл.

Как тогда правильно организовать задержку до физического обновления тбалицы док-тов изменений?

хм, а почему не подходит объект блокировки EFBNKA ?

Попробуй поставить в CALL TRANSACTION ... UPDATE 'L'.

спасибо, разобрался ... проблема - как всегда в hands.dll

а что не получалось-то, поделись опытом:)

делюсь - поспелил радоваться
работает 3 раза, потом несколько раз не работает ... изменения хекоторых полей схватывает с первого раза, некоторых вообще никогда

делал так:

*запомнили момент запуска транзакции
dt1 = sy-datum.
tm1 = sy-uzeit.
...

CALL TRANSACTION 'FI02' USING bdc
MODE cmode UPDATE 'S'
MESSAGES INTO messtab.
* сразу-же ожидаем окончания асинхр.обновления
CALL FUNCTION 'ENQUEUE_EFBNKA'
EXPORTING
MODE_BNKA = 'E'
MANDT = SY-MANDT
BANKS = 'RU'
BANKL = ibnka-BANKL
* X_BANKS = ' '
* X_BANKL = ' '
* _SCOPE = '2'
_WAIT = 'X'
* _COLLECT = ' '
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2
OTHERS = 3
.
if ( sy-subrc = 0 ).
CALL FUNCTION 'DEQUEUE_EFBNKA'
EXPORTING
MODE_BNKA = 'E'
MANDT = SY-MANDT
BANKS = 'RU'
BANKL = ibnka-BANKL
* X_BANKS = ' '
* X_BANKL = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
endif.

COMMIT WORK AND WAIT.

*тут уже разбор сообщений транзакции
clear msg.
read table messtab with key MSGTYP = 'S'.
...

* по документам изменений фиксируем факт замены
clear: tcdhdr,tcdhdr[].
clear: tcdshw,tcdshw[].

concatenate sy-mandt 'RU' into objid.
concatenate objid ibnka-BANKL
into objid separated by ' '
. "мандант+RU+пробел+бик

*читаем док-ты обновления с момента проводки FI02
CALL FUNCTION 'CHANGEDOCUMENT_READ_HEADERS'
EXPORTING
* ARCHIVE_HANDLE = 0
DATE_OF_CHANGE = dt1
OBJECTCLASS = 'BANK'
OBJECTID = objid
TIME_OF_CHANGE = tm1
* USERNAME = SY-UNAME
* LOCAL_TIME = ' '
* DATE_UNTIL = '99991231'
* TIME_UNTIL = '235959'
TABLES
I_CDHDR = tcdhdr
EXCEPTIONS
NO_POSITION_FOUND = 1
WRONG_ACCESS_TO_ARCHIVE = 2
TIME_ZONE_CONVERSION_ERROR = 3
OTHERS = 4
.
describe table tcdhdr lines n.

read table tcdhdr index 1.
CALL FUNCTION 'CHANGEDOCUMENT_READ_POSITIONS'
EXPORTING
* ARCHIVE_HANDLE = 0
CHANGENUMBER = tcdhdr-CHANGENR
* TABLEKEY = ' '
* TABLENAME = ' '
* IMPORTING
* HEADER =
TABLES
EDITPOS = tcdshw
* EDITPOS_WITH_HEADER =
EXCEPTIONS
NO_POSITION_FOUND = 1
WRONG_ACCESS_TO_ARCHIVE = 2
OTHERS = 3
.
describe table tcdshw lines n.

if ( n = 0 ).
* нет док-тов по этому банку
else.
* анализируем, что изменилось в реквизитах
loop at tcdshw
...

дык вот в итоге транзакция всегда отрабатывает и сообщает в messtab[] что банк успешно изменен, а документы изменений всеравно не успевают в CDHDR лечь (т.е. ФМ чтения заголовков возвращает их через раз), даже несмотря на принудительный ENQUEUE

Под отладчиком ессно все ок, т.к. выполняется медленнее, и док-ты успевают записаться в CDHDR до того как будет вызван ФМ - хоть таймер млин вешай

если не осуществлять принудительное деблокирование, отрабатывать так

А Делать 10 раз
А1 Считать блокировку
А2 Блокировки нет - выход из цикла
А3 блокировка есть - ждем секунду

и, кстати, не посмотреть ли на наличие блокировок на change document. ФМ для добавления документов обработки запускается как правило IN UPDATE TASK

чтото не совсем понимаю мысль - можно поподробнее про change document?

вторая часть снимается. Для change document объектов блокировки нет.

Другой вопрос, что change document создается вызовом подобным этому
CALL FUNCTION 'DOKUMENT_WRITE_DOCUMENT ' IN UPDATE TASK
EXPORTING OBJECTID = OBJECTID
TCODE = TCODE
UTIME = UTIME
UDATE = UDATE
...

при этом ФМ с параметром update module \ start delayed - т.е. обновление V2

может быть, commit wort все же не отрабатывает?

а первый вариант - с контролем блокировок, пробовали?

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

нужно не снимать блокировку, а ждать, пока система сама её не снимет. Например, используя примерно такой код
DO 30 TIMES.
CALL FUNCTION 'ENQUEUE_READ'
EXPORTING
GCLIENT = SY-MANDT
GNAME = 'ZCAT_MAT_CLASSIF'
GARG = l_arg
GUNAME = SPACE
IMPORTING
NUMBER = l_number
SUBRC = l_subrc
TABLES
ENQ = t_seqg3
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2
OTHERS = 3.

IF l_number = 0.
EXIT.
ENDIF.

ENDDO.

Разрешите поинтересоваться - я какая задача изначально стояла, зачем changedoc читать?

всё просто ... нужно раз в неделю в систему грузить актуальный справочник банков РФ (который из Центробанка расходится по всей стране). Мы получаем готовый полный файл, т.е. нужно сравнить его с тем что уже есть в системе, выявить банки к уалению, новые банки, плюс отследить по каким из существующих банков произошли изменения реквизитов.

С реквизитами еще хитрее - изменение какихто малоактуальных полей (например контактный телефон банка или почтовый индекс) отражается только в BNKA ... А вот смена к примеру корсчёта потянет кучу дополнительных проводок: замена корсчета в соотв.позициях основных записей дебиторов/кредиторов, СРЛов ...

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

Т.е. хочется "по факту" внесения изменений (когда новые реквизиты гарантированно легли в BNKA) делать расширенный контроль (а не тупо сравнивать отдельные поля ДО вызова транзакции FI02) и максимально автоматизировать тем самым контроль правильности банковских реквизитов - потомукак реально в САПе это очень криво сделано (практически никак)

Вы весь его грузите? Я правильно понял, что вы весь справочник загоняете по call tran 'FI02' в BNKA, а потом по CD отслеживаете изменения?
А не думали использовать только те банки, что реально нужны в работе? (по мере возникновения необходимости, через какой-либо интерфейс ввода нового банка в BNKA из "большой" базы). Наверняка реально и 10% базы ЦБ не используется в работе? Тогда и проверять можно было бы "со стороны" BNKA, "тупо сравнивая" с полной базой, и FI02 делать только для изменённых. Что я не учёл в своих рассуждениях?

ИМХО более простым, надёжным и главное быстрым (с точки зрения БД) будут просто два SELECTа из BNKA

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