понедельник, 27 ноября 2017 г.

Тестовая система в SAP ландшафте

Ссылка на статью
Не так давно в посте "Почему SAP рекомендует 3-х системный ландшафт?" я описывал односистемный, двухсистемный и трёхсистемные ландшафты. В посте я показал, что трёхсистемный ландшафт является минимально достаточным для организации корректной разработки и контроля качества в SAP системе.

Таким образом, типовой SAP ландшафт (рис. 1) состоит из 3-х систем:
  • система разработки и настройки (DEV),
  • тестовая система или система контроля качества (QAS),
  • продуктивная система или система промышленной эксплуатации (PRD).

Рис. 1. Трёхсистемный ландшафт.

Остановимся на тестовой системе.

Тестовая система выполняет следующие основные функции:
  • тестирование новых разработок и настроек,
  • тестирование переноса изменений через транспортный запрос,
  • тестирование ролей и полномочий,
  • тестирование разработок на больших объемах данных, с целью решения проблем производительности,
  • обучение пользователей. 

Назначение тестовой системы подразумевает содержание большого объема мастер-данных. В идеале, всех данных продуктивной системы. Следовательно, при проектировании тестовой системы необходимо проработать план обновления этих данных из продуктивной системы с достаточной периодичностью. Частота обновления зависит от требований проекта, но ориентироваться можно на 1 раз в квартал.

Способы обновления могут быть следующими:
  • обновление через копирование содержимого отдельных таблиц,
  • обновление через копирование манданта,
  • обновление через гетерогенное копирование системы,
  • обновление через гомогенное копирование системы.

Перед обсуждением способов обновления данных остановлюсь еще на одном моменте. В идеальном мире архитектура серверов продуктивной и тестовой систем должна быть идентичной. Если бы это требование выполнялось в реальной жизни, то мой пост был бы в 2 раза короче. Но, к сожалению, в реальной жизни встречаются разные ситуации. При разной архитектуре продуктивной и тестовой систем тоже можно обеспечить приемлемое качество проекта. Протестировать разработки, перенос запросов, обучить пользователей и так далее. То есть процентов 80 запросов система покрывает. Но в данном случае обновление данных в тестовой системе имеет свои ограничения. Об этом сейчас и поговорим.

Итак, при создании тестовой системы смотрим на архитектуру оборудования, которое выделено под эти цели. Если архитектура отличается от продуктивной системы, то при создании тестовой системы придётся использовать процедуру гетерогенного копирования систем. Процедура длительная: требуется останов продуктивной системы и создание экспорта базы данных. Также в такой тестовой системе ограничен набор сценариев тестирования. Если в тестовой системе будет использоваться другая база данных, то тестирование разработок, в которых используется NativeSQL, вызывает большой вопрос. Тест производительности так же будет носить очень отдалённый характер, в силу больших различий со средой промышленной эксплуатации.

Если же архитектура идентична, то вопрос создания тестовой системы решается через гомогенное копирование. В качестве источника данных в данном случае отлично подойдёт существующая резервная копия продуктивной базы данных (offline или online + redo logs).

При периодическом обновлении мастер-данных в тестовой системе всё так же упирается в архитектуры продуктивной и тестовой систем. Если архитектуры разные, то можно использовать только следующие процедуры:
  • копирование содержимого отдельных таблиц: позволяет обновить только один функциональный модуль или его часть. Очень медленный способ. Перенос данных выполняется через транспортный запрос. Как включить содержимое таблицы в транспортный запрос я описывал в этом посте. При повторном переносе можно воспользоваться советом из поста "Саповские секретики - III (секретик 2)" и, создавать новый запрос через копию содержимого старого запроса. Процедура возможна только в крайнем случае и только при контроле и управлении со стороны опытного функционального консультанта. Результат не всегда гарантирован. Но в практике иногда применяется.
  • копирование манданта системы: возможно использование процедуры удаленного копирования манданта или экспорта/импорта манданта. Все способы описаны в этом посте. Процедура очень сильно нагружает обе системы (продуктивную и тестовую), работа в продуктивной системе должна быть минимальна, иначе высока вероятность возникновения проблем с целостностью данных. 
  • гетерогенное копирование системы - фактически полное удаление и установка тестовой системы по новой. Требует останова продуктивной системы на момент создания экспорта данных. Длительные временные затраты на создание копии в целом.

