А самый простой и правильный выход - сделать правильную дельту на стороне исходной системы. Чтобы при такой ситуации:
"Из исходной системы в BW приходит не удаленная запись с 0RECORDMODE = D, а две записи оставшиееся, то есть новое состояние документа и именно эти две строки должны заменить три ранее сохраненные в кубе", в BW приходила правильная дельта с правильным 0RECORDMODE.

2 RSA1

Не понимаю! Например новые данные по одному документу попали в разные пакеты. В одном документе было 700 записей, в другом 1500. Всего документов загружается примерно 2000, какие-то больше размером, а какие-то небольшие. Берем примерный размер одного документа 2000 записей умножаем на среднее число документов 2000 и получаем 4 000 000 записей за загрузку. Теперь предположим, что размер пакета 100 000 записей. При обработке нашего документа Вы предлагаете читать данные из ODS (то есть уже здесь просматривается недостаток - ODS дублирует данные результирующего куба, а я как раз пытался избежать этого). Ну и как будет организовано чтение? 700 записей в первом пакете из 100 000 принадлежат одному документу, идут они в перемешку с данными других документов... Ну и...

Читать и анализировать надо ОДС, а не пакет. Лучше даже делать цепочку ОДС -> ОДС. В ОДС доступны ВСЕ данные запросом SELECT * FROM /BIC/AИМЯ_ОДС00.

И можно еще в цепочке процессов анализ производить Хотя поабапить придётся.

Грубо-говоря так:
- Прочитали запись в пакете.
- Определили сколько в исходной ОДС, сколько в целевой.

- Если пришло меньше -> соответствующие выводы
Ну и, к сожалению, наверное ЛОГ вести.

Вообщем всё это уже програмистские трики. "А кому сейчас легко(с)"

2 RSA1

Очень неудачно Ваше решение. Чтобы анализировать ODS надо иметь начальные данные для анализа, а это 700 записей размазанных по пакету из 100 000. Допустим, прочитали вы данные из этого ODS для этого документа. Получилось, например, 2500. Придется их сравнивать с 700 записями в пакете и генерировать D-записи, вставлять их DATA_PACKAGE (здесь заранее невозможно предсказать какой размер получится, ведь весь этот процесс повторяется для всех документов в пакете). Затем приходит очередь другого пакета, а в нем часть данных по документу, который уже обрабатывался в прошлом пакете. И как теперь читать данные из ODS? Вести лог? Не стоит ли сразу отбросить такое решение, как архитектурно неправильное?

Решение абсолютно неприемлемое. То что я предложил сравнительно легко реализуемо и работоспособно, но все равно спасибо за дискуссию.

Что касаемо ведения очереди на стороне исходной системы, то в принципе реализуемо, но опять таки - избыточность хранения, причем очень существенная - сама система хранит данные большого объема, очередь хранит данные большого объема (причем к исходному коду системы доступ запрещен), в BW-данные большого объема.

У вас что, финансовые документы содержат по 2500 позиций ?

Ну знаете, на вкус и цвет...

У вас, что, за ночь миллионы записей приходят ?

В чём сложность сделать примерно следующее:
В цепочке процессов

1. Данные удаляются ис 1-й ОДС.
2. Загружаются новые данные за ночь.
3. Анализируем данные в 1-м ОДС

SELECT DISTINCT Номера документов
Запоминаем и для каждого номера документа
SELECT COUNT Позиции INTO COUNT1

Для целевого ОДС
SELECT COUNT Позиции INTO COUNT2

IF CONT1 LT COUNT2
Надо генерить записи для удаления.
ENDIF.

И что, по каждому документу у вас может сгенериться по 2500 позиций ?

А разве кто-то говорил, что документы финансовые?!
Может и 5000 записей быть...

Генерить записи для удаления... вот я писал инструмент объединяющий данные куба и ODS, чтобы сгенерировать
сторнирующие записи Но в итоге буду использовать
все-таки стандартный ФМ удаления - так правильнее

Ладно, спасибо за обсуждение, тема практически исчерпана. Надеюсь сие описание станет полезным для тех, кто сталкнется с подобной задачей.

