28 сентября 2017 г.

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:

Последний, как это видно из примеров страниц 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-х человек). Если не участвовали, то просьба - поставьте галочку для статистики. :)

Спасибо.


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


25 сентября 2017 г.

Анализ места на диске в 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 есть различные графические утилиты, которые помогают визуализировать занимаемое пространство. Но еще раз повторюсь, команды из командной строки это самый универсальный инструмент, который есть во всех дистрибутивах, версиях и более или менее постоянен.




21 сентября 2017 г.

Пользователь TMSADM

При начальной конфигурации транспортной системы в AS ABAP любой SAP системы в 000 манданте автоматически создаётся системный пользователь TMSADM.

Данный пользователь имеет тип "Communication" или "System" (рис. 1). Но ни в коем случае не "Диалоговый", то есть вход в систему через SAP GUI ему должен быть запрещен.

Рис. 1. Тип учетной записи TMSADM.

Дело в том, что для работы транспортной системы используются RFC-соединения (рис. 2). Эти RFC-соединения генерируются так же при первоначальной настройке транспортной системы (TMS).

Рис. 2. RFC-соединения, использующиеся в работе транспортной системы.

RFC-соединения используются для обмена информацией между системами транспортного ландшафта (рис. 3).

Рис. 3. Схема настройки RFC для работы транспортной системы.

Как видно из схемы и рис. 2, используется 2 вида RFC-соединений:
  • TMSADM@<SID>.<DOMAIN_NAME> - для аутентификации используется пользователь TMSADM, используется для некритичных операций, прежде всего на чтение информации;
  • TMSSUP@<SID>.<DOMAIN_NAME> - используется для более критичных операций, прежде всего операций записи, для аутентификации требует пару пользователь/пароль.

Эти два вида RFC-соединений создаются в каждой системе, которая подключена к транспортному домену. И пользователь TMSADM есть в каждой, но только в 000 манданте.

Так как пользователь TMSADM генерируется автоматически, то для него хранится стандартный пароль, который знают все системы транспортного ландшафта. В разных версиях SAP систем использовались два вида паролей:
  • PASSWORD;
  • $1Pawd2&.

Начиная с версии системы SAP NetWeaver 7.40, при настройке транспортной системы можно задать свой пароль. Или выбрать один из стандартных вариантов паролей (рис. 4).

Рис. 4. Установка пароля для пользователя TMSADM.

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

Проверить пароль пользователя TMSADM, не трогая учетную запись, можно через отчёт RSUSR003. Данный отчет проверяет пароли системных пользователей во всех мандантах системы на предмет их безопасности. То есть, в программе есть список хэшей стандартных паролей, которые он сверяет с реальными в системе. Например, для пользователей SAP* и DDIC, про которых я писал в этом посте.

Результатом работы отчета будет список системных пользователей и вердикт по их паролям (рис. 5).

Рис. 5. Проверка паролей системных пользователей.

Если отчёт в системе не отображает информацию по пользователю TMSADM, то необходимо заглянуть в SAP note # 1552894 - RSUSR003: Checking the standard password for user TMSADM. Установив исправления из ноты или соответствующий пакет поддержки для вашей версии системы, получите новую версию отчёта, которая проверяет пароль для пользователя TMSADM. Как работать с SAP нотами я описывал в цикле статей - часть 1, часть 2, часть 3.

Просто так, войдя в транзакцию SU01, изменить пароль для TMSADM нельзя. Как правильно изменить стандартный пароль для пользователя TMSADM описано в SAP note # 1414256 - Changing TMSADM password is too complex.

Дополнительно на данную тему можно найти информацию в курсе SAP "ADM325 - SAP Software Logistics for ABAP" и SAP note # 761637 - Logon restrictions prevent TMSADM logon.

  


18 сентября 2017 г.

Использование транзакции SE03 для поиска запросов/задач

Про транзакцию SE03 я уже писал в двух постах:

Рассмотрим еще некоторые функции этой транзакции. 

С помощью транзакции SE03 можно искать транспортные запросы в системе. Для этого в древовидном меню на главном экране транзакции необходимо выбрать пункт "Инструменты организатора переносов -> Запросы/Задачи -> Поиск запросов" и нажать кнопку "Выполнить" на панели (рис. 1).

