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

Секретик 1.

Про транспортную систему я писал уже не раз (прочитать можно тут или тут). Типичная картина: в системе настройки/разработки создаётся транспортный запрос, который содержит изменения (записи таблиц с настройками или объекты ABAP-словаря). Затем этот запрос деблокируется (released) и отправляется дальше по системам для тестирования и промышленной эксплуатации. Это все, наверное, знают.

Так же вы знаете, что ABAP-словарь системы является общим для всех мандантов системы, а настройки могут быть двух видов - манданто-зависимые (большинство) и манданто-независимые. Манданто-независимые объекты доступны для всех мандантов системы сразу после создания. А манданто-зависимые оказывают влияние только на текущий мандант.

Часто бывает ситуация, когда в системе настройки создано несколько мандантов: чистая разработка-настройка, первичный тест, "песочница" и так далее. Первый сегодняшний секретик заключается в том, что есть возможность перенести запрос с манданто-зависимыми настройками внутри одной системы - из одного манданта в другой. Причем, запрос даже не нужно деблокировать - он может оставаться открытым для изменения. Для этого, после создания запроса с настройками в исходном манданте, необходимо войти в целевой мандант той же системы и запустить транзакцию SCC1. На основном экране необходимо указать номер транспортного запроса и исходный мандант, в котором запрос был создан. После этого поставить галочку напротив пункта "Включ. нижестоящие задачи запроса" и нажать кнопку "Немедленный запуск" (рис. 1).

Рис. 1. Основной экран транзакции SCC1. 

Подтвердить перенос данных, нажав "Да" в диалоговом окне (рис. 2).

Рис. 2. Запрос на копирование данных между мандантами.

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

Рис. 3. Журнал переноса запроса между мандантами одной системы.

Отдельно журнал доступен в транзакции SCC3. Для отображения журналов переносов запросов между мандантами необходимо на панели нажать кнопку "Все запросы на перенос" (рис. 4 и 5).

Рис. 4. Начальный экран транзакции SCC3.

Рис. 5. Просмотр журнала в транзакции SCC3.

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

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


Секретик 2.

Как-то я писал пост про такой полезный инструмент, как "User Information System", к которому можно получить доступ через транзакцию SUIM. В транзакции представлен набор отчетов по пользователям/ролям/полномочиям в системе. Инструмент хороший, но очень объемный.

Поэтому второй секретик будет о том, как посмотреть документы изменений для пользователя ABAP системы. Необходимо войти в транзакцию SU01 (Ведение пользователей), ввести имя пользователя, а в меню выбрать пункт "Инфо -> Документы изменений для пользователей" (рис. 6).

Рис. 6. Вызов отчета по документам изменений для пользователя.

Откроется один из отчетов SUIM, в котором необходимо установить фильтр для событий, а так же можно указать временные рамки. После чего нажать "Выполнить" (рис. 7).

Рис. 7. Начальный экран отчета по документам изменений для пользователя.

Система выдаст всю информацию по пользователю: когда был создан, когда менялся пароль или был блокирован (рис. 8).

Рис. 8. Информация по пользователю системы.

Один интересный момент - если пользователь был удален из системы, то данный журнал изменений в системе всё равно хранится (обратите внимание на последнюю запись в отчете на рис. 8).

Таким образом можно просмотреть информацию и по удалённым пользователям. И вычислить кто, когда и кого удалил. :)


Секретик 3.

В нескольких постах я уже рассказывал, что в SAP системе можно увеличивать производительность уровня сервера приложений через установку дополнительных диалоговых инстанций (пост 1, пост 2). В случае нескольких установленных инстанций для входа в систему используют "Logon Group"-ы, которые указываются в программе SAP Logon. Основательный пост про это можно найти тут.

При входе в систему вы попадаете на одну из диалоговых инстанций, в зависимости от настроек вышеуказанных Logon Group и встроенной системы балансировки нагрузки со стороны Message Server.

Текущую диалоговую инстанцию можно посмотреть в правом нижнем углу любого окна SAP GUI (рис. 9).

Рис. 9. Определение текущей диалоговой инстанции.

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

Рис. 10. Переход на другую диалоговую инстанцию в рамках одной системы.

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


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


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

Пользователь 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.

  

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

Мульти-логин в SAP систему