2RSA1:
Как мне кажется, perishkin, имел ввиду, что в программу обновления передастся только очередной пакет. Т.е. мы можем получить в одном пакете 30 записей для одного документа и, читая ОДС, увидим, что надо удалить 40 из имеющихся 70-ти, но эти 40 реально могут быть в следующем пакете (т.е. документ не изменился на самом деле). А самое главное - когда придет второй пакет, то мы пометим на удаление 30 записей из первого пакета (мы ведь не знаем о том, что они были в первом пакете)? Гарантии ведь нет, что все записи придут в одном пакете. Или я что-то не понял?

2Олл: Вообще мне хотелось бы узнать - это разве вообще правильно, удалять, факты из куба? MS AS, например, вообще не поддерживает удаление данных из куба - можно только сторнировать, т.е. добавить запись с тем же ключом, но с отрицательным значением. Вернее - скорее всего как-то можно это придумать как найти таблицу фактов в БД и выкусить оттуда запись, но эффективность такого решения будет, скорее всего, крайне низкой (там же индексы, в том числе кластерные, я полагаю, агрегаты автоматические и т.д.). А BW хорошо работает с удалениями данных из куба? У меня просто похожая задача, позиции фактур непроведенных могут исчезать без следа (плюс еще и перенумеровываются, причем происходит таким образом, что известно только об изменении фактуры, а что конкретно и с какой позицией - неизвестно). Пока придумал проведенные фактуры грузить дельтой, а непроведенные грузить полностью, а для отчета объединять мультиком, но, может быть, можно просто удалять из куба? Что в этом случае будет с агрегатами (или стандартный ФМ будет их пересчитывать после удаления?)?

Выборочное удаление из куба - стандартное средство, предлагаемое самим SAP. В администрировании куба оно есть, значит может быть использовано и в собственной программе.

Руль - стандартное средство управления автомобилем.
Но пересечение двойной сплошной (сделанное с помощью того же руля) -- весьма серьезное нарушение правил.

Есть некоторая вероятность, что удаляя из куба, можно ошибиться, тогда [censored]ец.

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

Является ли твой случай исключительным - решать только тебе.

1. Все данные хранятся в ОДС 2. Из ОДС 2 записи идут в КУБ(ы), для создания BEх-запросов.

2. Новые данные приходят в ОДС1. Перед загрузкой ВСЕ старые данные удаляются из ОДС1. ОДС1 Хранит данные за предыдущие 24 часа (или какой-там период загрузки).

3. По-хорошему, из цепочки процессов должна запускаться программа с SQL запросами, анализирующими данные в ОДС 1 и ОДС 2 (Что-то Аналогично тому, что я привёл выше). В этой программе видны ВСЕ позиции по каждому документу в обоих ОДС. И эта программа должна каким-то образом создать лог для тех позиций, которые должны быть удалены. Лог может быть своя таблица на стороне BW.

4. В правилах обновленуя МОЖНО добавить записи на удаление, причём надо тоже запоминать в таблице логов, какие позиции для каких документов уже добавлены.

Вот что я имел ввиду. Всё это требует программирования. Не ах как много, но повозиться придётся.

У нас реализовано что-то аналогичное. Из APO приходят N материалов, каждый имеет своё значение показателя (количество). Необходимо по определённому алгоритму РАСПРЕДЕЛИТь количество между ДРУГИМИ М материалами в соответствии с пропорцией и коэффициентами. (M <> N). Коэффициенты для распределения постоянно обновляются и временно-зависимы. При этом количество - величина постоянная. Сколько пришло - столько должно уйти. Это реализовано при помощи цепочек ОДС и АБАПа.

2 G

Это замечание по степени полезности их серии сообщений на стенках клозета "Будьте бдительны! Не забывайте снимать штаны, перед началом процесса!"

2 RSA1

Я же уже писал об избыточности данных в ODS2, которые дублируют данные куба. А при серьезном кубе, когда размерностей больше 16, еще надо и заниматься склейкой ключей, чтобы записхать их ODS2 и их сплитом перед обновлением в куб. Ну плохое это решение и на вкус и на цвет. Хотя я сам примерно так сделал старый проект и жалею, что только теперь сообразил, что надо делать иначе