Книга "Upgrading SAP. The Comprehensive Guide"

Сегодня, первым постом в этом году, я хотел бы рассказать вам об отличной книге.
Книгу я получил в качестве приза, выиграв в конце 2015 года конкурс "Лучший автор SAPLand за 2015 год". То есть, оказалась она у меня в 2016 году. Но руки до неё дошли только в конце прошлого года. :)

Книга, издательства SAP PRESS. Называется "Upgrading SAP. The Comprehensive Guide".

Издана в 2015 году, приобрести в бумажном или электронном виде можно до сих пор. Написали её два "зубра" SAP Basis мира: Mark Mergaerts и Bert Vanstechelman (рис. 1).

Рис. 1. Авторы книги по апгрейду SAP системы.

По именам думал, что ребята немцы, а оказалось из Бельгии. У обоих большой опыт работы с SAP системами (по 20 лет и больше) и, судя по всему, специализируются они на апгрейдах и обновлениях.

Сразу скажу, что книга просто бомба! 550 страниц идеально сбалансированы в плане описательных и архитектурных нюансов и конкретных действий и шагов по апгрейду SAP систем. Конспектировать было очень сложно. В итоге, я просто взял маркер и отмечал все интересные, важные, мегаполезные вещи прямо в книге. В этом бумажный вариант выигрывает. Кто выберет электронный вариант, сможет насладиться своими плюсами: книга всегда с собой, целиком цветное издание! и возможность отмечать куски в pdf документе тоже никто не отменял. Если сравнивать материалы SAP курсов, прочитанные самостоятельно, без преподавателя и практических занятий, и книгу, то книга даёт раза в 3 больше материала и понимания вопроса.

Тут стоить отметить, что это не первая их книга на эту тему. В 2005 году была "The SAP OS/DB Migration Project Guide", потом в 2006 - "mySAP ERP Upgrade Project Guide", в 2007 - "SAP NetWeaver Application Server Upgrade Guide". Книги уже устарели и не издаются, но кое что можно найти на Amazon.com. То есть ребята книгу на эту тему пишут давно, постоянно её дополняя и актуализируя.

Вернемся к текущей книге. В первой главе "Планирование проекта" рассказывается о таких важных вещах, как:

• зачем нужен апгрейд;
• факторы влияющие на сложность апгрейда, длительность, затраты;
• проектная команда и основные роли;
• крупные мазки по основным шагам проекта;
• документация и планирование;
• тестирование системы до, во время и после апгрейда.

Во второй главе "Техническая информация и планирование" авторы останавливаются на следующих моментах:

• архитектура SAP NetWeaver;
• SAP ERP и SAP релизы (что-то похожее на мой пост про версии SAP ERP);
• технология System Switch;
• специфичные моменты, относящиеся к базам данных;
• хорошо освещены варианты системного ландшафта, плюсы и минусы разных вариантов;
• вопросы обновления dual-stack систем и MCOD инсталляций.

Третья глава "Подготовка к техническому апгрейду" охватывает все задачи, которые необходимо выполнить в фазе подготовки к апгрейду:

• документация;
• дополнительные сервисы, помогающие спланировать и выполнить проект;
• аппаратные и программные требования (PAM, sizing);
• Upgrade и Download directories;
• установочные диски, SP stacks и EHP.

Следующая глава "Инструкция по утилите обновления SUM" представляет собой 35-страничный документ подробнейшим образом освещающий все аспекты и секреты работы SAP Software Update Manager, о котором у меня был пост. Мой пост это 5% информации, которая есть в этой главе. У авторов эта глава даже есть отдельной брошюрой! 

Пятая глава самая большая - 120 страниц. Называется "Апгрейд ABAP системы". Шестая глава "Апгрейд Java системы". Стоит отметить, что авторы в качестве примера на страницах книги производят апгрейд версии SAP ERP 6.0 EHP 4 (SAP NetWeaver 7.0 EHP 1) до версии SAP ERP 6.0 EHP 7 (SAP NetWeaver 7.40). Эти две главы являются ключевыми практическими главами, которые описывают все шаги, от "А до Я", которые необходимо выполнить во время апгрейда ABAP и Java систем. 

Седьмая глава "Modification Adjustment" будто бы десерт для SAP Basis консультанта. Как долго эти вещи были для меня (и как пишут авторы, для многих администраторов) "тёмной территорией". А здесь, просто всё разложено "по полочкам". Может быть по этой главе я напишу отдельный пост. Главное собраться. :)

Следующие 7 глав кратко описывают нюансы возникающие при апгрейде таких SAP систем как:

• SAP Business Warehouse;
• SAP SCM;
• SAP CRM;
• SAP SRM;
• SAP Enterprise Portal;
• SAP PI и SAP PO;
• SAP Solition Manager.

То есть охвачены все системы входящие в SAP Business Suite. И этого авторам было мало. :) В приложении разместили таблицу с версиями систем от SAP R/3 3.1H до построенных на базе SAP NetWeaver 7.40. Данная таблица содержит информацию по возможным путям обновлений между версиями в рамках данного диапазона. И там не только SAP ERP, но и все остальные продукты SAP, построенные на базе SAP NetWeaver.

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

Про языки. Полное покрытие всех языков возможно только с помощью Unicode. Конвертация системы в Unicode возможна для всех систем, основанных на SAP WAS 6.20 и новее. Транзакция UCCHECK позволяет просканировать ABAP код на наличие неподходящего для перехода на Unicode кода.

Про тестирование. Первый шаг после апргейда системы разработки - это массовая синтаксическая проверка всех разработок в области имен клиента через транзакцию SAMT.

Про SAP PI. Самой свежей из всех систем ландшафта должна быть SAP Process Orchestration (SAP PO, он же SAP PI или SAP XI). Подробности и исключения в SAP note 1043047.

Про SAP GUI. Необходимо подумать и об обновлении версий SAP GUI пользователей. Сделать это надо до обновления версии SAP системы. После обновления SAP GUI возможна работа со старой системой, так как SAP GUI поддерживает обратную совместимость. User exit EXIT_SAPLSUSF_001 - записывает версию SAP GUI вошедших в систему пользователей. Функциональные модули - GUI_GET_DESKTOP_INFO и GUI_GET_FILE_INFO - показывают версию SAP GUI. Во время тестирования системы после технического апгрейда используемая версия SAP GUI должна быть идентичной той, что будут использовать в будущем конечные пользователи.

Про новую функциональность. Рекомендуется активировать новую функциональность только после полного окончания технического апгрейда и убедившись, что система находится полностью в стабильном состоянии.

Про подготовку. Пробный апгрейд это идеальный путь для оценки трудозатрат и временных рамок для проекта апгрейда. Закладывать для первого апгрейда как минимум 2 недели. Для пробной системы обычно берется копия продуктивной системы. Но для этого надо много дискового пространства. При этом, система разработки худший кандидат для этого, так как её репозитарий перегружен разработками, изменениями, которые не используются, но
всплывут во время апгрейда.

Про технический апгрейд и downtime. Начиная с WAS 6.10 появился механизм - system switch upgrade. Когда параллельно создается shadow instance, в которую импортируется новый репозитарий, и которая работает параллельно с основной. Это снижает длительность downtime во время процесса апгрейда. Во время downtime происходит переключение на новый репозитарий, а старый удаляется. Причем, shadow instance может быть установлена на отдельный сервер, если оборудование целевого сервера не позволяет разворачивание 2-х инстанций. Shadow instance управляется автоматически утилитой обновления (SUM).

Три стратегии при апгрейде:

• single system - без shadow instance, долгий downtime, но используется минимальное количество ресурсов;
• standard downtime - создается shadow instance;
• advanced - самое большое использование ресурсов и самый короткий downtime.

Технология near Zero Downtime Management (nZDM) - максимально уменьшает downtime, до 4-х часов. Подробности в SAP notes: 1678564 и 1678565.

Рекомендуется всегда использовать downtime-minimized strategy, потому что на продуктивной системе надо проводить 100% процедуру, которую проводили до этого. При этом downtime обычно укладывается в 5-8 часов. То есть, хорошо подготовленный апгрейд продуктивной системы реально провести за 2 выходных дня.

Про SUM. У SUM есть 2 роли: Administrator и Observer (доступ только на чтение). Одновременно может работать с утилитой только один администратор. Если еще один переходит в роль Администратора, то старый автоматически переходит в роль Observer.

Утилита состоит из 2-х частей:

• серверная - запускается скриптом, в Unix рекомендуется запуск в режиме nohup, чтобы не зависеть от открытого shell пользователя. В Windows рекомендуется в конце скрипта добавить команду pause, чтобы в случае сбоя терминальное окно висело и не закрывалось.
• GUI часть запускается через web-браузер. По-умолчанию, используются порты 4239, 4240, 4241. Порты можно изменить (описание на стр. 203). Если был утерян пароль роли Administrator, то поможет SAP note 1874441 (описание на стр. 203).

Про SP stacks. При апгрейде первой системы в ландшафте необходимо всегда выбирать максимальный SPS для целевой системы. Для продуктивной системы используется уровень SPS, который использовался для предыдущих систем.

Всю книгу не перепишешь. Поэтому категорически рекомендую саму книгу. Если вам хоть раз приходилось проводить апгрейд, то эта книга должна быть в вашей SAP Basis библиотеке.

Сейчас SAP для всех видов обновлений - апгрейд основного релиза системы, установка SAP EHP или пакетов поддержки (отдельно или в рамках стека), использует термин апдейт (update) и одну утилиту SUM. Следовательно, книга будет полезна при любом обновлении системы с помощью утилиты SUM.

Чего пока в этой книге нет, так это перехода на SAP S4/HANA и нюансов работы базы данных SAP HANA. Хотя несколько слов о SAP HANA ребята всё таки сказали. Если выйдет от них обновленная книга, обязательно постараюсь достать.


Автор: Шиболов Вячеслав Анатольевич