Может кто-нибудь пояснить как обрабатывается дельта-обновление и нужно ли предпринимать дополнительные усилия для создания дельта - обновления в экстракторе реализованном на базе собственного ФМ. Кнопку "родовая дельта" я нажал, указал поле, в ФМ дополнительная обработка нужна?
Спасибо.

Конечно надо доп.усилия, чудес то не бывает. В функциональном модуле необходимо принимать параметр I_UPDMODE типа RSAAPI_IF-UPDMODE и корректно отрабатывать все его значения ('F','D','I','R','C'). Для примера можно посмотреть RSAX_BIW_GET_DATA. Из своего опыта могу сказать, что объем кода получается весьма приличный, в итоге дельта-функциональность была реализована обходным путем.

Добрый день!

Потребовалось грузить в БВ данные из таблицы J_3RKKRS. Экстрактор на основе ФМ, так как необходима достаточно серьезная обработка, в частности "вертикальное разрезание" данной таблицы. В этой таблице в R\3 за год собирается примерно 2.5 млн. записей, в результате обработки на выходе ФМ получаем примерно 5 млн. (Не спрашивайте зачем вообще это надо и почему нельзя было воспользоваться данными отдельных позиций ГК )
Возник вопрос о реализации дельта обновления. Сделал псевдо дельта обновление (через ОДС). Но консультанты по FI сказали, что так же возможно изменение исторических записей этой таблицы, поэтому необходимо реализовать дельту из R\3 (не грузить же ежемесячно от 15 млн. записей в ОДС).
Попробовал разобраться с ФМ RSAX_BIW_GET_DATA, но возникло несколько вопросов:
1. Выше писалось о том, что нужно обрабатывать режимы ('F','D','I','R','C') и код получается объемным.
В ФМ RSAX_BIW_GET_DATA я нашел только обработку
case i_updmode.
when 'F'.
when others.
if 1 = 2. message e011(r3). endif.
log_write 'E' "message type
'R3' "message class
'011' "message number
i_updmode "message variable 1
' '. "message variable 2
raise error_passed_to_mess_handler.
endcase.
Следовательно, на сколько я могу судить в мой ФМ просто нужно вставить этот код, плюс немного доработать напильником. Так ли это???
2. При реализации дельта обновления в ФМ с его помощью можно будет получать только обновленные данные, следовательно для полной загрузки нужно будет использовать другой ФМ???
3. Может кто нибудь знает, вообще в общем случае меняются ли данные в таблице J_3RKKRS для закрытих периодов??? Может и не стоит париться с дельтой из R\3 а всего лишь после закрытия грузить последний месяц и довольствоваться псевдо-дельтой

Что то я торможу...
case i_updmode.
when 'F'.
Это обработка только полного обновления... Нет ли стандартного ФМ с обработкой именно дельта обновления?

How To Create Generic DataSources which use the Delta Queue

Боюсь это не совсем то, что мне нужно... В примере создается экстрактор на ракурсе и делается обработка дельта обновления. Только не совсем понятно зачем все так усложнять, ведь на сколько мне известно для экстрактора да ракурсе достаточно настроить родовую дельту, привязав к определенному полю. (утверждать не буду, так как сам не делал реализацию дельты для Z* экстракторов, только читал).
У меня же экстрактор на ФМ. Можно конечно сделать доп. таблицу, которую заполнять как мне надо(а потом из нее грузить в БВ), но это тоже не праавильно, так как придется обрабатывать процесс ее заполнения опять же с учетом переноса только измененных или новых записей, да и дублировать данные в R\3 не есть хорошо.

А разве там дельту не ФМ собирает? Фул тоже можно сделать на ФМ подобно RSAX_BIW_GET_DATA_SIMPLE

Всё просто. В экстракторе родовую дельту делаете на поле CPUDT, в ФМ реализуете обработку ограничений по полю CPUDT, пример посмотрите в ФМ RSAX_BIW_GET_DATA_SIMPLE. Возможно для ускорения потребуется индекс на CPUDT.

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

Данный вариант прельщает больше!
Свой ФМ и так реализовал на основе RSAX_BIW_GET_DATA_SIMPLE.
Вы имеете ввиду просто добавить
loop at s_s_if-t_select into l_s_select where fieldnm = 'CPUDT'.
move-corresponding l_s_select to l_r_cpudt.
append l_r_cpudt.
endloop.
ну естественно еще дополнительно ограничив выборку этим полем
select * from j_3rkkrs where bukrs in l_r_bukrs
and belnr in l_r_belnr
and gjahr in l_r_gjahr
and budat in l_r_budat
and debet in l_r_debet
and kredit in l_r_kredit
and cpudt in l_r_cpudt.
и будет счастье?
А данное поле cpudt модифицируется при изменении записи в j_3rkkrs(т.е. будет ли отслеживаться изменение существующих записей?). Или в этой таблице вообще записи не модифицируются, а только добавляются новые?

А как отслеживать удаление записей через CPUDT ?

Этот вопрос тоже очень беспокоит! Воообще думаю на эту тему нужно поговорить в консультантами FI, узнать какие вообще модификации могут происходить с записями данной таблицы. Как узнаю, напишу.

Изменения там простые, если документ переразбирают, то все старые записи по документу удаляются и вставляются новые результаты разбора. Ключи в результате могут изменится, соответственно в правилах обновления DSO надо будет искать существующие записи по документу и добавлять их в пакет с recordmode = 'D'.

Добрый день
сейчас делаю Родовую на этом же поле.
что там сказали консультанты? что нового???
что то я даже не думал как это поле будет отслеживать удаления...
ну кроме сторнирования документов конечно, это проходит нормально

Все так и есть, как написал EvgenySA. Т.е. просто дельтой не отделаться. Еще на стороне БВ обязательно нужен DSO, так же нужна программа, так как может быть такая ситуация, что было 4 записи, а после переформирования стало 2. В этом случае в БВ имеем 2 лишние записи, которые сами никуда не исчезнут...