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

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.

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