Как вы знаете, для входа в ABAP часть SAP системы используется клиентское место SAP GUI. При входе в SAP систему пользователь указывает свой ID (учетную запись), который часто, в российской SAP практике, совпадает с фамилией пользователя. Хотя, изначально подразумевалось, что ID пользователя будет совпадать с его табельным номером. Поэтому даже в последних релизах SAP систем это поле не больше 12 знаков (рис. 1). Но на каких российских предприятиях сотрудники знают свой табельный номер наизусть? :)

Рис. 1. Начальное окно входа в SAP систему.

После успешного входа в систему, при попытке повторно войти в систему с тем же ID появится окно с предупреждением, в котором указывается с какого терминала (IP адрес + hostname) и в какое время уже был выполнен вход в систему (рис. 2).

Рис. 2. Попытка входа в систему дважды.

В таком случае, по-умолчанию, система предлагает выбрать из трёх вариантов:

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

При втором варианте произойдет, так называемый, мульти-логин в систему. Данные об этом SAP система тщательно сохраняет в таблице USR41_MLD (рис. 3).

Рис. 3. Пример записи в таблице USR41_MLD.

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

•  пиковое количество одновременно работающих пользователей с одинаковым ID, 
•  счётчик зафиксированных фактов мульти-логина,
• даты и время первого и последних мульти-логинов в SAP систему.

Информация о текущих регистрациях в систему хранится в таблице USR41 (рис. 4).

Рис. 4. Пример содержимого таблицы USR41.

Таким образом, когда пользователь входит в SAP систему, информация об этом записывается в таблицу USR41. При новой попытке входа, происходит считывание записей из этой таблицы и при обнаружении записи с таким ID, выдается вышеуказанное предупреждение (рис. 2).

Как вы, наверное, уже знаете, SAP системы лицензируются по количеству пользователей, работающих в продуктивной системе. Таким образом, мульти-логины, когда несколько пользователей одновременно работают в системе под одним ID, не только снижают безопасность системы и подвергают риску сохранение консистентности данных, но и нарушают лицензионное соглашение. Поэтому компания SAP SE отслеживает эти нарушения. При проведении лицензионного аудита (транзакция USMM) в отчёт, помимо всего прочего, попадает информация из таблицы USR41_MLD. На основании этого компания оставляет за собой право пожурить клиента за мульти-логины в систему.

Дабы не доводить до греха и повысить безопасность системы, можно отключить возможность мульти-логина в систему через установку параметра профиля SAP: login/disable_multi_gui_login = 1 (рис. 5).

Рис. 5. Описание параметра login/disable_multi_gui_login.

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

Рис. 6. Попытка входа в систему дважды после установки запрета на мульти-логин.

Одновременно с этим, в параметре login/multi_login_users можно указать пользователей, которым будет разрешён мульти-логин в SAP систему (рис. 7). ID пользователей следует перечислять через запятую без пробелов, заглавными буквами.

Рис. 7. Описание параметра login/multi_login_users.

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

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

Подробности про лицензионный аудит можно найти тут.


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

"Меню пользователя" vs "Меню SAP"

В клиентском месте SAP GUI на верхней панели слева есть две кнопки: "Меню пользователя", которое основано на ролях присвоенных пользователю и "Меню SAP", представляющее собой общее стандартное древовидное меню (рис. 1).

Рис. 1. Кнопки вызова меню SAP и меню пользователя.

В общем случае, нажимая на ту или иную кнопку, пользователь может переключаться между двумя видами меню.

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

Отдельные пункты меню пользователь SAP системы может добавлять в Избранное или Фавориты, которые отображаются в верхней части при выборе любого типа меню. Добавить транзакцию в избранный список можно двумя способами. Либо через нажатие правой клавиши мыши на нужной функции в меню и выбор пункта "Добавить в избранное" (рис. 2). Либо через код транзакции, нажав правой клавишей на папку "Избранное" и выбрав пункт "Вставить транзакцию" (рис. 3).

Рис. 2. Добавление пункта меню в избранное.

Рис. 3. Добавление в избранное транзакции через её код.

Очень часто возникает ситуация, когда пользователь, случайно нажав на кнопку "Меню SAP", получил на экране не привычное ему меню, а стандартное меню SAP, в котором он не может найти необходимые ему для работы функции и транзакции. Поведение системы по-умолчанию подразумевает показ из двух этих типов меню того, которое было выбрано в последнюю сессию работы в системе. Таким образом, нажав однажды не на ту кнопку, пользователь будет при каждом логине иметь одну и ту же пугающую картину: огромное древовидное стандартное меню (рис. 4).

