Системный ландшафт SAP BW, проектируем на перспективу.
В данной статье рассматривается организация правильного системного ландшафта SAP BW, ориентированного на динамичное, итерационное развитие аналитической системы в многолетней; временной перспективе.
Обычно системный ландщафт SAP BW повторяет ландшафт SAP R/3 или ECC и включает в себя три базовые системы:
- BW DEV – система разработки
- BW QA – система тестирования
- BW PRD – продуктивная система
На этапе разработки и подготовки первого релиза аналитической системы поток изменений системы - линейный: BW DEV => BW QA => BW PRD, такой подход предполагает что разработки выполненные в BW DEV переносятся в BW QA систему, где производится их проверка и после подтверждения корректности работы разработка переносится в систему продуктивной эксплуатации: BW PRD.
Если речь идет о консалтинговой компании или на объекте внедрения формируется внутренний штат консультантов BW, которым необходимо «место» для обучения и экспериментов, в системный ландшафт SAP BW необходимо добавить систему «песочницу» - BW SANDBOX.
Система BW SANDBOX не должна быть связана с основным ландшафтом и предназначена в первую очередь для выполнения экспериментов и обучения консультантов.
В части организации процесса обучения пользователей имеются два рекомендованных подхода:
- Фиксирование разработки и формирование системы обучения BW TRAIN путем копирования из BW QA. Таким образом, процесс обучения пользователей проводится в системе с зафиксированным на определенную дату состоянием. В то же время доработка системы может продолжаться, но изменения не имеют оперативного отражения в системе обучения. Выравнивание систем может быть выполнено в «ручном режиме» путем переноса необходимых запросов. Преимуществом такого подхода является возможность быстрого получения системы обучения сразу с готовыми данными, т.к. делается копия с системы тестирования, которая уже наполнена тестовыми данными, на которых осуществляется проверка работоспособности.
- Второй подход: одновременный перенос настроек в две системы: BW QA и BW TRAIN. При таком подходе в настройках транспортной системы добавляется целевая группа, которая включает две системы: систему тестирования и систему обучения. Преимуществом такого подхода является то, что система обучения BW TRAIN будет максимально соответствовать системе тестирования и будет включать все последние доработки. Недостатком такого подхода является необходимость загрузки и перезагрузки данных в систему обучения при серьезных изменениях логики, что требует отвлечения ресурсов.
В больших компаниях, например, таких как банки или крупные корпорации,
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 6
Комментарий от
Виктор Долгов
| 01 марта 2013, 13:28
Спасибо за статью, но к сожалению не нашел в предложенных Вами системных ландшафтах самого главного.
Где SAP HANA?
С уважением
Виктор Долгов
Комментарий от
Олег Шкуренков
| 05 марта 2013, 00:26
Комментарий от
Илья Муковоз
| 15 марта 2013, 09:45
Виктор Долгов 01 марта 2013, 13:28
Илья, добрый день.
Спасибо за статью, но к сожалению не нашел в предложенных Вами системных ландшафтах самого главного.
Где SAP HANA?
С уважением
Виктор Долгов
SAP HANA - это совсем другая архитекктура, использование этого продукта пока узко специализировано, очень немногие Российские компании могут себе его позволить, поэтому данный вопрос может быть расмотрен в отдельном материале.
Комментарий от
неизвестного пользователя
| 14 ноября 2013, 09:19
С одной стороны в тексте прозвучала ключевая фраза: "все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV", но на схеме это никак не отражено.
Схема, я считаю, не правильная.
Дело в том, что данная схема предполагала ведение параллельных работ по поддержке существующего решения (исправление ошибок, мелкие доработки) и внедрение новой функциональности (существенные разработки).
Так вот, из предложенной архитектуры мы видим, что все наработки, связанные с исправлением ошибок будут потеряны с выключением "BW DEV", и ландшафт станет неконсистентным, т.е. "BW NEW DEV" не будет равен "BW PRD".
Можно поступить след. образом:
- скопировать "BW DEV" в "BW NEW DEV";
- текущие работы по поддержке существующего решения вести в "BW DEV"
- Новая функциональность должна настраиваться в "BW NEW DEV"
- И сам ландшафт должен выглядеть так:
(BW NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD)
таким образом, будет соблюдена консистентонсть систем, и не нужно инсталлировать одну лишнюю инстанцию (BW NEW QA)
С уважнием,
Владимир.
Комментарий от
Дмитрий Кириченко
| 21 января 2014, 17:01
Неизвестный пользователь 14 ноября 2013, 09:19
Касательно последней архитектуры.
С одной стороны в тексте прозвучала ключевая фраза: "все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV", но на схеме это никак не отражено.
Схема, я считаю, не правильная.
Дело в том, что данная схема предполагала ведение параллельных работ по поддержке существующего решения (исправление ошибок, мелкие доработки) и внедрение новой функциональности (существенные разработки).
Так вот, из предложенной архитектуры мы видим, что все наработки, связанные с исправлением ошибок будут потеряны с выключением "BW DEV", и ландшафт станет неконсистентным, т.е. "BW NEW DEV" не будет равен "BW PRD".
Можно поступить след. образом:
- скопировать "BW DEV" в "BW NEW DEV";
- текущие работы по поддержке существующего решения вести в "BW DEV"
- Новая функциональность должна настраиваться в "BW NEW DEV"
- И сам ландшафт должен выглядеть так:
(BW NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD)
таким образом, будет соблюдена консистентонсть систем, и не нужно инсталлировать одну лишнюю инстанцию (BW NEW QA)
С уважнием,
Владимир.
Последняя схема из статьи Ильи рабочая, но ресурсоемкая по "железу" и администрированию.
Встречаются схемы (BW DEV)=>(BW QA)=>(BW pre-PRD)=>(BW PRD), где (BW pre-PRD) - препродуктивная система,копия системы PRD на более легком "железе". Она используется для проведения регресс-теста и теста исправлений по поддержке. Активности по новым разработкам и исправлениям в рамках поддержки разводятся регламентными процедурами с созданием бэкап-запросов, фиксирующих версии объектов "до изменения".
Комментарий от
Илья Муковоз
| 27 марта 2014, 19:12
Неизвестный пользователь 14 ноября 2013, 09:19
Касательно последней архитектуры.
С одной стороны в тексте прозвучала ключевая фраза: "все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV", но на схеме это никак не отражено.
Схема, я считаю, не правильная.
Дело в том, что данная схема предполагала ведение параллельных работ по поддержке существующего решения (исправление ошибок, мелкие доработки) и внедрение новой функциональности (существенные разработки).
Так вот, из предложенной архитектуры мы видим, что все наработки, связанные с исправлением ошибок будут потеряны с выключением "BW DEV", и ландшафт станет неконсистентным, т.е. "BW NEW DEV" не будет равен "BW PRD".
Можно поступить след. образом:
- скопировать "BW DEV" в "BW NEW DEV";
- текущие работы по поддержке существующего решения вести в "BW DEV"
- Новая функциональность должна настраиваться в "BW NEW DEV"
- И сам ландшафт должен выглядеть так:
(BW NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD)
таким образом, будет соблюдена консистентонсть систем, и не нужно инсталлировать одну лишнюю инстанцию (BW NEW QA)
С уважнием,
Владимир.
Доработки учитываются - т.е. разработка нового функционала, нового релиза должна поддерживать и включать в себя текущие доработки. С точки зрения ресурсов - да, это трудоемко, но и выгода в конце значительная: практически бесшовная замена релиза.