Вот вы говорите: "Ландшафт, ландшафт... " А что такое ландшафт?
Давайте остановимся на этом понятии поподробнее.
Итак, в посте "Копирование манданта SAP системы" я приводил структуру данных SAP системы (рис. 1).
В ABAP части SAP системы выделяют автономные единицы для работы и хранения данных предприятия. Данные единицы носят название - мандант. Мандант содержит основные данные (Master Data), записи пользователей с полномочиями и манданто-зависимые настройки. Манданты идентифицируется троичным номером и их в системе может быть несколько. Теоретически 1000 штук.
Помимо манданта, в системе есть общие для всех мандантов данные: манданто-независимые настройки и репозитарий SAP системы. Репозитарий это прежде всего ABAP-программы (reports, функциональные модули, экраны и т.п.). К репозитарию так же относится и ABAP-словарь, про который я писал в посте "Транзакция SE14 : утилита базы данных".
Ландшафт, как я уже упоминал ранее, это объединение нескольких систем одного назначения/версии для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. Например, SAP ERP 6.0 EHP7 (кстати, самая распространенная версия по опросам) или SAP SRM 7.0 EHP3.
Ландшафты SAP систем могут быть:
Давайте остановимся на этом понятии поподробнее.
Итак, в посте "Копирование манданта SAP системы" я приводил структуру данных SAP системы (рис. 1).
 |
| Рис. 1. Структура данных в SAP системе. |
В ABAP части SAP системы выделяют автономные единицы для работы и хранения данных предприятия. Данные единицы носят название - мандант. Мандант содержит основные данные (Master Data), записи пользователей с полномочиями и манданто-зависимые настройки. Манданты идентифицируется троичным номером и их в системе может быть несколько. Теоретически 1000 штук.
Помимо манданта, в системе есть общие для всех мандантов данные: манданто-независимые настройки и репозитарий SAP системы. Репозитарий это прежде всего ABAP-программы (reports, функциональные модули, экраны и т.п.). К репозитарию так же относится и ABAP-словарь, про который я писал в посте "Транзакция SE14 : утилита базы данных".
Ландшафт, как я уже упоминал ранее, это объединение нескольких систем одного назначения/версии для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. Например, SAP ERP 6.0 EHP7 (кстати, самая распространенная версия по опросам) или SAP SRM 7.0 EHP3.
Ландшафты SAP систем могут быть:
- односистемными,
- двухсистемными,
- трёхсистемными.
Рассмотрим первый вариант - ландшафт SAP системы, состоящий из одной системы. Допустим, в одном манданте системы разработчики и консультанты производят настройки и пишут/изменяют ABAP-программы. А второй мандант системы выделен для работы пользователей (рис. 2).
 |
| Рис. 2. Односистемный SAP ландшафт. |
В плане разграничения доступа - всё хорошо. Пользователи в разных мандантах разные. И консультанты и разработчики не имеют доступ к основным данным предприятия (например, заработной плате), так как работают в отдельном манданте. Но представьте, что будет, если разработчик активирует новую версию программы при работающих с ней пользователях? Будет несколько дампов (равных количеству работающим с программой пользователей) и все результаты работы пользователей будут потеряны. Так как, еще раз повторюсь, репозитарий для нескольких мандантов одной системы только один, он общий (рис. 2).
Я в своей практике встречался с таким ландшафтом. Это был пилотный проект в одном, отдельно взятом, подразделении крупного транспортного предприятия. В день, когда на проект приходил разработчик, пользователи в системе не работали. :) То есть получалась система с разграничением времени работы: либо пользователи, либо ABAP-программист.
Второй вариант: в ландшафте SAP системы уже 2 системы. Одна играет роль системы разработки и настройки, вторая для продуктивной работы пользователей. Системы объединены транспортной системой (рис. 3).
 |