Рис. 4. Стандартное меню SAP.

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

Первый предполагает деактивацию кнопки "Меню SAP" для всей системы. Для этого необходимо войти в транзакцию SM30, выбрать ракурс ведения для таблицы SSM_CUST (рис. 5) и параметру SAP_MENU_OFF присвоить значение 'YES' или 'X' (рис. 6). Следует помнить, что эта настройка производится для всех мандантов системы.

Рис. 5. Ведение ракурса таблицы SSM_CUST.

Рис. 6. Отключение кнопки стандартного меню SAP.

В результате у пользователей в системе всегда будет только меню на основе их ролей, а кнока "Меню SAP" будет деактивирована (рис. 7).

Рис. 7. Кнопка "Меню SAP" неактивна.

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

Рис. 8. Пустое меню пользователя.

Таким же образом можно дективировать кнопку "Меню пользователя", указав в том же ракурсе ведения параметр ALL_USER_MENU_OFF =  'YES' (или 'X') (рис. 9 и 10).

Рис. 9. Отключение кнопки "Меню пользователя".

Рис. 10. Кнопка "Меню пользователя" неактивна.

При выставлении обоих параметров в 'YES' (или 'X') у пользователей будут на экране только списки избранного (рис. 11). То есть меню будет отключено.

Рис. 11. Деактивация меню у пользователей.

Второе решение подразумевает настройку доступности разных типов меню для каждого отдельного пользователя. Для этого необходимо в транзакции SM30 выбрать ракурс ведения к таблице USERS_SSM (рис. 12).

Рис. 12. Ведение ракурса таблицы USERS_SSM.

В таблице можно для каждого пользователя прописать какой тип меню для него будет доступен (рис. 13).

Рис. 13. Настройка меня для каждого пользователя.

Настройка из данной таблицы имеет больший приоритет, чем общесистемная настройка в таблице SSM_CUST. Поэтому для пользователей ADMIN и SHIBOLOV экраны будут выглядить согласно настройке из таблицы USERS_SSM (рис. 14 и 15).

Рис. 14. Экран пользователя ADMIN c активным "Меню пользователя".

Рис. 15. Экран пользователя SHIBOLOV с активным "Меню SAP".

В транзакции SSM2 можно переопределить меню, которое будет показываться в качестве начального "Меню SAP" (рис. 16).

Рис. 16. Установка меню в качестве стандартного.

Если выбрать в качестве основного, например, "S002 -Системное администрирование", то основной экран со стандартным меню будет выглядеть совсем по-другому (рис. 17).

Рис. 17. Стандартное начальное меню SAP с поддеревом "Системное администрирование".

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

• отключить всё меню для всех,
• деактивировать кнопку "Меню SAP" для основного числа пользователей или конкретных лиц,
• деактивировать кнопку "Меню пользователя" для всех пользователей или конкретных лиц.

Подробности по этой теме можно найти в SAP note # 380029 - FAQ: Customizing of SAP Easy Access.


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

Backdoor в SAP

В посте "User Information System" я рассказывал про встроенную систему отчетов, с помощью которой можно по различным критериям получать списки пользователей/полномочий/ролей и т.п. Недавно обнаружил, что в этой системе есть интересный, в какой-то степени даже опасный, нюанс. Заключается он в следующем:
Если мы создадим в системе пользователя с именем "............" (12 точек), то он не будет отображаться ни в одном из списков User Information System.

Для примера возьмем свеженькую систему SAP Solution Manager 7.1 SPS 08 (SAP_BASIS patch level 12). Создадим вышеуказанного пользователя с профилем SAP_ALL (рис. 1, 2).

Рис. 1. Создание пользователя "............".

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

Под данным пользователем можно войти в систему (рис. 3).

Рис. 3. Вход в систему под пользователем "............".

А теперь попробуем этого пользователя найти. Например, с помощью отчета RSUSR002. Зададим в качестве критерия - "все пользователи с профилем SAP_ALL" (рис. 4, 5).

Рис. 4. Экран выбора отчета RSUSR002.

Рис. 5. Результат работы отчета RSUSR002.

Результаты удивительны: нашего пользователя тут нет.

Во таком поведении виноваты несколько строк в инклуде SR002F10 программы RSUSR002 (рис. 6).

Рис. 6. Код программы RSUSR002.

