BW - ник написал:
Lench написал:
да, 2LIS_*
а где почитать?

)
help.sap.com
sdn.sap.com
курсы

http://www.sap-si.com/files/BW_Logistic ... ussion.pdfhttps://www.sdn.sap.com/irj/sdn/weblogs ... b/wlg/1096Не поможет... Вернее поможет, но не очень.
"Голова - предмет тёмный и исследованию не подлежит(с)".
Еще НИКТО не смог полностью мне обьяснить как работает весь этот "Logistics Cockpit" "механизм".
1. Заполняем таблицы реорганизации. Эти таблицы существуют только для хранения исторических данных. Докопался до этих таблиц - типа кластерные с непонятной структурой. А самое главное на хрена они вообще нужны ? Если запустить RSA3 и посмотреть, что происходит в SM50, видно, что всё равно система обращается напрямую в логистические таблицы (VBAK, VBAP, VBUP и так далее в случае с 2LIS_11_*). Вопрос в студию: а на хрена козе этот боян с таблицами реорганизации ? Единственная версия - для улучшения скорости. При том, что новые данные не пишутся автоматически в таблицы реорганизации.
Для справки. Таблицы реорганизации можно "дополнять". То есть, если знаете каких номеров документов там нет, смело запyскаете процесс заполнения с нужными номерами. Дельта не пострадает.
2. Дельта. При сохранении документа, ( в зависимости от настроек, но в подавляющем большинстве случаев конфигурится именно так ) ссылки на изменённые документы пишутся в очередь LBWQ. Затем фоновым процессом данные оттуда выбираются и пишутся в дельта-очередь. Но в какой момент и как фиксируется факт изменения документа ? Идёт ли это через механизм Central change management-
таблицы CDHDR, CDPOS ?
(Все изменения в логистических документах записываются в эти таблицы
http://help.sap.com/saphelp_470/helpdat ... ontent.htm )
И вообще, в чём тайный смысл этой очереди LBWQ ?
Нота 505700
Цитата:
3. The new "queued delta" update method:
With this update mode, the extraction data for the affected application is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
Up to 10,000 delta extractions of documents to an LUW in the BW delta queues are cumulated in this way per DataSource, depending on the application.
If you use this method, it is also necessary to schedule a job to regularly transfer the data to the BW delta queues ("update collective run"). However, you should note that reports delivered using the logistics extract structures Customizing cockpit are used during this scheduling. There is no point in scheduling with the RSM13005 report for this update method since this report only processes V3 update entries. The simplest way to perform scheduling is via the "Job control" function in the logistics extract structures Customizing Cockpit. We recommend that you schedule the job hourly during normal operation - that is, after successful delta initialization.
In the case of a delta initialization, the document postings of the affected application can be included again after successful execution of the recompilation run in the OLTP, provided that you make sure that the update collective run is not started before all delta Init requests have been successfully updated in the BW.
In the posting-free phase during the recompilation run in OLTP, you should execute the update collective run once (as before) to make sure that there are no old delta extraction data remaining in the extraction queues when you resume posting of documents.
If you want to use the functions of the logistics extract structures Customizing cockpit to make changes to the extract structures of an application (for which you selected this update method), you should make absolutely sure that there is no data in the extraction queue before executing these changes in the affected systems. This applies in particular to the transfer of changes to a production system. You can perform a check when the V3 update is already in use in the respective target system using the RMCSBWCC check report.
НО в CRM все изменения записываются непосредственно в дельта-очередь. Количество данных в CRM не меньше, а зачастую и больше, чем, скажем в VA01/VA02. И никаких LBWQ. Так в чём пойнт ?