Рис.1. Вызов функции по поиску запросов на перенос.

На появившемся экране откроется огромное количество фильтров, используя которые можно ограничить поиск. Для открытия всех параметров необходимо на панели нажать кнопку "Развернуть" и заглянуть в средство поиска "Тип запроса" (рис. 2).  

Рис. 2. Набор фильтров для поиска запросов в системе.

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

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

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

Рис. 3. Результаты поиска транспортных запросов.

Следующая функция в данной категории это "Объединение списков объектов" (рис. 4).

Рис. 4. Объединение списков объектов запросов.

Вызываем функцию, нажав на панели кнопку "Выполнить". На следующем экране устанавливаем фильтры для поиска запросов и нажимаем "Выполнить". Затем выделяем необходимые транспортные запросы с помощью кнопки "Выделить ветвь +/-" на панели и нажимаем на той же панели кнопку "Объединить" (рис. 5).

Рис. 5. Объединение объектов двух транспортных запросов.

Указываем существующий или создаем новый транспортный запрос и получаем объединение объектов в одном запросе (рис. 6).

Рис. 6. Создание транспортного запроса для включения объектов.

Так же в транзакции SE03 есть функция снятия блокировки с объектов (рис. 7). Данная операция бывает необходима, например, при импорте пакетов обновлений в систему. Когда импорт обновлений "натыкается" на блокированные в транспортных запросах объекты.

Рис. 7. Снятие блокировки с объектов.

На первом экране программы снятия блокировки с объектов необходимо указать номер запроса или задачи, объекты которого вы хотите разблокировать. Есть несколько опций (рис. 8).

Рис. 8. Разблокирование объектов транспортного запроса.

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




14 сентября 2017 г.

Опрос: опыт администрирования SAP систем

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

И это было не лишено смысла. Эти люди, на тот момент, были фактически теми, кто стоял у истоков внедрений SAP систем в России. Кто первым окунулся в романтику первых робких внедрений в России. Кто был ветераном на линии немецко-российских отношений между бизнесом и информационными системами для автоматизации этого самого бизнеса.

По прошествии лет пяти ситуация кардинально изменилась: специалистов на рынке труда в России стало больше, людей с большим опытом тоже. И шестью годами опыта в SAP-консалтинге или поддержке никого не удивишь. Сейчас тем более.

В 2011 году я в своём блоге проводил опрос, целью которого было определить опыт администрирования SAP систем среди читателей моего блога. К сожалению, на тот момент я использовал в качестве платформы для опросов средства blogspot.com и результаты опроса пропали. А я их не зафиксировал.

Поэтому давайте проведем опрос еще раз. Буду очень признателен, если Вы примете участие.

Опрос завершен, 39 человек приняли участие. Всем большое спасибо. Результаты получились следующие (рис. 1).

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

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

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

Выводы очень грустные. У почти половины участвовавших огромный опыт администрирования SAP систем - больше 6 лет, а на мой призыв поучаствовать в наполнении блога никто не откликнулся. Неужели у вас нет каких-то заметок, идей для написания, пусть небольшого, но кому-то полезного поста? Не верю. В чём причина? Лень, отсутствие времени, нежелание делиться своими знаниями или не нравится предложенный формат? Напишите хотя бы почему нет. :) Если вы начинали вести свой блог и у вас было несколько постов, то можно, актуализировав, прислать их. Дополнительный ресурс не будет лишним. Мои статьи тоже дублируются: на этом блоге и на портале SAPLand.

Написание статей это прекрасная возможность. Недавно SAPLand расширил набор бонусов для авторов статей на портале:
  1. Книги на русском языке о SAP (нашего издательства) и электронные на английском языке (авторам нескольких статей) в подарок. 
  2. Журнал SAP Professional Journal Россия в бумажной форме по почте бесплатно.
  3. После одной статьи (в год) предоставляется бесплатный доступ к платной базе знаний переводных материалов https://goo.gl/KBUPrr.
  4. По запросу высылаются отдельные статьи из базы http://sapexperts.wispubs.com.
  5. Предоставляется возможность бесплатно обучаться на мастер-классах, проводимых порталом (авторам нескольких статей). Очередная сессия состоится с 23 по 27 октября 2017 года.

