Опрос: что будет с блогом в 2018 году?

Друзья, в связи с наступлением нового года, проведем небольшой опрос.

Просьба высказать своё честное мнение.

Опрос закончен. Спасибо всем, кто участвовал.

В опросе приняло участие 58 человек. Большинство требует "продолжения банкета" без изменения формата (рис. 1).

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

При этом приличная часть читателей согласна на добавление личных постов. Приму к сведению. Обещаю много личных постов не писать.

Один человек предложил переходить на написание статей на других ресурсах. И у меня есть предположение кто это мог быть. :)

Географию читателей можно посмотреть на диаграммах (рис. 2 и 3).

Рис. 2. География читателей по странам.

Рис. 3. География читателей из России по городам.

Выводы из итогов опроса я делаю такие, что надо продолжать вести блог. Другого варианта вы мне не дали. 10 лет скоро будет, как я его веду. Ну что ж, the show must go on!

Кстати, если кто-то вдруг захочет поддержать блог, а внести лепту в виде постов (как я приглашал) не получается, то можно это сделать через мой Яндекс-кошелёк - 410015988352987. А то вдруг, мой блог вам очень помог, а вы не можете меня поблагодарить.

Ну и напоминаю, что мне всегда можно написать на shibolov@gmail.com. Комментарии, критика, предложения, всё туда. Читаю обычно всё.

P.S. Еще одно нововведение - писать комментарии к постам теперь можно без регистрации.


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

С наступающим 2018 годом!

Всех, кто читает мой блог постоянно или заглядывает сюда лишь изредка, хочу поздравить с наступающим Новым Годом!

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

Уходящий год был для меня не самым плохим. Надеюсь, что каждый из вас найдёт из всех событий, что были в вашей жизни в этот год, что-то доброе, хорошее и благоприятное.

В этом году я прочитал 23 книги и посмотрел порядка 56 фильмов и сезонов сериалов. Как всегда, количество фильмов больше, чем количество книг.

Из книг, что прошли через меня в этом году, могу посоветовать Джордж Леонард "Мастерство. Путешествие длиною в жизнь" (книга про мастерство), Владимир Успенский "Апология математики" (отличная книга для популяризации математики, очень занимательно и легко читается). Открытием года для меня стал Даниил Гранин, жаль, что для этого ему пришлось уйти из жизни. Особенно советую "Искатели", "Однофамилец", "Эссе о страхе", "Зубр", "Бегство в Россию". Очень искренняя, качественная современная литература. Еще не всё прочитал, что задумал.

Из фильмов советовать тяжело. Из сериалов "Остановись и гори" (4 сезона; плюс, что сериал завершен), "Кремниевая долина" (очень качественный ситком), "Лучше звоните Солу" (особенно для тех, кто неравнодушен к "Во все тяжкие"), "Мистер Робот" (не всем понравится, но зато про компьютеры). Из фильмов - "Гран Торино", "Малышка на миллион", "Монах и бес", "Нелюбовь", "Кловерфилд, 10".

Желаю всем не бояться трудностей и нового (помните: что не происходит, всё к лучшему), интересных проектов, здоровья и хорошего настроения!


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

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

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

Таким образом, типовой SAP ландшафт (рис. 1) состоит из 3-х систем:

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

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

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

Тестовая система выполняет следующие основные функции:

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

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

Способы обновления могут быть следующими:

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

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

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

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

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

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

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

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

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

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

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


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

 

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

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

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

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

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

Опрос закрыт. Всего проголосовало 43 человека. Результаты голосования печальны для браузера Internet Explorer. Действительно, его времена прошли. Ни одного голоса. :) Первенство разделили Google Chrome и Mozilla Firefox (рис. 1).

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

Отвечающие по странам распределены как обычно (рис. 2).

Рис. 2. Географическое распределение респондентов.

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

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

Мастер-класс по архитектуре 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.

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

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

Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (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 мониторинг) такой проблемы бы не возникло. 

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

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

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

Опрос: 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. Участники опроса по странам.

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

Создание ярлыка для соединения с 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 не рекомендует использовать эту функцию.


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

Саповские секретики - 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.


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

Почему SAP рекомендует 3-х системный ландшафт?

Вот вы говорите: "Ландшафт, ландшафт... " А что такое ландшафт?

Давайте остановимся на этом понятии поподробнее.

Итак, в посте "Копирование манданта 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).

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