| Рис. 3. Двухсистемный SAP ландшафт. |
Здесь ситуация лучше: программисты разрабатывают программы в отдельной системе и, по мере готовности, переносят их в продуктивную систему. Программисты отделены от пользователей и не мешают их работе. Но, на самом деле, ситуация далека от идеальной. Такой ландшафт не может обеспечить хороший уровень контроля качества настроек и разработок системы. Тут проблемы возникают с тестированием решений. Где проводить тестирование? На стороне системы разработки? Тогда встает вопрос с безопасностью (основные данные предприятия в системе, где работают консультанты и разработчики) и с обновлением данных. Про тестирование на стороне системы промышленной эксплуатации вообще говорить не приходится. Даже если выделить отдельный мандант в этой системе, репозитарий общий и дампы при переносе никуда не денутся.
Но основная проблема на самом деле в другом: в переносе изменений. Никто не может гарантировать, что транспортный запрос содержит все необходимые компоненты с изменениями и импортируется в систему промышленной эксплуатации без ошибок. В таком ландшафте это никто не проверял.
Поэтому переходим к последнему варианту - трёхсистемный ландшафт. Три системы (DEV, QAS, PRD) работают в связке, объединенные, корректно настроенной, транспортной системой. Такая связка обеспечивает независимость разработки и настройки в первой системе, тестирование разработанного решения и переноса транспортного запроса во второй и безопасный перенос готового, оттестированного решения в систему промышленной эксплуатации (рис. 4).
В данном варианте разработчик создаёт новую версию объектов репозитария (программы, экраны, таблицы словаря, элементы данных и т.п.) в системе разработки (DEV). После этого, деблокировав транспортный запрос, содержащий необходимые объекты, переносит его в систему контроля качества (QAS). В тестовой системе производятся все виды тестирования: функциональное и нагрузочное на больших объёмах данных, решаются возникающие проблемы интеграции с другими разработками и модулями. Все доработки производятся в системе разработки (DEV) и переносятся новыми транспортными запросами в систему QAS. После того, как разработка подтверждается как завершённая, принимается решение о переносе её в продуктивную систему. И тогда производится перенос всей очереди сформированных запросов в рамках данной разработки. Запомните! Всей очереди, а не только последних запросов. Только так можно гарантировать, что во время переноса вы не получите что-то другое в системе промышленной эксплуатации. Все ваши запросы в систему QAS - это проверенная очередь, при переносе которой в новую систему вы ничего не потеряете и не забудете.
За промежуточные некорректные версии объектов, которые содержатся в такой очереди, можно не переживать. При импорте очереди запросов, автоматически активируются только последние версии каждого объекта.
А чтобы было меньше дампов у пользователей при переносе, осуществлять его лучше во время минимальной активности в системе. Вечер пятницы вроде бы идеально подходит, но иногда чреват незапланированной работой в выходные. :) Поэтому лучше вечер четверга.
Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.
Так же и мандантов внутри систем может быть больше. В системе разработки часто, кроме манданта для настройки и разработки (который в идеале не содержит основных данных), создают мандант первичного тестирования. В нём есть небольшой объем данных для первичного теста. Так же часто можно увидеть мандант-песочницу, в котором консультанты могут "побаловаться" с настройками. Главное, чтобы все изменения (мусор, песок) в этом манданте не включались в транспортные запросы и никуда не импортировались.
В тестовой системе часто создают отдельный мандант для обучения сотрудников. Так как для реальных примеров во время обучения нужен объем данных, а в продуктивной системе обучать новых людей нельзя по очевидным причинам.
В продуктивной системе могут быть несколько промышленных мандантов для работы отдельных предприятий в рамках одной системы.
Но самое главное, что я хотел сказать, это то, что для качественной разработки и поддержки нужны минимум 3 отдельные системы.
P.S. Всё что здесь описано, касается только AS ABAP, при разработке в AS JAVA требования к ландшафту несколько другие. Подробности можно найти в курсах SAP ADM325 и SAP ADM800.
Но основная проблема на самом деле в другом: в переносе изменений. Никто не может гарантировать, что транспортный запрос содержит все необходимые компоненты с изменениями и импортируется в систему промышленной эксплуатации без ошибок. В таком ландшафте это никто не проверял.
Поэтому переходим к последнему варианту - трёхсистемный ландшафт. Три системы (DEV, QAS, PRD) работают в связке, объединенные, корректно настроенной, транспортной системой. Такая связка обеспечивает независимость разработки и настройки в первой системе, тестирование разработанного решения и переноса транспортного запроса во второй и безопасный перенос готового, оттестированного решения в систему промышленной эксплуатации (рис. 4).
 |
| Рис. 4. Трёх системный SAP ландшафт. |
В данном варианте разработчик создаёт новую версию объектов репозитария (программы, экраны, таблицы словаря, элементы данных и т.п.) в системе разработки (DEV). После этого, деблокировав транспортный запрос, содержащий необходимые объекты, переносит его в систему контроля качества (QAS). В тестовой системе производятся все виды тестирования: функциональное и нагрузочное на больших объёмах данных, решаются возникающие проблемы интеграции с другими разработками и модулями. Все доработки производятся в системе разработки (DEV) и переносятся новыми транспортными запросами в систему QAS. После того, как разработка подтверждается как завершённая, принимается решение о переносе её в продуктивную систему. И тогда производится перенос всей очереди сформированных запросов в рамках данной разработки. Запомните! Всей очереди, а не только последних запросов. Только так можно гарантировать, что во время переноса вы не получите что-то другое в системе промышленной эксплуатации. Все ваши запросы в систему QAS - это проверенная очередь, при переносе которой в новую систему вы ничего не потеряете и не забудете.
За промежуточные некорректные версии объектов, которые содержатся в такой очереди, можно не переживать. При импорте очереди запросов, автоматически активируются только последние версии каждого объекта.
А чтобы было меньше дампов у пользователей при переносе, осуществлять его лучше во время минимальной активности в системе. Вечер пятницы вроде бы идеально подходит, но иногда чреват незапланированной работой в выходные. :) Поэтому лучше вечер четверга.
Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.
Так же и мандантов внутри систем может быть больше. В системе разработки часто, кроме манданта для настройки и разработки (который в идеале не содержит основных данных), создают мандант первичного тестирования. В нём есть небольшой объем данных для первичного теста. Так же часто можно увидеть мандант-песочницу, в котором консультанты могут "побаловаться" с настройками. Главное, чтобы все изменения (мусор, песок) в этом манданте не включались в транспортные запросы и никуда не импортировались.
В тестовой системе часто создают отдельный мандант для обучения сотрудников. Так как для реальных примеров во время обучения нужен объем данных, а в продуктивной системе обучать новых людей нельзя по очевидным причинам.
В продуктивной системе могут быть несколько промышленных мандантов для работы отдельных предприятий в рамках одной системы.
Но самое главное, что я хотел сказать, это то, что для качественной разработки и поддержки нужны минимум 3 отдельные системы.
P.S. Всё что здесь описано, касается только AS ABAP, при разработке в AS JAVA требования к ландшафту несколько другие. Подробности можно найти в курсах SAP ADM325 и SAP ADM800.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий