Важнейшие преимущества ALE — это:
• Интеграция полуавтономных систем
• Лучшие входные интерфейсы, в сравнении с пакетной передачей данных (batch data communications, BDC) и вызовом транзакций (call transactions, СТ)
• Возможность коммуникации между различными версиями SAP
• Соединение с иными (не SAP) приложениями без нарушения данных и последовательности бизнес-действий
• Несинхронная интеграция компонентов бизнес-структуры, включая бизнес-компоненты, бизнес-объекты и BAPI.
Архитектура ALE
Основной принцип, стоящий за ALE — это гарантия полной интеграции SAP R/3. Каждое приложение является автономным и существует в распределенной среде со своим набором данных. Использование автономных систем подразумевает некоторую степень избыточности данных, а это предполагает, что данные должны быть распределены и синхронизированы во всей системе. Это достигается при помощи асинхронной коммуникации. Архитектура механизма сообщений ALE состоит из трех уровней.
Сервисы приложений
Этот уровень обеспечивает интерфейс ALE для отправления и приема сообщений, содержащих данные для/от R/3 или внешних систем. Эти сообщения содержат такую информацию, как сведения о получателе, типе передачи и типе обработки.
Сервисы дистрибуции
Этот уровень, способствующий интеграции бизнес-приложений, включает:
• Определение получателей на базе дистрибутивной модели
• Фильтрацию и перекодировку сообщений
• Сжатие сообщений для уменьшения объема передаваемой информации.
Сервисы коммуникации
Обмен сообщениями ALE происходит при помощи асинхронного удаленного вызова функции (RFC) или электронного обмена данными (Electronic Data Interchange, EDI). Для использования функции информационного поиска может быть применен синхронный RFC.
Компоненты ALE
В этом разделе перечислены компоненты ALE. Многие из них работают также и с интерфейсом EDI, который будет описан в следующем разделе.
Логическая модель
Логическое представление всей системы должно быть сконструировано, перед тем как распределенная и интегрированная система будет полностью внедрена в компании. Эта логическая модель, которую считают специфической разработкой SAP, определяет, какое приложение должно работать в определенной системе и как различные системы должны обмениваться данными. SAP предоставляет эталонную модель, в которой есть все возможные сценарии для распределенных приложений. Компания может разработать свою собственную модель на базе этой библиотеки сценариев.
Тип сообщений
Этот компонент применяется для обмена между различными системами. Тип сообщения определяет сообщение и устанавливает его отношение к типу промежуточного документа (IDoc). MATMAS, например, является стандартным типом сообщения для основных записей материалов. ALE поддерживает более 200 типов сообщений.
Промежуточные документы и их типы
Тип IDoc представляет структуру и формат данных для типа сообщения. IDoc состоит из следующих записей:
• Управляющие записи: однозначно определяют IDoc через тип IDoc, тип сообщения, отправителя и получателя.
• Записи данных: содержат данные приложений. Каждая запись содержит раздел с описанием содержания данных. IDoc может состоять из одной или более записей данных. Количество данных определяется в каждом конкретном случае и зависит от структуры сегмента, идентификации, последовательности и иерархии. При обработке исходящих документов функциональные модули ALE/EDI заполняют эти сегменты данными приложений.
• Записи статуса: отслеживают производственные стадии, через которые прошел IDoc. Здесь также хранится информация об отметках времени и даты соответствующего статуса. IDoc может иметь одну или более записей статуса.
Клиентская модель распределения
Эта модель применима только к ALE и описывает фактическое распределение приложений. Она характеризует поток сообщений между распределенными логическими системами. Она также устанавливает критерии определения правильного получателя для каждого отдельного сообщения. Модель распределения между клиентами распространяется из центральной системы во все участвующие системы.
Объект фильтра и его тип
Тип объекта фильтра используется для установления критерия отбора для типа сообщений текущей логической системы. В случае, если это ведущий тип сообщений у клиента, объектом фильтра может быть код компании. Сложные объекты фильтра с разными значениями для одного типа сообщений могут быть связаны с одной и той же логической системой.
Читать дальше