Если архитектура идентична, то проблем, конечно же, меньше. В данном случае можно использовать первые два способа, описанные выше: перенос содержимого списка таблиц и копирование манданта. Но оптимально будет использовать процедуру гомогенного копирования системы. Причем, её укороченный вариант. Только обновление данных базы данных.

Здесь я хочу плавно подвести к тому, что оптимальным вариантом при проектировании тестовой системы является выбор той же архитектуры, что и на системе промышленной эксплуатации. Хочу отметить, что я говорю про идентичность архитектуры и платформы, а не про идентичность в плане производительности. Нагрузка на тестовую систему гораздо ниже, чем на продуктивную. Следовательно, оборудование может быть "слабее". Какие плюсы мы получаем:
  • возможность полного тестирования любых функциональностей и разработок в среде, максимально приближенной к продуктивной,
  • тестовую среду, позволяющую проводить нагрузочное тестирование с выявлением узких мест в производительности разработок,
  • несложную процедуру обновления данных с получением почти 100 % идентичной продуктивной среды,
  • периодическое тестирование процедуры восстановления из резервной копии продуктивной системы с высчитыванием интервалов необходимых на процедуру восстановления для прогнозирования временных затрат в случае сбоя среды промышленной эксплуатации.

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

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


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

 

среда, 15 ноября 2017 г.

Опрос: Web-браузер

Ссылка на статью
Предыдущий опрос завершился полной победой Unix (Linux). Результаты на основе мнения 44 администраторов можно посмотреть тут.



Давайте теперь посмотрим на Web-браузеры.

Прошли те времена, когда почти единственным корректно работающим (то есть де-факто стандартом для тестирования у разработчиков сайтов) браузером был MS IE. Сейчас можно услышать опасения, что таким может стать Google Chrome. Да, и продукты компании SAP поддерживают большинство основных Web-браузеров примерно на одном уровне.

Давайте проведем опрос: какой Web-браузер вы используете на компьютере в качестве основного. В каком браузере у вас открыто большинство вкладок. Отметьте только тот, который у вас работает в большинстве случаев. В комментариях можно больше подробностей.


Спасибо за участие. Результаты, как обычно, в середине следующего месяца.

Я лично использую в качестве основного Google Chrome, а MS Internet Explorer у меня на подхвате. Для проверки упрямых страничек и сайтов. Всё хочу вернуться обратно на Firefox, но последняя попытка была неудачной. Сейчас Mozilla, как раз, сделала крупное обновление. Хочу попробовать дать ему еще один шанс. :)

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


понедельник, 30 октября 2017 г.

Мастер класс по архитектуре SAP HANA

Ссылка на статью
В прошлую пятницу, 27 октября, я посетил мастер-класс "Архитектура решений на SAP HANA. Рекомендации". Мастер-класс проводился в рамках осенней сессии мастер-классов SAPLAND. Попал я на него бесплатно, как автор статей на портале. За что порталу отдельная благодарность.

Сразу скажу, что я ни разу не пожалел о своём посещении. На этот мастер-класс я пытался попасть ещё весной 2017 года, но, к сожалению, его тогда отменили - в последний момент оказалось только 2 участника. В этот раз было 11 человек. Отдельно хочу отметить ребят из "М-Видео", которые активно делились опытом использования BW on SAP HANA.

Организация семинара была осуществлена на базе учебного центра "Специалист при МГУ им. Н. Э. Баумана". В целом за организацию можно поставить твёрдую четвертку. Учебные классы хорошие, хотя участие в мастер-классе было пассивное, никаких практических заданий не было. Чай-кофе, вода, раздаточные материалы. Девушки из SAPLand, я считаю, отработали на 5. Понятное дело, что сравнение с учебным центром SAP в Москве некорректно, туда вложено больше денег и уровень там другой. Ну и для однодневного семинара это всё не так принципиально.

Автору мастер-класса Михаилу Вронскому отдельное спасибо. Материал был объёмный и при этом всё крайне полезно. Работали практически без перерывов, чтобы всё успеть. Было много практических рекомендаций и обсуждения опыта автора и участников. Я бы даже сравнил количество материала с 2-3 днями хорошего семинара. Только практики не было.

Небольшие заметки по мастер-классу (это лишь 10 % того, что там было :) ).

SAP HANA - база данных с поколоночным хранением данных и обработкой в оперативной памяти. Была впервые представлена в 2011 году. После этого на работу с данной базой данных была переведена система SAP BW. Решение носило название SAP BW on (powered by) SAP HANA или BWoH. Затем решение было полностью интегрировано в платформу SAP HANA и решение стало носить название SAP BW4/HANA (рис. 1).

Рис. 1. Эволюция решений SAP BW, использующих платформу SAP HANA.

Затем пришло время другим решениям от SAP переходить на новую платформу. Сначала появились продукты SAP Business Suite on (powered by) SAP HANA, а сейчас - SAP S4/HANA (рис. 2).

Рис. 2. Эволюция решений SAP Business Suite, использующих SAP HANA.

Таким образом, решения SAP BW4/HANA и SAP S4/HANA являются продуктами, в которых интеграция с платформой SAP HANA достигла такого уровня, что эти продукты могут работать только на ней. Эти решения используют новую модель данных, оптимизированную под SAP HANA.

Стоит отметить, что с 2013 года в продуктах SAP уже появляются специальные вставки в код для работы с базой данных SAP HANA, которые используют не чистый OpenSQL.

SAP заявляет, что с 2025 года он не будет поддерживать свои решения на других СУБД, кроме SAP HANA. Учитывая тот факт, что на данный момент в мире больше половины решений SAP используют в качестве базы дынных - Oracle, заявление вызывает некоторый скептицизм.

При поколоночном решении обеспечивается хорошее сжатие данных и быстрый поиск. Нет нужды в индексах (для таблиц с поколоночным хранением), убраны некоторые таблицы (например, pool и кластерные).

Соответственно, систему SAP BW проще перевести на BW4/HANA, ERP сложнее. Хороший вариант: перевнедрение - установить систему рядом и переносить данные перед стартом в промышленную эксплуатацию.

Для OLAP систем - автор рекомендует переходить на SAP HANA, для OLTP систем можно не спешить, надо взвешивать все за и против. Особенно для высоко-нагруженных систем.

Есть решение ORACLE in-memory, когда в памяти выделяется область для копирования таблиц в поколоночное хранение. Это увеличивает скорость работы. Но в SAP HANA идет изменение модели хранения и изменение кода.

На данный момент поддерживаются следующие версии SAP HANA:
  • SAP HANA 1.0 SPS12 (поддержка до 2021 года),
  • SAP HANA 2.0 SPS01,
  • SAP HANA 2.0 SPS02.

Версию SAP HANA 2.0 пока поддерживают не все системы.
Новый график выхода версий (SPS) - раз в год (апрель).

Оборудование (для продуктивных систем): только х86_64 (для HANA 2.0 от Intel Haswell и выше) и ограниченная поддержка IBM Power (для HANA 2.0 IBM Power 8). Всё оборудование должно быть сертифицировано SAP (до конкретной модели сервера). Системы хранения данных тоже только сертифицированные.

Операционные системы: только Linux - SLES или RHEL и только определенных версий.
В качестве ОС, автор рекомендует SLES, так как разработка SAP NetWeaver и SAP HANA в SAPLabs ведется именно на ней.

Подробности в PAM.

Возможно 2 варианта проектирования:
  • покупка готового решения (Appliance): готовый сервер+СХД+все оборудование, предустановленная SAP HANA, запуск, обучение.
  • конфигурация всего по отдельности (Tailored Data Center или TDI): покупка оборудования, системы, монтаж, установка, запуск. 

Первое решение дорогое, второе дешевле и более гибкое.


Выделяют 2 архитектуры разворачивания:
  • Scale-up - одна HANA нода. Рекомендуется для SAP ERP on HANA. Более производительное решение, но для апгрейда требует замену полностью всего оборудования на новый Applience. 
  • Scale-out - несколько HANA нод, объединенных в одну базу. Рекомендуется для BW on HANA и BW4/HANA. Позволяет наращивать объем памяти через добавление новых нод. Так же добавляет некоторую отказоустойчивость.

Виртуализация не рекомендуется для SAP HANA, а отказоустойчивый кластер, наоборот, настойчиво рекомендуется.

В SAP HANA есть свой WebAS. Весь инструмент работы с SAP HANA переводится в Web.
Текущий инструмент, SAP HANA Studio не имеет будущего.

Примеры установки и использование SAP HANA можно посмотреть на рис. 3.

Рис. 3. Примеры разворачивания и использования платформы SAP HANA.

Есть проблема с лицензированием BW4/HANA - полностью изменена модель: с пользователей на лицензирование по объему памяти.

Для того, чтобы предварительно посмотреть SAP HANA можно использовать:
  • SAP HANA Express edition (в виде самостоятельной установки или готового образа ВМ),
  • SAP Solution Manager 7.2 on SAP HANA 1.0.

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


понедельник, 23 октября 2017 г.

Пример проблемы при переполнении файловой системы

Ссылка на статью
Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (troubleshooting). Утром одна из систем была обнаружена в недоступном для пользователей состоянии. Анализ показал, что инстанция SAP запущена, а база данных Oracle нет. После старта базы данных система стала доступна для работы, а последующий анализ показал, что не завершился ночной оффлайн бэкап базы данных. Про резервное копирование я писал в посте "Резервное копирование SAP системы". 

Так как при оффлайн резервировании база данных Oracle на время копирования данных останавливается, то утром она была обнаружена как раз в остановленном состоянии.

Анализ журналов копирования показал ошибку при старте базы данных после резервирования: при записи журналов не хватило места на какой-то файловой системе сервера (рис. 1).

Рис. 1. Ошибка в журнале оффлайн резервирования базы данных Oracle.

Тут стоит вспомнить один из моих недавних постов "Анализ места на диске в Unix". Вооружившись советами из статьи и командами bdf и du, можно легко обнаружить, что в домашней директории Oracle закончилось свободное пространство. Много места занимает директория с журналами (log), а именно журнал процесса Listener (рис. 2 и 3).

Рис. 2. Вывод команды bdf.

Рис. 3. Анализ размера директорий в файловой системе.

Тут опять же, стоит вспомнить пост "Старые журналы событий SAP и ORACLE", в котором я упоминал про этот журнал. Данный журнал хранит информацию о соединениях процессов SAP с Oracle. Смело очищаем и высвобождаем место (рис. 4).

Рис. 4. Удаление содержимого журнала listener.log.

После этого проблема решена. 

Стоит отметить, что при настроенном мониторинге (например, через CCMS мониторинг) такой проблемы бы не возникло. 

Первая задача администратора: сделать так, чтобы всё заработало. 

Вторая задача: разобраться в ситуации, выяснить причины ошибки и выполнить шаги, чтобы не допустить повторение ошибки в будущем. 




среда, 18 октября 2017 г.

Опрос: Windows vs Unix

Ссылка на статью
Предыдущий опрос про опыт администрирования SAP систем завершён. Результаты и обсуждение тут.


Предлагаю новый опрос. Представьте, что необходимо установить продуктивную SAP систему. Согласно PAM возможна установка на операционные системы семейства MS Windows и Unix-подобные (Linux, AIX, HP-UX и т.п.). Никаких особых ограничений ни в одной, ни в другой операционных системах со стороны SAP нет.
Что вы выберете для продуктивной системы? Ваше личное мнение. Анонимно. :)

