Ритейл ориентированные хранилища данных (ч.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
Денис Мужжухин 24 апреля 2012, 08:57
При Механизм сбора данных в режиме реального времени
про ограничение в 100 тысяч записей и разработку для закрытия пакета - преувеличение, мне кажется. в BW 7.1 можно и по времени пакет закрывать. с регистрацией источника данных и SOAP тоже было бы все здорово, если бы его не надо было генерировать непосредственно в продуктивной системе (хотя транспорт сделать можно, но сервис будет работоспособным).
хотелось бы, чтобы автор привел хотя бы ориентировочные объемы загружаемых данных.
Спасибо
Комментарий от
Алексей Зимин
| 24 апреля 2012, 12:04
Мне всегда нравятся статьи описывающие реальный опыт, но не всегда этот опыт можно назвать best practice.
Данную статью корректнее было назвать - как сделать решение по загрузке чековых данных "на коленке". Это было бы честнее )
Ты элегантно оставил за кадром стандартные решения по загрузке POS данных - POS DM и/или SAP PI, в которых все эти задачи решаются стандартным способом. Понятно что они стоят денег, но,на мой взгляд, начинать выбор решения надо с них.
Также было бы интересно узнать - чем вызвана у бизнеса потребность видеть данные продаж онлайн? (данные складов видны и без POS)
Ну и конечно хочется иллюстраций (чем больше тем лучше) общей фразы "практика показала" !
С уважением,
Алексей
Комментарий от
Илья Муковоз
| 28 апреля 2012, 16:57
Денис Мужжухин 24 апреля 2012, 08:57
При Механизм сбора данных в режиме реального времени
про ограничение в 100 тысяч записей и разработку для закрытия пакета - преувеличение, мне кажется. в BW 7.1 можно и по времени пакет закрывать. с регистрацией источника данных и SOAP тоже было бы все здорово, если бы его не надо было генерировать непосредственно в продуктивной системе (хотя транспорт сделать можно, но сервис будет работоспособным).
хотелось бы, чтобы автор привел хотя бы ориентировочные объемы загружаемых данных.
Спасибо
Про объемы данных: приходилось перезаливать по 248тысч. чеков (когда в них исправили ошибку).
Комментарий от
Илья Муковоз
| 28 апреля 2012, 17:03
Алексей Зимин 24 апреля 2012, 12:04
Илья, добрый день!
Мне всегда нравятся статьи описывающие реальный опыт, но не всегда этот опыт можно назвать best practice.
Данную статью корректнее было назвать - как сделать решение по загрузке чековых данных "на коленке". Это было бы честнее )
Ты элегантно оставил за кадром стандартные решения по загрузке POS данных - POS DM и/или SAP PI, в которых все эти задачи решаются стандартным способом. Понятно что они стоят денег, но,на мой взгляд, начинать выбор решения надо с них.
Также было бы интересно узнать - чем вызвана у бизнеса потребность видеть данные продаж онлайн? (данные складов видны и без POS)
Ну и конечно хочется иллюстраций (чем больше тем лучше) общей фразы "практика показала" !
С уважением,
Алексей
Потребность бизнеса обусловлена желанием принимать правильные управленческие решения исходя из динамики текущих продаж.