В данном варианте разработчик создаёт новую версию объектов репозитария (программы, экраны, таблицы словаря, элементы данных и т.п.) в системе разработки (DEV). После этого, деблокировав транспортный запрос, содержащий необходимые объекты, переносит его в систему контроля качества (QAS). В тестовой системе производятся все виды тестирования: функциональное и нагрузочное на больших объёмах данных, решаются возникающие проблемы интеграции с другими разработками и модулями. Все доработки производятся в системе разработки (DEV) и переносятся новыми транспортными запросами в систему QAS. После того, как разработка подтверждается как завершённая, принимается решение о переносе её в продуктивную систему. И тогда производится перенос всей очереди сформированных запросов в рамках данной разработки. Запомните! Всей очереди, а не только последних запросов. Только так можно гарантировать, что во время переноса вы не получите что-то другое в системе промышленной эксплуатации. Все ваши запросы в систему QAS - это проверенная очередь, при переносе которой в новую систему вы ничего не потеряете и не забудете.

За промежуточные некорректные версии объектов, которые содержатся в такой очереди, можно не переживать. При импорте очереди запросов, автоматически активируются только последние версии каждого объекта.

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

Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.

Так же и мандантов внутри систем может быть больше. В системе разработки часто, кроме манданта для настройки и разработки (который в идеале не содержит основных данных), создают мандант первичного тестирования. В нём есть небольшой объем данных для первичного теста. Так же часто можно увидеть мандант-песочницу, в котором консультанты могут "побаловаться" с настройками. Главное, чтобы все изменения (мусор, песок) в этом манданте не включались в транспортные запросы и никуда не импортировались.
В тестовой системе часто создают отдельный мандант для обучения сотрудников. Так как для реальных примеров во время обучения нужен объем данных, а в продуктивной системе обучать новых людей нельзя по очевидным причинам.
В продуктивной системе могут быть несколько промышленных мандантов для работы отдельных предприятий в рамках одной системы.

Но самое главное, что я хотел сказать, это то, что для качественной разработки и поддержки нужны минимум 3 отдельные системы.

P.S. Всё что здесь описано, касается только AS ABAP, при разработке в AS JAVA требования к ландшафту несколько другие. Подробности можно найти в курсах SAP ADM325 и SAP ADM800.

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

SAP на Linux: на какой дистрибутив можно поставить систему?

SAP системы дружат с Linux давно. Если клиентское место SAP GUI for Java, которое можно установить на любую операционную системы (Winodws, Linux или MacOS), но прежде всего на Linux, не является самым популярным решением (в отличии от версии SAP GUI для Windows). То Linux, как платформа для серверной части SAP системы, является бесспорно отличным вариантом. Причем, переход на Linux намечается и со стороны HP, в рамках перехода на x86_64 платформу и уход от HP-UX, и со стороны поклонников Solaris, как результат планомерной политики Oracle, купившей Sun. Один жирный плюс Linux это его универсальность и не зависимость от конкретного вендора железа. А где независимость и универсальность, там конкуренция и экономия.

Если мы обратимся к таблицам совместимости продуктов SAP, операционных систем и баз данных, а именно к Product Availability Matrix (PAM), то увидим, что почти все продукты SAP поддерживают установку на Linux. Причем, Linux может работать на большом количестве аппаратных платформ (x86_32, x86_64, zSeries, Power) в паре почти с любой базой данных. Исключение составляет разве что MS SQL Server, который работает только на Windows Server.

Напоминаю, что про PAM я писал в одноимённом посте.

Старые продукты, такие как SAP R/3 4.6C работали на Linux, последние версии SAP ERP 6.0 EHP8 или, например, SAP Solution Manager 7.2 на базе SAP HANA работают на Linux (рис. 1, 2 и 3).

Рис. 1. Страница PAM: SAP ERP 6.08 на Linux и MaxDB.

Рис. 2. Страница PAM: SAP ERP 6.08 на Linux и Oracle.

Рис. 3. Страница PAM: SAP Solution Manager 7.2 на Linux и SAP HANA.

Как я уже упоминал, на данный момент SAP поддерживает 3 версии дистрибутива Linux:

• Red Hat Enterprise Linux (RHEL),
• SUSE Linux Enterprise Server (SLES),
• ORACLE Linux (OL).

Последний, как это видно из примеров страниц PAM (рис. 1 и 2), поддерживается только при использовании базы данных Oracle. Зато первые два универсальны и работают даже с новой базой данных от SAP, использующей вычисления in-memory, - SAP HANA. Версии операционных систем, которые поддерживаются SAP HANA описаны в SAP note # 2235581 - SAP HANA: Supported Operating Systems.

