Application Link Enabling

We use cookies. Read the Privacy and Cookie Policy

Application Link Enabling

Существует тенденция, по которой различные организационные единицы функционируют как полуавтономные структуры. Отношения внутри компании построены по тем же принципам, что и отношения между производителем и покупателем. С другой стороны, возрастает интеграция процессов во всей компании, таких как закупки, продажи и распределение, включая производство и бухгалтерский учет.

Таким образом, современное предприятие одновременно нуждается:

• в высоком уровне интеграции между различными прикладными системами

• в комплексе самостоятельных систем, которые можно внедрять по отдельности. Application Link Enabling (ALE) является базовым компонентом бизнес-структуры SAP, при помощи которого осуществляется обмен и интеграция компонентов программного обеспечения SAP и других производителей. Стандартная лицензия SAP имеет заранее скомпонованный набор бизнес-процессов ALE, наряду с механизмами для развития и тестирования приложений ALE.

Ниже представлены типичные сценарии распределения, для которых необходимы специальные схемы управления:

• Централизованные продажи и планирование производства и децентрализованное планирование необходимых материалов (Material Requirements Planning, MRP)

• Централизованная логистика и децентрализованное управление складами

• Централизованная финансовая система и децентрализованная система логистики

• Централизованный анализ прибыльности и децентрализованное ценообразование.

Традиционных решений для удовлетворения этих требований явно недостаточно. Увеличение централизации систем лишь усугубляет проблемы производительности, времени реакции, поддержки, модернизации и обновлений, а также эффективности затрат. Другое традиционное решение — использование распределенной базы данных — сталкивается с проблемами защиты и целостности (например, при репликации), а также требует гигантских накладных расходов на коммуникацию и обработку данных.

ALE, которая стала доступна, начиная с выпуска R/3 3.0, представила концепцию работы и управления для распределенных приложений и баз данных. ALE позволяет внедрять слабосвязанные кластеры приложений, которые работают полуавтономно и имеют свои собственные базы данных. Это возможно благодаря контролируемому обмену информационными сообщениями, наряду с обеспечением взаимодействия между слабосвязанными системами приложений. Интеграция различных приложений достигается при использовании синхронной и асинхронной коммуникации, а не центральной базы данных.

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

Объект фильтра и его тип

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

Классификационные списки

Классификационные списки — это другой тип объектов фильтра, основанный на системе классификации SAP, который может быть применен только к основным данным о материалах, клиентах и производителях После того, как список составлен, он используется для создания объекта фильтра для типа сообщения, связанного с логической системой.

Указатель изменений

ALE имеет обширные возможности улавливать изменения в основных данных и рассылать их через интерфейс IDoc. Это используется для синхронизации более распределенных систем по отношению к основным данным.

Порты

Это логическое представление коммуникации, которое применяется ALE (например R/2, tRFC, File, Интернет) для отправления IDoc. EDI использует большинство портов на базе файлов.

Контроль сообщений и тип вывода

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

Коды операций

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

Профиль партнеров

Профиль партнеров определяет систему, используемую для создания сообщений. Существует четыре типа профилей: KU — для клиентов, LI — для производителей, В — для банков, LS — для логических систем. ALE использует только LS, остальные три — для интерфейсов EDI. Профили партнеров содержат все необходимые параметры, включая типы сообщений, типы IDoc, функции партнеров, коды обработки, идентификаторы приложений, функции сообщений, типы вывода и порты.

Сценарии ALE

Постоянный обмен данными между распределенными системами обеспечивает общую синхронизацию систем. Существуют следующие типы коммуникационных данных:

• Контрольные данные: включают данные настройки R/3 IMG, контрольные данные сценариев распределения IMG и контрольные данные модели распределения между клиентами.

• Основные данные: содержат информацию о материале, клиенте, продавце, счетах Главной книги, центрах учета затрат, виде затрат, типе операции, единицах измерения и соответствующем тарифе.

• Данные транзакции: счета-фактуры, заказ клиента, заказ на поставку, уведомление о перевозке и т. п.

В качестве примера возьмем сценарий ALE-распределения основных данных между разветвленными системами R/3, показанный на рисунке 19.5. Например, центральный офис несет ответственность за основные данные о материалах. Допустим, что они рассредоточены в системах двух разных заводов: 5001 и 6001. ALE дает возможность отфильтровывать и рассылать только важную информацию в соответствующие системы. Типом объекта фильтра, используемого для сообщения MATMAS (material master — основные данные о материалах) является WERKS (наименование завода). Как упоминалось ранее, данные о материалах полностью передаются из центрального офиса в соответствующие системы, после чего нужно отслеживать только изменения в информации и рассылать их в заводские системы.

Рис. 19.5. Передача IDoc при помощи ALE.