SAP R/3 Системное администрирование

Типы соединений 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.2. Поддержка прикладных связей (ALE)

Нередко бизнес-процессы на предприятии невозможно представить одной центральной системой. Очень часто причиной этого является деление информационного потока между относительно независимыми подразделениями компании. Другой причиной может быть техническое узкое место, которое возникает в связи с размером одной центральной системы. Вопросы безопасности также могут играть свою роль. Кроме того, может также понадобиться общение с системами внешних программ (например, системой управления хранилищем данных). Если по одной или нескольким причинам невозможно создать систему с центральной конфигурацией, но требуется постоянное согласование данных или поток сообщений, можно попробовать соединить систему с помощью Поддержки прикладных связей (ALE). Учитывая сложность ALE как с технической, так и с прикладной точки зрения, в следующих разделах рассматриваются только основы этой технологии. Наиболее важные моменты работы ALE описаны для будущих системных администраторов.

13.2.1. Технические основы

Поддержка прикладных связей (ALE — Application Link Enabling) является методом и технологией в SAP R/3 для поддержки управляемого деятельностью обмена сообщениями между слабо связанными системами. ALE содержит сценарии деятельности и модули функций, которые позволяют передавать и согласовывать данные системы SAP R/3 без специального участия пользователя.

Вопросы реализации

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

► Какие процессы должны быть представлены в разных системах?

► Какие объекты вовлечены в эти процессы?

► Какие данные должны рассматриваться на различных системах?

► В каком формате должны быть доступны данные, и какая информация должна передаваться для форматирования?

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

► Какую форму будет принимать поток данных между вовлеченными системами?

Технология ALE интегрирована одновременно в приложения и в настройку (Customizing). Она предоставляет ряд служб распространения, и информация может посылаться отправителю в ходе обработки. Часто происходит не только перенос данных: последующие действия также могут запускаться в целевой системе.

Данные обмена

С точки зрения SAP R/3 передаваемые данные включают:

► Данные транзакций — Данные приложений и данные транзакций

► Основные данные — Например, основные данные о заказчиках или материалах

► Данные настройки — Данные, которые обеспечивают однородное, глобальное представление ALE

Данные могут передаваться между системами SAP R/3, между системами SAP R/3 и SAP R/2 и между SAP R/3 и внешними системами. Основным фокусом реализованных сценариев является распространение между системами SAP R/3. Это распространение не зависит от версии системы в максимально возможной степени, что означает, что нет необходимости обновлять все системы SAP R/3 в системной инфраструктуре в одно время. Системы связаны слабыми синхронными (чтение) или асинхронными (изменение) коммуникациями. Технические характеристики соединения задаются в определении порта (port definition). Типы портов соответствуют выбранным методам коммуникации. В настоящее время используются файловые интерфейсы, RFC, CPI-C и интерфейсы Интернета.

Тип сообщения

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

Типы IDoc

Реальная информация может посылаться с помощью промежуточного документа (IDoc — Intermediate Document). Тип IDoc, содержащий описание структуры данных, присваивается типу сообщения как контейнер для данных, которые будут пересылаться. Специальный тип IDoc существует для всех прикладных областей, которые должны готовить данные для обмена. Посылаемые данные, включая таблицы и поля, должны определяться на основе типов IDoc. Когда тип IDoc заполнен конкретными данными в соответствии с правилами структуры, он называется IDoc (промежуточный документ).

Генерация IDoc