Особенности конфигурации файла /etc/services для SAP в SUSE Linux

Как знают постоянные читатели моего блога, в последнее время я начал плотно работать с операционной системой Linux (в частности SUSE Linux) в качестве платформы для разворачивания SAP систем. Сегодня расскажу ещё об одной особенности, с которой лично столкнулся.

После базовой установки ABAP-части SAP системы на операционную систему SUSE Linux обнаружил, что не корректно работают некоторые транзакции. В частности, транзакции, которые используются в системе с несколькими серверами приложений (я упоминал про это в этом посте). Прежде всего это транзакция AL08 - просмотр пользователей всех серверов приложений, выполнивших вход в систему. Также проблемы возникают в транзакциях SM21 (системный журнал) и SM20 (журнал безопасности) при попытке дистанционно просмотреть журналы других инстанций. Например, на начальном экране транзакции AL08 в старых версиях SAP систем не отображается ни одной активной инстанции, даже текущей (рис. 1).

Рис. 1. Не корректно работающая транзакция AL08.

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

Дело в том, что внутри данных транзакций используется функциональный модуль TH_SERVER_LIST (для просмотра используем транзакцию SE37), который в свою очередь вызывает внутреннюю C-функцию SAP ядра ThSysInfo (рис. 2).

Рис. 2. Пример исходного кода функционального модуля TH_SERVER_LIST.

Если мы попробуем протестировать работу данного функционального модуля, нажав на панели соответствующую кнопку (рис. 3).

Рис. 3. Тестирование работы функционального модуля TH_SERVER_LIST.

На следующем экране, не указывая параметров, выполним модуль (рис. 4).

Рис. 4. Тестирование работы функционального модуля TH_SERVER_LIST.

Для просмотра результатов необходимо щелкнуть на строке таблицы LIST напротив надписи "Результат" (рис. 5).

Рис. 5. Просмотр результатов теста.

На экране появится строка таблицы (рис. 6).

Рис. 6. Просмотр результатов теста.

Функциональный модуль вызывает функцию SAP ядра, которая должна вернуть имя сервиса или номер порта текущей инстанции SAP системы. А в данном случае мы видим какой-то tick-port. Что это? 

Дело в том, что во всех Unix-like операционных системах сервисы, которые работают в системе, должны быть зарегистрированы. Имена сервисов, используемые ими порты и протоколы описаны в файле /etc/services.

К слову сказать, в MS Windows этот файл тоже есть и находится по пути - C:\Windows\System32\drivers\etc\services.

Если сервис не зарегистрирован, то есть не описан в этом файле, то ни одно приложение не может его использовать. Инстанции SAP системы не исключение и все свои сервисы должны описать в этом файле. Строки обычно добавляются автоматически в конец файла в процессе инсталляции SAP системы (рис. 7).

Рис. 7. Пример строк SAP системы в файле /etc/services.

Но разработчики операционных систем семейства Linux, в частности SUSE Linux, решили добавить в этот файл все возможные сервисы, которые могут быть в системе. Наверное, это сделали из лучших побуждений - чтобы потом после разворачивания почти любого приложения, всё работало. В итоге, сразу после инсталляции операционной системы данный файл уже имеет больше 12 000 строк сервисов!

Детальный анализ показал, что с номером порта, который используется текущей инстанцией, в этом файле уже есть записи (рис. 8).

Рис. 8. Строки с нашим номером порта для сервиса Tick Port.

Узнаёте? :) Это и есть то, что возвращает наша функция SAP ядра. То есть происходит поиск по номеру порта до первого совпадения. Имя сервиса считывается и передаётся ABAP-программе.

Решением данной проблемы может быть удаление или комментирование всех строк, в которых используются порты SAP системы. Этот список я приводил в этом посте. Так как портов очень много, то эта задача может быть не простой. По-хорошему стоит ещё и проанализировать какие сервисы используются в системе, а какие нет. Чтобы случайно что-нибудь не сломать.

Поэтому я применил другое решение. Можно после установки SAP системы перенести строки с сервисами SAP системы из конца файла /etc/services в его начало (рис. 9).

Рис. 9. Перенос строк с SAP сервисами в начало файла /etc/services.

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

Рис. 10. Пример корректной работы функционального модуля.

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

Надеюсь, что эта информация кому-то пригодится.

Похожие проблемы описаны в SAP notes:

• 947726 - Sec audit: SM20 does not display all existing servers,
• 2135427 - TH_SERVER_LIST Does Not Provide Dispatcher Service.

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

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


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

Транзакция SM02: сообщения в SAP системе

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

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

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

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

Кнопки на панели дублируют пункты меню "Перейти к" (рис. 2).

Рис. 2. Основные функции транзакции SM02.

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

Рис. 3. Создание нового сообщения в системе.

После нажатия, как я уже писал, клавиши "Enter" или кнопки с зеленой галочкой в диалоговом окне, сообщение будет активировано в системе. 

Пользователи в системе увидят его разово при любом следующем шаге диалога или при новом входе в систему (рис. 4). То есть, если пользователь ничего не делает в системе, то сообщение он не увидит.

Рис. 4. Сообщение в SAP системе.

После активации сообщение появится в списке в основном окне транзакции SM02 (рис. 5).

Рис. 5. Транзакция SM02 с одним активным сообщением.

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

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

Рис. 6. Удаление сообщения.

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