Опрос завершён. В опросе приняло участие 44 человека. Всем спасибо за участие.

Итоги получились ожидаемыми: с большим отрывом победили Unix системы (рис. 1).

Рис. 1. Результаты опроса.

Моё личное мнение совпадает с мнением большинства. Я бы тоже выбрал Unix-подобную операционную систему. По объективным и субъективным причинам. Люблю я их. :)

Хотя чаще надо выбирать головой. Например, учитывать при выборе факт наличия навыков и опыта работа с операционной системой у администраторов и политики компании.

В пользу Linux стоить отметить тот факт, что база данных SAP HANA, которую компания разрабатывает уже 5 лет, работает только на Linux. На Windows они её так и не портировали.

Распределение участников опроса по странам, если кому интересно, можно найти на рис. 2.

Рис. 2. Участники опроса по странам.



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


понедельник, 16 октября 2017 г.

Создание ярлыка для соединения с SAP системой без пароля

Ссылка на статью
В последнем посте "Саповские секретики - V", в качестве одного из секретов, я рассказывал, как создать ярлык для соединения к SAP системе. При создании ярлыка можно было указать, помимо целевой системы, манданта и языка, транзакцию, которую необходимо запускать сразу после входа в систему. Так же можно было указать имя пользователя, из под которого будет создаваться соединение (рис. 1). Пароль же вводится при открытии соединения через ярлык. И это безопасно и правильно. В данном случае пароль хранится у вас в голове и в SAP системе.

Рис. 1. Создание ярлыка для соединения.

Но, если очень хочется, то можно указать пароль в SAP систему прямо во вновь созданном ярлыке. Для этого необходимо внести изменения в реестр Windows, открыв его командой regedit и добавив по пути HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security параметр "EnablePassword"="1" (рис. 2).

Рис. 2. Внесение изменений в реестр Windows.

Либо можно создать файл-корректировку для реестра (расширение .reg) с содержимым вида:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security]
"EnablePassword"="1"
Выполнить созданный файл, внеся изменения в реестр. И перезапустить программу SAP Logon.

После этого при создании ярлыка для соединения, поле пароля будет открыто на изменение и можно будет внести пароль пользователя, из под которого будет выполняться соединение в будущем (рис. 3).

Рис. 3. Сохранение пароля в ярлыке для соединения.

Вносим пароль пользователя и сохраняем ярлык. После этого вход в систему будет осуществляться без ввода пары пользователь/пароль.

Хотя пароль хранится в ярлыке не в явном виде, всё равно SAP не рекомендуется сохранять его там (рис. 4).

Рис. 4. Пример содержимого ярлыка для соединения с SAP системой.

Функция описана в SAP note # 146173 - SAPShortcut: Saving password in SAPShortcut - not recommended.

В SAP note указано, что, начиная с SAP GUI 7.40 (SP 01) функция была удалена. И экран создания ярлыка в версии SAP GUI 7.50 выглядит без поля пароля вообще (рис. 5).

Рис. 5. Диалоговое окно для создания ярлыка в SAP GUI 7.50.

Но, ярлык, созданный в SAP GUI 7.30 с сохранённым паролем, работает и в SAP GUI 7.50. :)

Но опять же повторюсь, SAP не рекомендует использовать эту функцию.


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


понедельник, 9 октября 2017 г.

Саповские секретики - V

Ссылка на статью
Секретик 1.

При работе в клиентском месте SAP GUI можно открывать несколько режимов  (окон). Про это я писал в одном из выпусков саповских секретиков. Очень часто приходится открывать несколько режимов и при этом работать в нескольких системах SAP. Иногда, может потребоваться открывать сессии под разными пользователями. Чтобы не запутаться в большом количестве окон и, при переходе к окну сразу понимать что это за система/мандант/пользователь, необходимо развернуть информационную часть строки состояния, нажав соответствующий треугольничек в правом нижнем углу окна SAP GUI (рис. 1).

