Меню

Ритейл ориентированные хранилища данных (ч.3 on-line загрузка POS данных).

|

В данной статье будут рассмотрены три варианта загрузки POS данных в информационное хранилище SAP BW.

Ценность любого хранилища данных тем больше, чем быстрее обновляются в нем информация. Бизнес-пользователи, имеющие актуальное текущее состояние остатков на складах и видящие поток продаж в режиме реального времени, способны принимать оперативные и  обоснованные решения, способствующие оптимизации продаж и своевременному обеспечения пополнению запасов.

Одним из ключевых моментов при реализации мониторинга продаж является решение задачи on-line загрузки кассового потока (загрузка POS данных в хранилище данных).

POS терминалы, являясь генераторами потока чековых данных могут поставлять данные в различном виде: это и файлы, и записи в локальных таблицах OLTP базы данных и прямая запись на сервер сбора данных и прямая передача в информационное хранилище. Сейчас мы абстрагируемся от того, каким именно образом формируется поток POS данных и какими средствами происходит его формирование, это тема для отдельного, более детального рассмотрения. Сосредоточимся на задаче on-line загрузки потока в информационное хранилище SAPBW.

Для решения этой задачи в нашем распоряжении имеются следующие инструменты:

  • Механизм сбора данных в режиме реального времени (тр. RSRDA);
  • Механизм управления загрузками через штатные экстракторы под управлением цепочек процессов;
  • Механизм прямой записи данных с использованием BAPI;
  • Механизм модуля POS DM.

 Название метода

Преимущества

Недостатки

Механизм сбора данных в режиме реального времени (тр. RSRDA)

· Штатный механизм SAP BW;

· Работа механизма происходит полностью под управлением системы.

· Минимальный размер пакета данных равен  100тыс. записей;

· Требуется программная разработка для принудительного закрытия последнего неполного пакета данных.

· Требуется регистрация источника данных в системе или настройка интеграции с webserviceинтеграционной платформы.

· Не позволяет реализовать полноценный on-lineпоток данных в SAPBW.

Механизм управления загрузками через штатные экстракторы под управлением

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев5

Комментарий от  

Денис Мужжухин

  |  24 апреля 2012, 08:57

При Механизм сбора данных в режиме реального времени
 
про ограничение в 100 тысяч записей и разработку для закрытия пакета - преувеличение, мне кажется. в BW 7.1 можно и по времени пакет закрывать. с регистрацией источника данных и SOAP тоже было бы все здорово, если бы его не надо было генерировать непосредственно в продуктивной системе (хотя транспорт сделать можно, но сервис будет работоспособным).
хотелось бы, чтобы автор привел хотя бы ориентировочные объемы загружаемых данных.
 
Спасибо

Комментарий от  

Денис Мужжухин

  |  24 апреля 2012, 09:04

При Механизм сбора данных в режиме реального времени
 
про ограничение в 100 тысяч записей и разработку для закрытия пакета - преувеличение, мне кажется. в BW 7.1 можно и по времени пакет закрывать. с регистрацией источника данных и SOAP тоже было бы все здорово, если бы его не надо было генерировать непосредственно в продуктивной системе (хотя транспорт сделать можно, но сервис будет работоспособным).
хотелось бы, чтобы автор привел хотя бы ориентировочные объемы загружаемых данных.
 
Спасибо

опечатка вкралась: при транспорте сервис НЕ будет работоспособным из-за ссылки на структуру, которой нет

Комментарий от  

Алексей Зимин

  |  24 апреля 2012, 12:04

Илья, добрый день!
Мне всегда нравятся статьи описывающие реальный опыт, но не всегда этот опыт можно назвать best practice.
Данную статью корректнее было назвать  - как сделать решение по загрузке чековых данных "на коленке". Это было бы честнее )
Ты элегантно оставил за кадром стандартные решения по загрузке POS данных - POS DM и/или SAP PI, в которых все эти задачи решаются стандартным способом. Понятно что они стоят денег, но,на мой взгляд, начинать выбор решения надо с них.
Также было бы интересно узнать - чем вызвана у бизнеса потребность видеть данные продаж онлайн? (данные складов видны и без POS)
Ну и конечно хочется иллюстраций (чем больше тем лучше) общей фразы "практика показала" !
С уважением,
Алексей

Комментарий от  

Илья Муковоз

  |  28 апреля 2012, 16:57

При Механизм сбора данных в режиме реального времени
 
про ограничение в 100 тысяч записей и разработку для закрытия пакета - преувеличение, мне кажется. в BW 7.1 можно и по времени пакет закрывать. с регистрацией источника данных и SOAP тоже было бы все здорово, если бы его не надо было генерировать непосредственно в продуктивной системе (хотя транспорт сделать можно, но сервис будет работоспособным).
хотелось бы, чтобы автор привел хотя бы ориентировочные объемы загружаемых данных.
 
Спасибо

Минимальная гранулярность по времени для закрытия пакета демона - час, минуты не понимает. Загрузку через PI и зарегистрированный сервис  тоже проходили, если прием идет через реалтамовый механизм, то проблемы те же: размер пакета, время пакета.
Про объемы данных: приходилось перезаливать по 248тысч. чеков (когда в них исправили ошибку).

Комментарий от  

Илья Муковоз

  |  28 апреля 2012, 17:03

Илья, добрый день!
Мне всегда нравятся статьи описывающие реальный опыт, но не всегда этот опыт можно назвать best practice.
Данную статью корректнее было назвать  - как сделать решение по загрузке чековых данных "на коленке". Это было бы честнее )
Ты элегантно оставил за кадром стандартные решения по загрузке POS данных - POS DM и/или SAP PI, в которых все эти задачи решаются стандартным способом. Понятно что они стоят денег, но,на мой взгляд, начинать выбор решения надо с них.
Также было бы интересно узнать - чем вызвана у бизнеса потребность видеть данные продаж онлайн? (данные складов видны и без POS)
Ну и конечно хочется иллюстраций (чем больше тем лучше) общей фразы "практика показала" !
С уважением,
Алексей

Приветствую Алексей.
Потребность бизнеса обусловлена желанием принимать правильные управленческие решения исходя из динамики текущих продаж.