подскажите плиз:

есть ли какой-нибудь механизм позволяющий агрегировать данные в дельта-очереди на стороне R\3?

например - есть данные по движению материалов. у каждого материала своя группа. стандартный используемый экстрактор - 2LIS_03_BF хранит данные по движению материалов. необходимо на сторону BW передавать уже сагрегированные данные по группам материалов (цель-снизить объем передаваемых данных-разгрузить сеть и BW). детальные данные в BW не нужны

1. настроить струкутру экстрактора
2. использовать другие экстракторы
3. использовать функционально расширение экстрактора

2-й пункт понятен, а как 1-й и 3-й решит эту проблему что-то не пойму ?

1. выкинуть если возможно не нужные поля из структуры
3. наверное погорячился

можно еще один пункт добавить - написать свой экстрактор )

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

например в дельта очереди лежат:
материал1 гр1 5
материал1 гр1 4
материал2 гр2 2

а надо чтобы BW получил:
гр1 9
гр2 2


возможно уже гдето торможу (конец дня:))

ндя... под конец дня и я торможу... если задача - разгрузить сеть и минимизировать объем передаваемых данных - то тогда либо другие экстакторы либо самописные... все остальные мои предложения - ф топку

А зачем такой гемор? на стороне BW и произойдет нужная агрегация данных

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

Я думаю что дельта очередь будет не очень большая, тем более можно чаще ее запускать. А так получается ты пытаешся решить задачу BW, собственно она то для этого BW и создана.

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

Ну тогда как я понимаю остается написание собственного экстрактора (с собственной дельтой). Задача как я думаю не тривиальная...

Чесно говоря, я вот не понимаю задачу минимизации трафика... у вас что, р3 стоит во владике а bw - в калининграде и связаны они модемом на 9600 ? вряд ли.. может все таки убрать требования минимизации трафика и просто обойтись стандартными экстракторами - выбирать то что они должны выбирать, а в само ХД грузить не материал ( как пример) а группу... Все будет красиво и замечательно

1. в том то и дело что во владике и калиниграде
2. повторяю-объем данных очень большой, систем r\3 несколько и bw просто не справляется(ведь надо обрабатывать данные от всех r\3 систем)-естественно ни о какой работе пользователей в системе не может быть и речи. а если необходим оперативный учет?что тогда?накладывать на BW задачи, которые по идее можно сделать на стороне r\3 ну совсем не есть хорошо.хотя тоже как посмотреть

А какая работа ползователей в момент загрузки? данные грузят ночью При этом при загрузке работать с объектами, в которые идут загрузки, работать нельзя. А если система не справляется - значит железо не приспособлено для решения возложенных на нее задач - делайте сайзинг или ставьте новый сервер приложений. И оптимизируйте правила загрузки и обновлений.

Оперативный учет в BW? а вы случаем не путаете транзакционную систему и Хранилище?

нет не путаю-в рамках оперативного учета в данных целях данные необходимо грузить раза 2 в неделю к примеру. и повторяю еще раз, грузить данные с десятков r\3 систем, в каждой из которых дельта содержит по несколько миллионов записей - такая загрузка будет выполняться не одну ночь с учетом стейджинга (заполнение и-кубов, агрегация,...). в конечном счете в BW будет огромный объем данных в ненужной абсолютно детализации. зачем тогда хранить детали если они все равно никогда не будут использоваться?делать дополнительные процедуры сжатия ипрочее, каждый раз при этом нагружая систему и админов - тоже не выход в данной ситуации. не лучше ли не заваливать хранилище всяким хламом в начальный момент загрузки?