Рис. 1. Активация информационной части строки состояния SAP GUI.

Правый нижний угол строки состояния SAP GUI содержит много полезной информации. Прежде всего это SID системы, номер режима и номер манданта. Так же там отображается имя хоста (hostname), на котором работает сервер приложений SAP, обслуживающий текущую сессию (рис. 2).

Рис. 2. Полезная информация в строке состояния SAP GUI.

Но это еще не всё. Информации о текущем режиме больше и получить её можно, если вызвать всплывающий список, нажав на соответствующую кнопку после номера манданта (рис. 3).

Рис. 3. Полная информация о текущем режиме SAP GUI.

Как видно из снимка экрана, присутствует информация по текущему пользователю, запущенным программе и транзакции, а также временные задержки системы. Любую из этих строк можно сделать видимой в строке состояния постоянно, вместо SID системы и номера манданта, которые отображаются по умолчанию. Достаточно выбрать их в выпавшем списке. Например, имя пользователя, из под которого вы работаете в системе (рис. 4).

Рис. 4. Полезная информация в строке состояния SAP GUI: имя текущего пользователя.


Секретик 2.

Еще один полезный совет при работе с SAP GUI. Запуск соединения с SAP системой происходит через утилиту SAP Logon, которая содержит записи о соединениях с SAP системами. Но можно ускорить вход в ваши любимые системы и любимые транзакции. Для этого необходимо войти в необходимой мандант системы, запустить нужную транзакцию (не обязательно, можно указать позже) и нажать на панели кнопку "Создать ярлык" (рис. 5).

Рис. 5. Создание ярлыка для соединения.

В появившемся диалоговом окне заполнить поля и нажать "Готово" (рис. 6).

Рис. 6. Создания ярлыка для запуска соединения.

Здесь можно указать конкретную транзакцию, которую вы хотите сразу видеть на экране, мандант системы, пользователя из под которого вы будете работать, язык входа. В зависимости от того, что вы укажете в поле "Город" (явная ошибка перевода :)), ярлык будет создан или в окне SAP Logon в разделе "Ярлыки" (рис. 7) или, например, на рабочем столе Windows (рис. 8).

Рис. 7. Вновь созданный ярлык в SAP Logon.

Рис. 8. Вход в систему через ярлык.

При запуске ярлыка вводите пароль для пользователя (которого можно изменить) и сразу попадаете в транзакцию, указанную при создании ярлыка.


Секретик 3.

В серии постов про работу с SAP notes (часть 1, часть 2, часть 3) я рассказал про то, что SAP notes, которые содержат коррекции программного кода, часто включают в те или иные пакеты поддержки. То есть, найдя SAP note можно узнать какой пакет поддержки её содержит. Но можно решить и обратную задачу: найти все SAP notes, которые содержатся в том или ином пакете поддержки. Для этого входите на SAP Support Portal в раздел "Software Downloads", находите нужный пакет поддержки и справа от него выбираете пункт "SAP Notes & Side Effects" (рис. 9).

Рис. 9. Дополнительная информация по пакету поддержки.

В открывшемся окне будет список всех SAP notes (разбитых по компонентам), которые включены в данный пакет поддержки (рис. 10).

Рис. 10. Список SAP notes, включенных в пакет поддержки.

Ну и можно найти, например, все SAP notes с изменениями, касательными расчета заработной платы в России (рис. 11).

Рис. 11. Список SAP notes, включенных в пакет поддержки. 

Либо, если вы знаете имя пакета поддержки, можно воспользоваться быстрой ссылкой вида:
https://launchpad.support.sap.com/#/supportpackage/<SP_name>
здесь <SP_name> - имя пакета поддержки.


Предыдущие выпуски:
Саповские секретики - I,
Саповские секретики - II,
Саповские секретики - III,
Саповские секретики - IV.


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