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

В третьем методе используется управление сообщениями SAP R/3 для генерации соответствующего IDoc. Отправка сообщения формирует часть стандартных сценариев во многих приложениях, таких как создание заказа на покупку. Сообщение можно напечатать или послать в электронной форме с помощью базовой службы управления сообщениями. Для этого метода рассматриваемое приложение делает записи сообщений типа ALE в таблице NAST. В зависимости от конфигурации записи могут анализироваться либо немедленно системой управления сообщениями SAP R/3, либо с периодическими интервалами с помощью программы отчета RSNAST00; IDoc генерируется из этих записей.

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

Структура IDoc

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

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

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

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

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

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

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

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

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

В этом разделе используется простой пример в качестве иллюстрации базового процесса для конфигурирования метода распространения 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. При присвоении имени логической системе необходимо, насколько возможно, придерживаться соглашения об именах CLNT. Это соглашение делает партнера очевидным просто по использованному имени. На рис. 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