Книга: SAP R/3 Системное администрирование
13.1. Адреса назначения RFC
13.1. Адреса назначения RFC
Многие соединения/связи между двумя системами SAP R/3 или системой SAP R/3 и внешней системой основываются на протоколе интерфейса SAP — вызове удаленной функции (RFC — Remote Function Call). С помощью этого протокола приложения могут вызывать функции АВАР в системе SAP R/3, а системы SAP R/3 — внешние приложения (см. главу 1). Функции RFC делаются доступными для внешних программ через динамические библиотеки.
RFC вызывает предварительно определенный модуль функций в партнерской системе; вызывающая программа является клиентом RFC, а «отвечающая» вызванная система — сервером RFC (см. рис. 13.1).
Рис. 13.1. Распределение задач на различные системы
В среде SAP RFC предлагает интерфейс CPI-C, реализованный SAP.
Адреса назначения RFC
Чтобы полностью интегрировать систему SAP R/3 в существующую системную инфраструктуру, предоставленные соединения RFC должны быть идентифицированы как адреса назначения RFC. Часть этого определения делается автоматически, когда система SAP R/3 конфигурируется в инфраструктуре. Например, это включает соединения RFC, требуемые для системы управления транспортом (TMS, см. главу 5), которые создаются, когда система SAP R/3 интегрируется в области транспорта. Во время установки системы SAP R/3 также генерируются адреса назначения RFC для всех относящихся к делу серверов приложений; но зачастую необходимо создавать дополнительные адреса назначения. Типичными примерами из области системного администрирования являются соединения RFC для:
? Копирования удаленного клиента (см. главу 7)
? Настройки центрального управления пользователями (CUA, см. главу 8)
? Мониторинга удаленных систем SAP R/3 с помощью Alert Monitor (см. главу 16)
Чтобы определить адрес назначения RFC, все данные, необходимые для коммуникации с партнерской системой, компилируются с логическим именем. Устанавливается тип коммуникации. Заданное соединение RFC можно использовать любой программой; оно не присваивается какой-то определенной функции или определенному клиенту.
Соединения RFC всегда являются однонаправленными.
Каждая из коммуникационных пар, упомянутых выше, реализуется с помощью определенного типа соединения. Параметры, необходимые для создания нового адреса назначения RFC, зависят от типа соединения.
Таблица 13.1. Типы соединений для адреса назначения RFC
Тип | Описание | Требуемые данные |
1 | Соединение с сервером приложений с той же самой базой данных | нет |
3 | Соединение с системой SAP R/3 | Целевая машина и системный номер |
2 | Соединение с системой SAP R/3 | нет |
Т | Запуск внешней программы через TCP/IP | Зависит от типа активации Start: имя хоста и путь доступа программы Registration: ID программы |
L | Ссылочная запись (указывает на другой адрес назначения) | Адрес назначения RFC, для которого создается псевдоним |
S | Запуск внешней программы с помощью SNA или АРРС | нет |
X | RFC через специальные драйверы подпрограммы АВАР/4 | драйвер АВАР/4 |
M | Соединение CMC | нет |
В качестве примера рассмотрим определение нового соединения между двумя системами SAP R/3, «KLU» и «ELU».
1. Сначала с помощью ?RFC Administration выводится список всех известных адресов назначения RFC и сортируется согласно типу соединения (см. рис. 13.2).
Рис. 13.2. Начальный экран управления адресом назначения RFC
2. Щелкните на Create, чтобы открыть поле ввода для нового соединения RFC.
3. Введите логическое имя соединения в поле RFC destination. Необходимо отметить, что после создания этого имени, его невозможно будет изменить.
4. В зависимости от выбранного типа соединения экран автоматически расширится, чтобы включить необходимые поля ввода. На рис. 13.3 показан шаблон для записи данных для соединения RFC с другой системой SAP R/3 (тип соединения 3).
5. Результатом активации параметра трассировки будет подробная запись в файлы на уровне операционной системы выполнения всех программ, использующих это соединение RFC (см. раздел 15.5). Эти журналы можно анализировать с посылающей или принимающей системы с помощью либо программы отчета RSRFCTRC, либо ?RFC Administration • RFC • Display trace.
Рис. 13.3. Создание нового адреса назначения RFC
6. Введите Target host в качестве имени хоста или IP-адрес и System Number инстанции на этой машине.
7. Обычно для соединения RFC необходимо ввести язык регистрации, целевого клиента, пользователя целевой системы и пароль пользователя. Здесь возможны различные варианты:
- Явный ввод всех данных в разделе Logon. Чтобы избежать неправомочного использования, здесь должен использоваться пользователь типа communication.
- Использование текущего пользователя. При таком подходе текущий пользователь должен иметь такие же данные пользователя на целевом клиенте.
- Если в разделе Logon не вводятся никакие данные, то данные для регистрации запрашиваются с помощью всплывающего окна, когда используется соединение RFC. Этот метод не подходит для фоновой обработки.
- Если локальная система определена как Trusted system на цели адреса назначения RFC, то не требуется вводить никакие идентификационные данные. Можно создать доверительные отношения между системами SAP R/3 с помощью ?Trusted systems или из ?RFC administration с помощью RFC • Trusted systems или Trusting systems.
- Когда создается соединение RFC с удаленной системой, то предоставленные для соединения данные регистрации используются для авторизации его на удаленной системе. Назначение является статическим. Если, например, пароль пользователя на удаленной системе изменяется, то необходимо проверить определения соединений RFC.
8. Проверьте соединение с помощью Test connection, чтобы избежать проблем в последующем. Обратите внимание на то, что, выполняя ping таким образом, можно проверить только физическую доступность сервера.
В обзоре определенных соединений SAP R/3 (см. рис. 13.2) можно также видеть записи, созданные во время конфигурации TMS. Они всегда начинаются с кода «TMSADM». Для соединений RFC между системами SAP R/3 используется соединение типа 3.
Группы серверов
При определении соединений RFC вместо отдельной целевой машины можно использовать также имена группы серверов приложений. Необходимо, однако, сгенерировать их перед этим с помощью ?RFC administration • RFC • RFC groups или ?Maintenance of Server Groups. Преимущество этого метода заключается в том, что при установлении соединения из группы прикладных серверов выбирается машина с наименьшей нагрузкой, поэтому автоматически происходит распределение нагрузки. Этот механизм используется, например, когда распараллеливают копию большого клиента (см. главу 7). Можно управлять распределением нагрузки в группах серверов, настраивая предварительно определенные параметры ресурсов. Одним из важных параметров является число рабочих процессов, которые должны оставаться свободными.
Соединения TCP/IP
Определение других спецификаций для соединений RFC делается таким же образом. Данные, которые должны вводиться, различаются в зависимости от типа. Для адреса назначения RFC для выполнения внешних программ (соединение типа Т) необходимо сначала разграничить целевые серверы. Можно выбрать между сервером приложений, фронтальной рабочей станцией и явным хостом, который не используется текущей системой SAP R/3. Если внешняя программа должна выполняться на явном хосте, необходимо ввести имя или IP-адрес сервера при определении адреса назначения RFC. Для фронтальных рабочих станций и серверов приложений реальных систем SAP R/3 имена компьютеров уже стали известны во время регистрации в системе. Все серверы должны быть доступны через сеть без нового запроса имени пользователя и пароля. Внешняя запускаемая программа присваивается соединению RFC, которое будет определено.
Вместо явного запуска программы внешнего сервера RFC можно также зарегистрироваться на шлюзе SAP. Зарегистрированная программа ожидает затем запросы от различных систем SAP R/3, направленных на этот шлюз при вводе регистрации.
Логические соединения
Рекомендуется также использовать записи соединения типа L. Они называются логическими записями и ссылаются на другой адрес назначения RFC. Чтобы использовать этот механизм, сначала определяют адрес назначения RFC таким образом, который в конечном счете определяет только физическую цель — выбранный сервер. Затем создаются соединения типа L, ссылающиеся на эту запись. Соединения RFC типа L используют целевой сервер и тип соединения адреса назначения RFC, на который они ссылаются. Если нужно, логическое соединение RFC можно расширить, чтобы включить данные регистрации. Поэтому можно определять соединения RFC независимо друг от друга. Если, например, система SAP R/3 перемещается с одного сервера на другой, то потребуется только настроить адреса назначения RFC, которые используются как точки ссылки для определения соединений типа L.
Типы соединений RFC
Различают несколько типов коммуникации RFC, для которых можно задать дополнительные специальные конфигурационные параметры:
? Синхронный RFC
Для синхронного RFC вызывающая программа ожидает, пока закончится запрошенный шаг обработки на удаленной системе, и затем продолжает работать локально.
? Асинхронный RFC
Для асинхронного RFC вызывающая программа выдает запрос удаленной системе и немедленно продолжает работать локально. Запрошенный шаг обработки выполняется на удаленной системе независимо. Если удаленная система не может быть доступна во время вызова, асинхронные вызовы клиента RFC теряются.
? Транзакционный RFC
Транзакционный RFC также работает асинхронно, и, выделяя транзакционный идентификатор (ID), он гарантирует, что, если запрос послан несколько раз в связи с сетевыми проблемами, он обрабатывается только один раз. В противоположность асинхронному RFC при транзакционном RFC удаленная система не обязаны быть доступна в момент, когда клиентская программа RFC начинает вызов. Данные находятся в системе источника, пока целевая система не станет доступна. Программа отчета RSARFCSE вызывается в фоновом режиме с регулярными интервалами и пытается снова разместить неудачные запросы, идентифицированные их транзакционный ID.
? Упорядоченные (queued) RFC
Упорядоченный RFC является расширением транзакционного RFC. Для этого варианта запросы собираются в очередь и обрабатываются в транзакционном RFC только в том случае, если все предыдущие вызовы были обработаны соответствующим образом. Эта процедура гарантирует, что запросы обрабатываются в той последовательности, в которой они получены.
Характеристики определенных адресов назначения RFC можно адаптировать по данным, выводимым в определении соединения, с помощью Destination • TRFC options или ARFC options.
Коммуникационные партнеры не всегда могут получить доступ ко всем серверам приложений или серверу сообщений системы клиента RFC. Для присоединенных внешних программ при описании соединения часто требуется определить один конкретный сервер приложений. Если с внешней программой должны общаться и другие серверы приложений, можно определить сервер приложений, известный внешней программе, как шлюз для этого соединения RFC, чтобы вся коммуникация между клиентом RFC и внешней системой происходила через этот сервер приложений.
Мониторинг вызовов RFC
Транзакционные RFC контролируются с помощью ?tRFC Monitor, упорядоченные RFC с помощью ?qRFC Monitor Inbound, ?qRFC Monitor Outbound и ?qRFC Monitor.
- 13.1. Адреса назначения RFC
- 13.2. Поддержка прикладных связей (ALE)
- 13.2.1. Технические основы
- 13.2.2. Ограничение и ослабление соединения с помощью BAPI
- 13.2.3. Конфигурация
- 13.2.4. Мониторинг и анализ
- 13.3. Перенос данных
- 13.3.1. Пакетный ввод
- 13.3.2. Прямой ввод
- 13.3.3. Быстрый ввод/транзакция вызова
- 13.3.4. BAPI
- 13.3.5. Рабочая среда миграции унаследованных систем
- 13.3.6. Рабочая среда переноса данных
- 13.4. SAPconnect
- 13.5. Советы
- 13.6. Транзакции и пути доступа меню
- 13.7. Дополнительная документация
- 13.8. Контрольные вопросы
- Глава 2 Обнаружение адреса
- 5.21 IP-адреса, интерфейсы и множественное пребывание
- 3.6.1. Адресация в Linux
- 4.12.2. Переадресация
- Логика «от адресата»
- Обман MAC-адреса
- Глава 3 Как сразу «зацепить» адресата – начало
- Универсальная структура адреса сокета
- 1.3. Анонимные прокси-серверы: сокрытие IP-адреса и местонахождения
- 20.2. Широковещательные адреса
- 1.2. Анонимайзеры: сокрытие IP-адреса
- 17.3. IETF и процесс RFC-стандартизации