Все три дистрибутива коммерческие. Получать обновления и поддержку производителя можно только при оплате контракта. Исключения ORACLE Linux и его бесплатное распространение, включая обновления. Но поддержка так же платная.
И это логично. Система SAP серьёзное программное обеспечение и требует серьезного подхода. Только при таком подходе можно гарантировать бесперебойную и корректную работу всей системы.

Версии коммерческих дистрибутивов, поддерживаемых SAP, можно найти в SAP note # 2369910 - SAP Software on Linux: General information.

Для работы продуктивных систем предприятия, даже я бы сказал, продуктивных ландшафтов, подходят только коммерческие дистрибутивы, поддерживаемые компанией SAP.
У компании есть SAP LinuxLab, в которой тестируются Linux-ядра, указанных выше дистрибутивов. И SAP рекомендует использовать только их, без добавления модулей или перекомпиляции. Подробности в SAP note # 784391 - SAP support terms and 3rd-party Linux kernel drivers.

Но иногда хочется срезать углы, попробовать что-то необычное, новое, поэкспериментировать.

Если задуматься, то что такое дистрибутив Linux? Это набор ПО (ядро Linux, библиотеки, базовые утилиты, дополнительное ПО), распространяемый в своём формате пакетов, с набором тех или иных уникальных инструментов для установки и настройки. Таким образом, взяв за основу любой дистрибутив Linux, немного доработав его, мы получим базовую ОС для установки SAP системы?

К тому же, вы наверное знаете, что у Red Hat Enterprise Linux есть два близких родственных свободных дистрибутива - это CentOS и Fedora. Первый считается вообще почти полной копией.
У SUSE Linux Enterprise Server есть OpenSuse. И RHEL, и SLES с их родственниками основаны на rpm-пакетах. Есть еще огромная армия дистрибутивов, основанных на rpm.
Да, и дистрибутивы основанные на deb-пакетах (Debian, Ubuntu и т.п.) не сильно отличаются.

И у меня возник вопрос: а кто нибудь пробовал устанавливать SAP системы на не коммерческие дистрибутивы? CentOS? OpenSuse? Ubuntu? Какие дополнительные шаги были необходимы? Как стабильно работала система? Напишите в комментариях к посту. Я думаю, что всем будет интересен ваш опыт.

В Интернете нашел опыт установки системы SAP R/3 на AltLinux (rpm-based) и, даже, на FreeBSD! :)

P.S. напоминаю также про опрос "Опыт администрирования SAP систем", который закончится в середине октября (на данный момент зафиксированы голоса 23-х человек). Если не участвовали, то просьба - поставьте галочку для статистики. :)

Спасибо.


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

Анализ места на диске в Unix

Как вы знаете из поста "35 лет или как я попал в SAP", я начинал свою профессиональную карьеру с администрирования Unix систем. И я обожаю Unix. Во всём многообразии систем, называемых Unix-подобными, мне нравится ядро, концепция, которая лежит в основе их всех, начиная от AIX и заканчивая Linux.

Сегодня хочу остановиться на файловой системе.

В операционной системе Unix файловая система это отдельный столп, на котором базируется ядро этой системы.

В Windows, в отличии от Unix, понятие файловой системы не выходит на первый план. Есть набор дисков, которые подключены к компьютеру или серверу. Каждый диск имеет привязку к букве латинского алфавита. Без этой привязки работать с диском операционная система не сможет. А уже внутри диска создается файловая система. В Windows это может быть FAT, HPFS или NTFS. Подробности про них можно посмотреть тут.

Рис. 1. Пример жестких дисков в операционной системе Windows.

В Unix есть единый корень файловой системы: "/" (root). Это начало всего. Не зря суперпользователь в Unix так же носит имя "root". Все остальные файловые системы монтируются, как ветки общего дерева.

Это ещё не всё. Все объекты в Unix это файлы. С точки зрения программиста, программа обращается к файлу с помощью четырех системных вызовов: open(), read(), write() и close(). Таким образом, всё, с чем можно работать через данные вызовы, это файлы. Хотя, например в Linux, файлы в каталоге /proc не существуют физически. Это лишь представление внутренних данных ядра в виде файлов. Но работать с ними можно как с файлами. Это просто, универсально и удобно.

В операционной системе Unix есть следующие типы файлов:

