Вивек Кале - Внедрение SAP R/3: Руководство для менеджеров и инженеров
Бизнес-объекты SAP инкапсулируют данные R/3 и бизнес-процессы, скрывая структуру и детали исполнения лежащих в основе данных. Это достигается за счет того, что модули бизнес-объектов SAP имеют многоуровневую структуру, состоящую из:
Ядра: этот внутренний слой представляет принадлежащие объекту данные.
Уровня целостности: на этом уровне представлена бизнес-логика объекта, которая состоит из делового регламента, а также ограничений на объем и границ, применяемых к бизнес-объектам SAP.
Уровня интерфейса: этот уровень обеспечивает независимое от платформы описание внедрения бизнес-объекта SAP для внешних систем. Это достигается через BAPI.
Уровня доступа: этот уровень идентифицирует и определяет технологии, которые дают внешним системам доступ к уровню ядра, то есть к данным объекта. Это могут быть COM/DCOM, RFC(Remote Function Call) и другие технологии.
Рисунок 19.4 показывает разные уровни бизнес-объекта.
Интерфейс программирования бизнес-приложений
Business Programming Interfaces (BAPI) — это методы или процедуры, которые присваиваются бизнес-объекту. Они являются инкапсуляциями различных операций, которые могут быть проделаны с этими бизнес-объектами. Например, в случае со счетом-фактурой покупателя, различные BAPI дают возможность выполнить проверку достоверности (ратификацию), подсчет налогов, стоимости перевозки и т. п.; определение находящихся на рассмотрении и просроченных счетов-фактур; проверку оплаты, анализ амортизации и т. д. Стандартная лицензия SAP уже имеет библиотеку из более чем 200 BAPI, которая регулярно пополняется.
Репозитарий бизнес-объектов (BOR) хранит и управляет бизнес-объектами и соответствующими им BAPI как отдельными единицами. Это практическое проявление бизнес-компонентов на самом низком уровне деятельности. SAP уже имеет библиотеку из более чем 200 BAPI, которая регулярно пополняется. В настоящий момент BAPI внедряются в качестве функциональных модулей, которые создаются и управляются в Построителе функций (Function Builder). BAPI имеют следующие характеристики:
• Они связаны с бизнес-объектами SAP
• Они поддерживают протокол RFC (Remote Function Call) для сообщения с внешними системами
• Они вызывают программы через диалоговые экраны.
BAPI обеспечивают важные преимущества объектной ориентации, такие как:
• Создание и внедрение на любом компьютерном языке
• Поддержка стандартных интерфейсов
• Совместимость с различными технологиями коммуникации
• Автономное усовершенствование и техническое обслуживание. Бизнес-объекты с соответствующими им BAPI точно указывают направление будущих усовершенствований в системе SAP.
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 заполняют эти сегменты данными приложений.