Так что не теряйтесь. :)

Предыдущий опрос можно найти в посте "Опрос: версия SAP ERP".


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


11 сентября 2017 г.

Полные полномочия в SAP системе


Как я уже отмечал, в AS ABAP SAP системы для разграничения доступа к информации существует набор ролей и полномочий. Исходное правило: что не разрешено, то запрещено. Таким образом, чтобы пользователь смог выполнить действие в системе или получить доступ к информации, необходимо ему назначить роль, с которой ассоциируется профиль полномочий, в котором, в свою очередь, содержатся конкретные полномочия. Подробнее в посте "Как понять каких полномочий не хватает пользователю?".

Для получения полного набора полномочий в ABAP части SAP системы существует 2 готовых профиля полномочий:
  • SAP_ALL - составной профиль полномочий, который содержит все полномочия в SAP системе;
  • SAP_NEW - составной профиль полномочий, который используется при обновлении системы. Обеспечивает достаточный набор полномочий во время операций обновления, таких как установка пакетов поддержки или обновление версии SAP системы. 

Таким образом, для того чтобы создать в системе пользователя со всеми полномочиями, некого Super User, достаточно в транзакции SU01 добавить ему профили полномочий SAP_ALL и SAP_NEW (рис. 1).

Рис. 1. Добавление всех полномочий пользователю в SAP системе.

Начиная с релизов SAP_BASIS 700 и выше, профиль полномочий SAP_NEW был заменен на роль с таким же именем - SAP_NEW. Подробности в SAP note # 1711620 - Role SAP_NEW replaces profile SAP_NEW

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

SAP ноты на эту тему:

Так же можно посмотреть SAP курсы "ADM 940 - ABAP AS Authorization Concept" и "ADM 950 - Secure SAP System Management".



7 сентября 2017 г.

Поиск авторов для написания постов


Я веду этот блог с переменным успехом уже 9 лет. Были периоды, когда по несколько месяцев я ничего не публиковал, но в целом, я считаю, что ресурс держится на своём уровне.

Мою историю того, как я попал в SAP и занялся администрированием SAP систем, вы знаете. Об этом я писал в посте "35 лет или как я попал в SAP". Также я писал о том, что мне приносит написание статей в этом блоге ("Зачем я веду этот блог?").

Читая эти две истории, которые я описал в предыдущих постах, можно вспомнить фразу "время разбрасывать камни и время их собирать". Что означает, что в карьере любого человека есть время, когда он интенсивно впитывает знания, учится и постигает тонкости мастерства. А есть время, когда он сам отдаёт свои знания и делится опытом. Может быть, так и работает глобальный механизм человеческого развития и движения вперед. Причём, передача знаний это сам по себе процесс обучения, но уже на более высоком уровне.

Я предполагаю, что большинство тех, кто читает этот блог занимается администрированием SAP систем, как и я, или работают в смежных областях. И я на 100 % уверен, что хотя сфера занятий у нас одна, у каждого из нас свой путь, который нас привёл в эту профессию. И свой уникальный опыт. Все проекты разные. У компании SAP огромное количество решений и систем, которые в большинстве своём базируются на одной платформе (SAP Basis или SAP NetWeaver), но нюансы у которых разные. Комбинаций систем (особенно, если учитывать версии продуктов), используемых на предприятиях, огромное количество. Даже в рамках одной системы - SAP ERP, на данный момент эксплуатируется огромное количество версий, что показывают результаты недавнего опроса. Задачи, решаемые в рамках проектов, формируют картину вашего неповторимого и уникального опыта.

К чему я это всё веду? Одна голова хорошо, а две лучше. Предлагаю вам поделиться своим опытом и своими знаниями и стать соавторами данного ресурса.