• обычный файл (или жесткая ссылка),
• каталог,
• символическая ссылка,
• блочное и символьное устройства,
• именованный канал и доменный сокет Unix.

Обычный файл в Unix может быть многоликим, то есть иметь больше одного имени или жестких ссылок. Причем, это будут просто жесткие ссылки на один и тот же фрагмент памяти на жестком диске, который называется inode. 

Каталоги это тоже файлы. Файлы, содержащие список имён файлов с ссылками на inode (рис. 2). 

Рис. 2. Схема хранения файлов в Unix.

Inode хранит атрибуты файла, такие как тип файла, владелец, группа, права доступа, временные метки, и указатели на блоки данных. Про права доступа в Unix я писал в посте "Oracle + Unix: полномочия на директории". Пока на inode файла существует хоть одна жесткая ссылка, файл удален не будет. Стоит еще отметить, что таблица inodes существует в рамках файловой системы и жесткие ссылки могут быть созданы только внутри одной файловой системы.

Для указания на файлы из других файловых систем существуют символьные ссылки. Которые не что иное, как просто указатель на существующий файл в каком-либо каталоге. Пример использования символьных ссылок на файлы устройств для ленточной библиотеки я описывал в посте "Подружить кластер и brbackup/brarchive".

Блочные и символьные устройства - это файлы, через которые можно работать с теми или иными физическими устройствами. Например, устройство записи на магнитные ленты (символьное), жесткие диски (блочное).

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

Тип файла отображается в результатах команды ls, в виде первого символа перед правами доступа (рис. 3).

Рис. 3. Пример вывода команды ls.

Прочерк - признак обычного файла, d - каталога, l - ссылки и так далее.

Команда find, про которую я рассказывал в посте "HP-UX. Многоликая команда find", может помочь найти те или иные типы файлов. Например, сокеты (рис. 4).

Рис. 4. Пример вывода результатов поиска сокетов Unix.

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

В посте "Файл-пустышка" я уже затрагивал эту тему применительно к одной директории. Я рассказал как создать небольшую заглушку в директории, содержащей оффлайн журналы Oracle. Чтобы в случае заполнения файловой системы до 100% срочно освободить немного места одной командой. В ситуациях отсутствия необходимого пространства в данной директории - это место нужно, как глоток свободного воздуха. Иначе база данных Oracle просто "подвиснет", как и SAP система, которая работает на ней.

Просмотреть место в файловых системах поможет команда df (рис. 5).

Рис. 5. Пример вывода команды df в операционной системе Linux.

Данная команда показывает общее количество блоков (1 Кб), занятых (в Кб и процентах) и свободных блоков по каждой смонтированной файловой системе.

В операционной системе HP-UX более читабельной является команда bdf (рис. 6).

Рис. 6. Пример вывода команды bdf в операционной системе HP-UX.

Если свободное пространство где-то резко уменьшилось, то необходимо выяснить кто и чем его занял. В этом случае поможет команда du. Например,

 # du -ks ./* 

отобразит все каталоги в текущей директории и занимаемое ими пространство в файловой системе в Кб (рис. 7). Опция -k - отображает результаты в Кб, а ключ -s - диктует отображать только суммарное значение занимаемого пространства по каждой директории.

Рис. 7. Пример списка каталогов в директории /var с их размерами.

Еще очень хороший вариант (рис. 8):

 # du -xks / 

Рис. 8. Пример вывода команды, отображающей занимаемое пространство в корневой файловой системе.

При использовании ключа -х команда отображает занимаемое пространство только файлами корневой файловой системы, без других смонтированных файловых систем.

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

1. С помощью команд df (bdf) проанализировать файловые системы и свободное пространство в них.
2. Перейти в необходимую файловую систему и проанализировать пространство, занимаемое каждой директорией, с помощью команды du с необходимыми опциями.
3. Спуститься по дереву каталогов до конца, собрав информацию по пространству.
4. Принять решение по удалению файлов, если это возможно, или расширению файловой системы.

Так же для поиска старых, самых больших или определённых файлов (например, дампов core) можно воспользоваться командой find, про которую я писал в посте "HP-UX. Многоликая команда find".

Дополнительные ключи и опции команд Unix или Linux всегда можно найти в справке man, набрав команду вида:

 # man <command_name> 

P.S. Для Linux есть различные графические утилиты, которые помогают визуализировать занимаемое пространство. Но еще раз повторюсь, команды из командной строки это самый универсальный инструмент, который есть во всех дистрибутивах, версиях и более или менее постоянен.

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