Меню

Системный ландшафт 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

Илья, добрый день.
 
Спасибо за статью, но к сожалению не нашел в предложенных Вами системных ландшафтах самого главного.
 
Где 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 NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD) не решает вопрос потери исправлений в системе (BW DEV), которые произошли после копирования  "BW DEV" в "BW NEW DEV".
Последняя схема из статьи Ильи рабочая, но ресурсоемкая по "железу" и администрированию.
Встречаются схемы (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)
 
С уважнием,
Владимир.

Ключевой момент в таком подходе описывается фразой "При таком подходе все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV".
Доработки учитываются - т.е. разработка нового функционала, нового релиза должна поддерживать и включать в себя текущие доработки. С точки зрения ресурсов - да, это трудоемко, но и выгода в конце значительная: практически бесшовная замена релиза.