Обучение SAP Basis. Практика. Новый пакет заданий SAPADM_04.

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

В моей программе обучения SAP Basis появился новый пакет заданий - SAPADM_04.

Пакет SAPADM_04 состоит из этапов:

• 04.01. Установка дополнительной диалоговой инстанции SAP системы. Настройка логон групп.
• 04.02. Гомогенная копия SAP системы.
• 04.03. Создание манданта SAP системы через внутреннее копирование.
• 04.04. Настройка транспортной системы между двумя системами с собственными транспортными доменами.

В данном пакете 126 страниц заданий, описанных на русском языке, со снимками экранов SAP систем, с полезными ссылками на документацию и SAP ноты.

Пакет зависит только от базового пакета SAPADM_01.

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

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

Стоимость пакета: 6 000 рублей.

Страница с описанием программы и всеми пакетами - тут.

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

Диалоговые инстанции 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. Частные случаи можно посмотреть тут и тут.

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

Установка диалоговой инстанции для SAP ERP 6.0 SR3

SAP система имеет трезвенную архитектуру, состоящую из сервера базы данных (DB), сервера приложений и сервера презентации. Если мы не используем тонкого клиента, сервером презентации является рабочая станция пользователя с установленным клиентским местом SAP - SAP GUI. Сервер базы данных это СУБД того или иного вендора (ORACLE, MS SQL, DB2). В типовых случаях сервер базы данных не масштабируется. Сервер приложений в минимальной конфигурации состоит из центральной инстанции (CI), в состав которой обязательно входит Message Server (MS).

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

Рабочие процессы открывают соединение до процессов базы данных на сервер базы данных, а диспетчер диалоговой инстанции регистрирует себя у Message Server'а центральной инстанции.

В моем блоге я уже не раз в постах упоминал про диалоговые инстанции и особенности работы с ними:

• Установка дополнительных диалоговых инстанций.
• Дополнительные сервера приложений. Транзакции.
• Центральный системный журнал SAP.

Я написал инструкцию по установке ABAP диалоговой инстанции (zip-архив, 1022 Кб) для SAP ERP 6.0 SR3 на платформу Windows/ORACLE. Инструкция в формате pdf, количество страниц - 10.

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

Центральный системный журнал SAP

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

Но есть способ упростить себе жизнь. :) В транзакции SM21 можно выбрать другой вид системного журнала.

По-умолчанию, используется "Локальный журнал". При выборе пункта меню "Дистанционный журнал" или "Центральный системный журнал" на экране выбора появляется поле "Имя инстанции", в котором можно указать инстанцию любого сервера приложений системы.

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

В курсе ADM100 (SAP Web AS Administration I) указано, что центральный системный журнал возможен только на Unix-серверах. Еще один плюс в пользу этой операционной системы.

P.S. И не забудьте позаботиться о подарках родным, любимым и друзьям. ;)

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

Дополнительные сервера приложений. Транзакции.

Если в вашем "подворье" появились дополнительные диалоговые сервера, то придётся использовать ряд новых транзакций:

• SMLG - создание и администрирование logon групп,
• SM51 - список всех серверов приложений, с возможностью дистанционного входа, просмотра списка процессов и пользователей каждой инстанции,
• AL08 - список активных пользователей всех серверов приложений,
• SM66 - список активных процессов всех серверов приложений на одном экране.
  

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

Установка дополнительных диалоговых инстанций

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

Я хотел бы описать несколько моментов, которые будут интересны тем, кто еще не устанавливал дополнительный сервер приложений.
Итак, вот они:

1. Аппаратная платформа для установки дополнительного сервера приложений может отличаться от платформы основного сервера.
2. При установке дополнительного сервера приложений стоит использовать в качестве имени системы (SID) такое же имя, что и у основной системы. Часто это не отмечено в инструкции по установке, но без этого ничего не получится. Проверено. :-)
3. Часть файловых систем необходимо монтировать удаленно, например по NFS, с центрального сервера. Если платформы разные, то ядро сервера приложений SAP с центрального сервера для диалоговой инстанции не подойдет. Но можно создать на центральном сервере приложений, рядом с директорией основного ядра, директорию для ядра платформы, на которой работает дополнительный сервер приложений. И монтировать удаленно уже эту директорию. Это позволит центролизовать процесс обновления ядра SAP диалоговых инстанций.
4. Вам придется использовать logon group для входа в систему. В системе они настраиваются через транзакцию SMLG. Стоит отметить, что за балансировку отвечает message server, который работает на центральной инстанции, и делает он это автоматически. Коннект к системе осуществляется через message server. Сначала клиентское место SAP посылает запрос message server-у с указанием имени logon group, с которой он хочет работать. Message server определяет, какие сервера входят в данную logon group, выбирает наименее загруженный и посылает его координаты клиенту. Клиент подключается уже к нему напрямую и весь сеанс работает только с ним.
5. На клиентской машине надо прописать координаты message server-а в файле Drive:/windir/system32/drivers/etc/services. Прочтите перед этим SAP note # 52959. Обратите внимание на важное замечание - оставлять пустую строку в конце данного файла.
6. Очень удобно администрировать записи message server-ов, строк SAP router, записей коннекта в SAP Logon через служебные файлики sapmsg.ini, saproute.ini, saplogon.ini. Данные файлики лежат в директории Drive:/windir/. Подробнее о формате файлов читайте в SAP note # 38119.

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

И с наступлением настоящей весны! :)

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