Данный код явно удаляет пользователя "............" из результатов работы отчета RSUSR002.

В компании SAP это назвали 'program error'. Ситуация и ее решение описываются в SAP note # 1844202 - SUIM| RSUSR002 User '............' is not found. А следы ведут нас к SAP note # 694250 - SUIM|RSUSR002: Negative multiple selection for profiles, в которой в злополучный инклуд SR002F10 вставляется кусок кода с вышеуказанными строками.

Как видно из SAP note # 1844202 данная ошибка затрагивает почти все системы с SAP_BASIS от 46B до 740. Мелочь, а неприятно.

На данную тему меня навела статья на сайте habrahabr.ru

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

User Information System

А вы знаете как получить список всех пользователей с начальными паролями - тех, кто не сменил свой пароль на продуктивный. Это может быть серьезной брешью в безопасности SAP системы. Или как узнать кто из пользователей имеет те или иные полномочия, не перебирая все роли, присвоенные пользователям.
На эти вопросы и массу других может ответить User Information System. Это набор отчетов, осуществляющих построение списка пользователей/ролей/полномочий по тем или иным критериям. Это может быть полезно при решении проблем из области пользователи/роли/полномочия или анализа системы в плане безопасности.

Например, отчет RSUSR200 (рис. 1, 2) позволяет составить список пользователей по дате входа и изменению пароля. С помощью него можно выявить пользователей, которые имеют начальный пароль или не входили в систему длительное время. Очень удобно начальнику отдела отслеживать кто как часто ходит в систему. :)

Рис. 1. Основной экран отчета RSUSR200.

Стандартные пользователи системы SAP

Как известно, после начальной установки любой SAP системы с ABAP-стэком мы имеем несколько стандартных мандантов:

• 000 - эталонный мандант, "прародитель" рабочих мандантов системы; в данном манданте производятся работы по обновлению системы, настройке транспортной системы и так далее;
• 001 - стандартный мандант, "прародитель" рабочих мандантов системы, в некоторых системах  (например, в SAP Solution Manager) может быть использован как рабочий мандант;
• 066 - так называемый "Early Watch Client"; может быть использован службой поддержки компании SAP AG для доступа к системе клиента для анализа проблем, в частности с производительностью.

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

В мандантах 000, 001 после установки системы есть 2 стандартных пользователя:

• SAP* - используется при копировании мандантов, установки/продления лицензии (в случае ее скоропостижного окончания) и т.п.
  Раньше после установки пользователь имел начальный пароль: "06071992", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password":
  
  

  

  Экран установки SAP системы

  
  При удалении учетной записи остаётся псевдо-пользователь с начальным паролем "PASS", с помощью которого можно войти в систему. Подробности я описывал в посте: Как попасть туда, куда не пускают.
  
  
• DDIC - используется при установке системы, обновлении, настройке и работе транспортной системы и других процессах.
  Блокировка/удаление ведет к останову многих процессов системы.
  Раньше после установки пользователь имел начальный пароль: "19920706", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password".

Иногда во время установки системы, основанной на SAP NetWeaver происходит сбой и, после вроде бы корректной установки, администратор не может войти в систему под стандартными пользователями с "Master Password".
В данном случае стоит попробовать старые стандартные пароли. Кстати, пароль - это дата выпуска первой SAP R/3 системы: 6 июля 1992 года.

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

Диалоговые инстанции SAP: балансировка нагрузки

Любая SAP система имеет трехзвенную архитектуру.

Рис. 1. Трехзвенная архитектура SAP системы

Уровень базы данных представляет собой инстанцию базы данных (ORACLE, MSSQL, MAXDB, DB2, SYBASE ASE). Идентифицируется DBSID.

Уровень приложений состоит из центральной инстанции SAP (CI). Если упрощенно, то это исполняемые файлы SAP kernel плюс ABAP/J2EE программы, хранящиеся в базе данных. Идентифицируется SAP SID или просто SID, которые обычно совпадает с DBSID.

Ну и наконец, уровень представления, который в большинстве случаев располагается на рабочей станции пользователя и представляет собой SAP GUI. В случае использования "тонкого клиента" (пользователь работает через Web-браузер) уровень презентации переносится на сервер SAP (ITS сервер).

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

Рис. 2. SAP система с несколькими серверами приложений

