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

Какой из трех методов будет оптимальным, зависит от приложения; невозможно произвольно выбрать метод по желанию.

Структура IDoc

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

Рис. 13.5. Структура IDoc

Каждый документ IDoc содержит одну управляющую запись, которая состоит из необходимой для переноса технической информации, такой как отправитель, получатель и тип сообщения. Управляющая запись определяет, какие операции обработки необходимы для переносимых данных. Реальные данные сообщения ALE идут после управляющей записи. Данные хранятся в различных сегментах согласно иерархии. Таблица кластеров определяет структуру сегмента и содержит данные, которые будут распространятся, в одном поле. Имя и структура этой таблицы зависит от версии SAP R/3. Третий компонент структуры IDoc является статусной информацией.

За определение обмена данных отвечает настройка (Customizing). Однако техническое определение соединений ALE обычно выполняет системный администратор SAP R/3, работая в тесном сотрудничестве с менеджером приложения или консультантом, отвечающим за прикладную сторону.

13.2.2. Ограничение и ослабление соединения с помощью BAPI

Если распределенный бизнес-процесс должен быть реализован с помощью удаленного вызова BAPI, также можно использовать механизм ALE.

Ограничение соединения

Вместо сообщения, созданного приложением в формате IDoc, посылается имя типа бизнес-объекта и метод, который обрабатывается синхронно на целевой системе. Синхронно запущенные методы должны выполнять только функции чтения или анализа.

Ослабление соединений

Чтобы запустить BAPI на целевой системе асинхронно, можно послать в виде IDoc необходимые параметры интерфейса. Получение этой информации запускает обработку предпочтительного метода на целевой системе с пересланными параметрами.

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).