Стоит отметить, что среди почти 300 постов этого блога есть парочка не моих. Это пост "История одного долгоиграющего отчета" от Дмитрия Бондарева и "Что такое SAP?" от Алексея Петрова. Первый был опубликован по инициативе автора, а второй по моей. Но это были единичные случаи. Сейчас же я предлагаю стать постоянными соавторами блога "Записки SAP Basis консультанта". Как я уже упоминал в одном из постов, многие начинают свои блоги, но не многим хватает упорства и вдохновения постоянно их поддерживать. Я же предлагаю соединить наши усилия и создать ресурс, который объединит опыт и знания многих в одной базе знаний по администрированию SAP систем.

Итак, что я предлагаю:
  • ресурс с целевой аудиторией из SAP Basis специалистов в количестве примерно 90-100 читателей в день;
  • помощь с моей стороны в оформлении и написании постов и статей (соавторство);
  • возможность структурировать свои знания, оформив их в читаемый вид;
  • признание сообщества, широкая известность в узких кругах;
  • страница автора с резюме на сайте этого блога (аналог моей) при публикации хотя бы 3-х статей,
  • в случае публикации успешной статьи, возможность выхода на аудиторию SAPLand.ru.

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

Все свои темы, предложения и статьи присылайте мне на электронный ящик - shibolov@gmail.com.

Статьи публикую на ресурсе я с обязательной ссылкой на авторство. Я помогаю оформлять статьи, внося корректировки с согласия автора. Даты публикации выбираю я.

Признательность сообщества SAP Basis администраторов и удовлетворение от хорошего дела гарантирую. :)


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


4 сентября 2017 г.

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

Секретик 1.

При импорте транспортного запроса в систему через транзакцию STMS можно выбрать 2 режима: синхронный и асинхронный. В первом случае режим SAP GUI будет блокирован до окончания выполнения всех шагов импорта. Во втором случае режим SAP GUI будет сразу освобожден, а импорт транспортного запроса будет происходить в фоне. Выбор режимов происходит в диалоговом окне после выбора пункта меню "Запрос -> Импортировать" во вкладке "Выполнение" (рис. 1).

Рис. 1. Выбор режима импорта транспортного запроса.

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

Рис. 2. Планирование импорта транспортного запроса по времени.

После планирования времени импорта в системе будет сформировано фоновое задание (транзакция SM37), которое выполнится в указанное время (рис. 3). У транспортного запроса будет установлен статус "Запланировано" (рис. 4). Данный тип планирования удобен при импорте запросов в нерабочее время, чтобы изменения не коснулись работающих в текущий момент в системе пользователей.

Рис. 3. Фоновое задание по импорту транспортного запроса в систему.

Рис. 4. Статус транспортного запроса после планирования импорта по времени.


Секретик 2.

Еще один нюанс про транспортную систему. Любой транспортный запрос можно переадресовать из очереди одной системы в очередь любой другой системы в рамках транспортного ландшафта вручную. Данное действие можно выполнить вне зависимости от настроенных путей переноса, главное условие: чтобы система была известна в данном ландшафте. Для этого необходимо установить курсор на номер транспортного запроса в очереди на перенос и выбрать пункт меню "Запрос -> Переадресовать -> Система" (рис. 5).

Рис. 5. Переадресация транспортного запроса в другую систему.

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

Рис. 6. Выбор системы для переадресации транспортного запроса.


Секретик 3.

В посте "Стандартные пользователи системы SAP" я писал, что в SAP системе после инсталляции всегда присутствует 000 мандант, который является эталоном. Изменения проводить в нём не рекомендуется. Он используется при создании новых мандантов в системе и для некоторых базисных работ, таких как, обновление системы, установка SAP notes и так далее. Обычно работы, которые проводят в 000 манданте рекомендуют проводить, войдя в систему на английском (EN) языке. Чтобы каждый раз в окне логина не указывать язык EN (что, кстати, легко забывается, так как обычно мы его не указываем, прописав в настройках для всех язык RU, по-умолчанию), я рекомендую в настройках основной записи своего пользователя (транзакция SU01) в 000 манданте сразу указать язык логина EN на вкладке "ПостЗначения" (рис. 7). И входить в 000 мандант всегда на языке EN.

Рис. 7. Установка языка входа для пользователя по умолчанию.


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


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