Рабочие процессы (в основном диалоговые) диалоговых инстанций имеют свои соединения к shadow-процессам ORACLE. А процесс Message Server (MS) центральной инстанции организовывает работу диалоговых инстанций, при запуске регистрируя их у себя, а затем распределяя соединения пользователей и отслеживая состояние SAP инстанций.

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

Пользователи системы через SAP GUI могут коннектиться напрямую на любую диалоговую инстанцию (включая центральную), зная IP-адрес/hostname сервера и номер инстанции. Но в данном случае это очень "скучно". Интереснее создать логон-группы (SAP LogonGroup) в транзакции SMLG, распределив диалоговоые инстанции между ними. На рабочем месте каждого пользователя в SAP Logon прописать ту или иную логон-группу и указать адрес Message Sever. Вход в систему в данном случае происходит по следующей схеме:

1. Первый пакет от SAP GUI пользователя отправляется к Message Server.
2. Message Server имея список запущенных серверов приложений, входящих в логон-группу пользователя, выделяет один из них, посылая обратный пакет с координатами сервера, пользователю.
3. Получив сетевой пакет от Message Server, SAP GUI соединяется с сервером приложений, координаты которого получил.

Рис. 3. Соединение с системой SAP через логон-группу

Обсудим, как лучше распределить сервера приложений (диалоговые инстанции) по логон-группам. Возьмем для примера систему SAP ERP, в которой работают 400 пользователей, равномерно распределенные по SAP модулям системы: MM, FI и PM. Данные пользователи работают в 8 подразделениях предприятия. Установлены центральная инстанция системы и 6 дополнительных серверов приложений.

Следуя управленческому подходу, можно разделить сервера приложений, создав логон-группы для подразделений. Например, на 6 диалоговых серверах будут созданы 3 логон-группы (по 2 сервера на группу). Пользователи 8 подразделений будут распределены по 3 логон-группам по территориальному или иному признаку. Этот подход, к сожалению, не эффективный.

Рекомендуемым подходом будет распределить пользователей по модулям системы. То есть создать 3 логон-группы (по 2 сервера приложений в каждой): MM_users, FI_users, PM_users. В SAP Logon пользователям прописать логон-группу, с функциональностей которой пользователь работает. Преимущество данного решения следующее. В сервере приложений SAP есть несколько буферов для ускорения работы системы (самый крупные и важные - Program buffer и Table buffer). И когда на инстанции работают пользователи одного модуля, то они запускают в основном приложения своего модуля и обращаются к таблицам, содержащим данные этого модуля. Таким образом, SAP буферы диалоговых инстанций логон-группы будут содержать программы, объекты словаря, экраны и данные таблиц только одного модуля. Это резко повышает количество попаданий в буфер, эффективность использования буферов и памяти сервером приложений SAP. И уменьшает время реакции (response time) всей системы.

Конечно, если какой-то модуль в системе очень сильно нагружает систему, в сравнении с другими, например, PM, то эффективнее будет отдать логон-группе PM_users 3 диалоговых инстанции. А на трех других создать логон-группу для модулей FI и MM.

Вообще грамотное использование диалоговых инстанций позволяет получить ряд плюсов:

• минимум 2 диалоговые инстанции в логон-группе обеспечат отказоустойчивость группы. При выходе из строя одной из инстанций в логон-группе пользователи смогут работать на оставшейся (пользователи, кто был на злополучной инстанции вынуждены будут переконнектиться к системе) без изменения записи в SAP Logon. 
• минимум 2 диалоговые инстанции в логон-группе  активируют встроенный механизм балансировки нагрузки между инстанциями внутри логон-группы. Message server при выборе диалоговой инстанции для пользователя руководствуется временем отклика (response time) и количеством пользователей, работающих на инстанциях.
• распределение пользователей по диалоговым инстанциям позволяет исключить из логон-групп центральную инстанцию. После чего, уменьшив размеры SAP буферов на центральной инстанции, можно отдать все ресурсы сервера (CPU, ОЗУ) базе данных (ей-то мало не бывает никогда :о) ).

 Подводя итоги, правила "лучшей практики" в случае логон-групп следующие:

• включайте в логон-группу минимум 2 сервера приложений,
• разделяйте пользователей по модулям/функциональности,
• закрывайте центральную инстанцию для пользователей (по возможности),
• "кормите" ORACLE лучше, так как больше рабочих процессов SAP требуют больше процессов ORACLE. Частные случаи можно посмотреть тут и тут.

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