В третьем методе используется
Какой из трех методов будет оптимальным, зависит от приложения; невозможно произвольно выбрать метод по желанию.
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.
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии