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

13.2.3. Конфигурация

В этом разделе используется простой пример в качестве иллюстрации базового процесса для конфигурирования метода распространения ALE между двумя системами SAP R/3. Задача состоит в том, чтобы настроить Central User Administration (CUA, см. главу 8). Основное внимание будет здесь сконцентрировано не на приложении, а на системном администраторе и его задачах.

Процедура состоит из следующих шагов:

1. Определение партнера в инфраструктуре ALE

2. Создание представления модели для метода распространения ALE

3. Генерация профиля партнера

Точкой входа для ?ALE Customizing является подузел Implementation Guide (см. главу 6).

Порядок задач более или менее соответствует последовательности их обработки. Описанные ниже настройки всегда основываются на экране ALE Customizing.

Организация логических систем

Партнеры коммуникации в сценарии ALE называются логическими системами и должны быть сначала определены. В инфраструктуре SAP логические системы реализуются клиентами. При настройке коммуникации ALE не имеет значения, будут ли партнеры физически находиться в одной или в разных системах SAP R/3. При присвоении имени логической системе необходимо, насколько возможно, придерживаться соглашения об именах <SID>CLNT<Client>. Это соглашение делает партнера очевидным просто по использованному имени. На рис. 13.7 показаны записи логической системы, которые могут быть доступны прямо из дерева Customizing при использовании символа выполнения.

Рис. 13.6. ALE Customizing (Basis Release 4.6C)

Произведенные изменения записываются в запросе Customizing, который должен присваиваться пользователю, если рассматриваемый клиент сконфигурирован с параметром Automatic recording of changes (автоматическая запись изменений, см. главу 7). Этот запрос можно использовать для переноса проверенных базовых настроек на другие системы. Настройки содержатся в общеклиентской таблице и поэтому должны производиться только один раз для каждой системы SAP R/3.

Рис. 13.7. Определение логических систем

Присвоение клиентов

На следующем шаге имена логических систем присваиваются выбранным клиентам соответствующей системы SAP R/3. Для этого запустите ?ALE Customizing и перейдите к деятельности Sending and receiving systems • Logical systems • Assign client to logical system или используйте ?Client maintenance (см. главу 7 и рис. 13.8).

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

Обслуживание модели распространения

Используя логические системные имена, модель распространения описывает партнеров коммуникации и посылаемые данные. Чтобы обеспечить наличие только одной активной версии модели для всех подходящих систем, она создается и поддерживается в одной системе. Для этого в ?ALE Customizing выберите ?Modeling and Implementing Business Processes • Maintain Distribution Model and Distribute Views • Create Model View или прямой подход ?Maintenance of Distribution Model • Create Model View. Введите подходящий короткий текст и техническое имя для планируемого представления модели (см. рис. 13.9).

Рис. 13.8. Присвоение логической системы клиенту

Рис. 13.9. Создание представления модели для Central User Administration

BAPI/тип сообщения

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

? Add message type

С помощью нового представления модели присвоенный типу сообщения IDoc должен быть послан удаленной системе.

? Add BAPI

С помощью нового представления модели должен быть активирован метод BAPI или доставлен с параметрами на удаленную систему.

В данном примере CUA посылающей логической системой является «ЕРА_001», а получающей логической системой — «EPACLNT001». Типы бизнес-объектов User и UserCompany (адрес компании) должны быть заполнены с помощью метода Clone (см. рис. 13.10).

Рис. 13.10. Описательные данные модели распространения

Фильтры

Объем пересылаемых данных можно сократить, определяя фильтры. При фильтрации типов сообщений, если ввести пару типа объекта/значение, сегменты IDoc и их подсегменты не пересылаются, если они содержат поле типа объекта, которое не имеет определенного значения. Фильтрация BAPI проверяет пары параметр/значение. Только если параметр соответствует заданному значению, BAPI будет создавать и распространять IDoc.

Специальные настройки

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

? Конфигурирование предварительно определенных бизнес-процессов ALE

? Конфигурирование распространения основных данных

? Конфигурирование синхронизации данных Customizing

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

Коммуникация

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

В каждой системе должно быть создано соединение RFC (см. раздел 13.2) с типом 3 (соединение с системой SAP R/3) для коммуникации между партнерами в группе ALE. В примере центрального управления пользователями адреса назначения RFC должны создаваться из центральной системы во всех дополнительных системах, а в зависимости от настроек параметра изменяемости также и в противоположном направлении (см. главу 8).

Если имя адреса назначения RFC соответствует имени логической получающей системы, дополнительные настройки могут генерироваться автоматически.

Профили партнеров

В следующем разделе ?Partner profiles в ALE Customizing описываются параметры для входящей и исходящей обработки для вовлеченных систем (см. раздел 13.11). После генерации профиля партнера этот раздел распространяется на все выбранные партнерские системы или, если задано только модельное представление без каких-либо явных имен партнеров, на всех партнеров в модельном представлении. При определении партнерского профиля в центральной системе в данном примере дополнительные системы являются партнерами.

Размер пакета и режим вывода задаются с помощью параметров вывода. Можно немедленно послать каждый сгенерированный IDoc получателю или собрать несколько IDoc в группу и послать их, когда группа будет заполнена. Недостатком нескольких небольших пакетов является то, что требуется устанавливать соединение с целевой системой и выполнять процедуру регистрации для каждого пакета. Этот подход может привести к деградации производительности. Однако если собирать документы IDoc и затем посылать их, то пул данных в посылающей и получающей системах может со временем различаться. Передача большого числа документов IDoc создает также пиковые нагрузки на получающей системе. Следовательно, необходимо найти разумный компромисс между этими подходами. Обычно SAP рекомендует собирать несколько документов IDoc и передавать их одним пакетом.

Настройки, задаваемые на получателе, относятся к управлению документами IDoc на получающей стороне. IDoc могут обрабатываться немедленно или в фоновом режиме. В типичных случаях можно обеспечить лучшую производительность, не обрабатывая входящие IDoc немедленно, а позже, когда нагрузка на систему ослабнет. Отложенная обработка означает также, что можно распараллелить входящие IDoc. После завершения определения необходимо сохранить его и сгенерировать партнерские профили. Порт и данные об обработке IDoc создаются автоматически как часть генерации партнерских профилей. Порт должен определяться вручную только в случае файлового интерфейса. Партнерские профили определяют, как управлять сообщениями при обработке ALE. Они зависят от типа партнера и от различных типов сообщений. На рис. 13.12 показан коммуникационный поток данных между логическими системами.

Рис. 13.11. Генерация партнерского профиля

Рис. 13.12. Технические настройки

Порт

Порт определяет тип соединения с партнером. Данные могут передаваться через tRFC с помощью последовательных файлов, с помощью CPI-C в систему SAP R/2 или через Интернет. Каждому порту присваивается уникальный номер.

Партнерские профили могут успешно генерироваться только тогда, когда имена соединений RFC согласованы с именами логических систем. Если это не так, необходимо определить партнерские профили вручную.

Чтобы обеспечить работу сделанных и сгенерированных настроек, можно выполнить функцию Check all partner profiles for consistency в ?IDoc Check, чтобы осуществить проверку на согласованность всех партнерских профилей.

Настройки модели распространения

Настройки распространения должны быть известны всем партнерским системам. Соответственно последний шаг распространяет настройки модели: ?Maintenance of distribution model • Edit • Model view • Distribute.

Этот шаг завершает определение соединения ALE.

Оглавление книги