В зависимости от приложения для генерации IDoc может использоваться один из трех методов (см. рис. 13.4).
Рис. 13.4.
Часто IDoc создается прямо из приложения. Прикладная программа либо заполняет внутреннюю таблицу в формате IDoc и переносит ее в службу ALE, либо использует BAPI с интерфейсом ALE.
Вторым методом является генерация IDoc из
В третьем методе используется
Какой из трех методов будет оптимальным, зависит от приложения; невозможно произвольно выбрать метод по желанию.
IDoc состоит из нескольких различных сегментов. Каждый сегмент имеет свое собственное определение структуры и документацию. Для хранения данных используется несколько таблиц на уровне базы данных. IDoc организован иерархически (см. рис. 13.5).
Рис. 13.5.
Каждый документ 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 называются
Рис. 13.6.
Произведенные изменения записываются в запросе 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. На следующем шаге необходимо задать поток данных в системной инфраструктуре.
Используя логические системные имена,