ГЛАВА 13 РАСПРОСТРАНЕНИЕ И ПЕРЕНОС ДАННЫХ

ГЛАВА 13

РАСПРОСТРАНЕНИЕ И ПЕРЕНОС ДАННЫХ

Для создания межсистемных бизнес-процессов могут использоваться различные способы поиска решения, способствуя тем самым открытому обмену данными. В зависимости от требований можно выбрать слабое или тесное взаимодействие и синхронную или асинхронную распределенную обработку шагов процесса.

Стандартным сценарием распределенного приложения является Поддержка прикладных связей (ALE — Application Link Enabling). Для технической реализации должны быть определены структуры данных и методы коммуникации. В качестве усовершенствования традиционных процедур реализованы также новые интерфейсы с помощью технологии BAPI.

BAPI

Интерфейс программирования бизнес-приложений (BAPI — Business Application Programming Interface) предоставляет внутренний, а также внешний доступ к данным и бизнес-процессам, определенным в системе SAP R/3. Нижележащими базовыми компонентами этого объектно-ориентированного подхода являются типы бизнес-объектов, которые представляют объекты реального мира в виде программного обеспечения. Стандартные примеры включают план счетов, торговый заказ или закупочную организацию. Эти типы объектов могут быть доступны только с помощью стандартизованных, независимых от платформы методов, которые не зависят также от версии и открыты, — BAPI.

Все типы бизнес-объектов и соответствующие BAPI хранятся в репозитории бизнес-объектов (BOR — Business Object Repository) системы SAP R/3. С помощью ?BAPI Explorer можно получить обзор определенных типов объектов, их методах и характеристиках и сделать изменения. Объекты являются конкретными экземплярами типа объектов.

Кроме специфических методов объектов, некоторые BAPI доступны для всех типов объектов, а именно:

Технически методы реализуются как модули функций. Например, можно использовать BAPI для соединения с внешними программами, а метод распространения ALE — для соединения с бизнес-процессами за пределами системы.

13.1. Адреса назначения RFC

Многие соединения/связи между двумя системами SAP R/3 или системой SAP R/3 и внешней системой основываются на протоколе интерфейса SAP — вызове удаленной функции (RFC — Remote Function Call). С помощью этого протокола приложения могут вызывать функции АВАР в системе SAP R/3, а системы SAP R/3 — внешние приложения (см. главу 1). Функции RFC делаются доступными для внешних программ через динамические библиотеки.

RFC вызывает предварительно определенный модуль функций в партнерской системе; вызывающая программа является клиентом RFC, а «отвечающая» вызванная система — сервером RFC (см. рис. 13.1).

Рис. 13.1. Распределение задач на различные системы

В среде SAP RFC предлагает интерфейс CPI-C, реализованный SAP.

Адреса назначения RFC

Чтобы полностью интегрировать систему SAP R/3 в существующую системную инфраструктуру, предоставленные соединения RFC должны быть идентифицированы как адреса назначения RFC. Часть этого определения делается автоматически, когда система SAP R/3 конфигурируется в инфраструктуре. Например, это включает соединения RFC, требуемые для системы управления транспортом (TMS, см. главу 5), которые создаются, когда система SAP R/3 интегрируется в области транспорта. Во время установки системы SAP R/3 также генерируются адреса назначения RFC для всех относящихся к делу серверов приложений; но зачастую необходимо создавать дополнительные адреса назначения. Типичными примерами из области системного администрирования являются соединения RFC для:

? Копирования удаленного клиента (см. главу 7)

? Настройки центрального управления пользователями (CUA, см. главу 8)

? Мониторинга удаленных систем SAP R/3 с помощью Alert Monitor (см. главу 16)

Чтобы определить адрес назначения RFC, все данные, необходимые для коммуникации с партнерской системой, компилируются с логическим именем. Устанавливается тип коммуникации. Заданное соединение RFC можно использовать любой программой; оно не присваивается какой-то определенной функции или определенному клиенту.

Соединения RFC всегда являются однонаправленными.

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

Таблица 13.1. Типы соединений для адреса назначения RFC

В качестве примера рассмотрим определение нового соединения между двумя системами SAP R/3, «KLU» и «ELU».

1. Сначала с помощью ?RFC Administration выводится список всех известных адресов назначения RFC и сортируется согласно типу соединения (см. рис. 13.2).

Рис. 13.2. Начальный экран управления адресом назначения RFC

2. Щелкните на Create, чтобы открыть поле ввода для нового соединения RFC.

3. Введите логическое имя соединения в поле RFC destination. Необходимо отметить, что после создания этого имени, его невозможно будет изменить.

4. В зависимости от выбранного типа соединения экран автоматически расширится, чтобы включить необходимые поля ввода. На рис. 13.3 показан шаблон для записи данных для соединения RFC с другой системой SAP R/3 (тип соединения 3).

5. Результатом активации параметра трассировки будет подробная запись в файлы на уровне операционной системы выполнения всех программ, использующих это соединение RFC (см. раздел 15.5). Эти журналы можно анализировать с посылающей или принимающей системы с помощью либо программы отчета RSRFCTRC, либо ?RFC Administration • RFC • Display trace.

Рис. 13.3. Создание нового адреса назначения RFC

6. Введите Target host в качестве имени хоста или IP-адрес и System Number инстанции на этой машине.

7. Обычно для соединения RFC необходимо ввести язык регистрации, целевого клиента, пользователя целевой системы и пароль пользователя. Здесь возможны различные варианты:

- Явный ввод всех данных в разделе Logon. Чтобы избежать неправомочного использования, здесь должен использоваться пользователь типа communication.

- Использование текущего пользователя. При таком подходе текущий пользователь должен иметь такие же данные пользователя на целевом клиенте.

- Если в разделе Logon не вводятся никакие данные, то данные для регистрации запрашиваются с помощью всплывающего окна, когда используется соединение RFC. Этот метод не подходит для фоновой обработки.

- Если локальная система определена как Trusted system на цели адреса назначения RFC, то не требуется вводить никакие идентификационные данные. Можно создать доверительные отношения между системами SAP R/3 с помощью ?Trusted systems или из ?RFC administration с помощью RFC • Trusted systems или Trusting systems.

- Когда создается соединение RFC с удаленной системой, то предоставленные для соединения данные регистрации используются для авторизации его на удаленной системе. Назначение является статическим. Если, например, пароль пользователя на удаленной системе изменяется, то необходимо проверить определения соединений RFC.

8. Проверьте соединение с помощью Test connection, чтобы избежать проблем в последующем. Обратите внимание на то, что, выполняя ping таким образом, можно проверить только физическую доступность сервера.

В обзоре определенных соединений SAP R/3 (см. рис. 13.2) можно также видеть записи, созданные во время конфигурации TMS. Они всегда начинаются с кода «TMSADM». Для соединений RFC между системами SAP R/3 используется соединение типа 3.

Группы серверов

При определении соединений RFC вместо отдельной целевой машины можно использовать также имена группы серверов приложений. Необходимо, однако, сгенерировать их перед этим с помощью ?RFC administration • RFC • RFC groups или ?Maintenance of Server Groups. Преимущество этого метода заключается в том, что при установлении соединения из группы прикладных серверов выбирается машина с наименьшей нагрузкой, поэтому автоматически происходит распределение нагрузки. Этот механизм используется, например, когда распараллеливают копию большого клиента (см. главу 7). Можно управлять распределением нагрузки в группах серверов, настраивая предварительно определенные параметры ресурсов. Одним из важных параметров является число рабочих процессов, которые должны оставаться свободными.

Соединения TCP/IP

Определение других спецификаций для соединений RFC делается таким же образом. Данные, которые должны вводиться, различаются в зависимости от типа. Для адреса назначения RFC для выполнения внешних программ (соединение типа Т) необходимо сначала разграничить целевые серверы. Можно выбрать между сервером приложений, фронтальной рабочей станцией и явным хостом, который не используется текущей системой SAP R/3. Если внешняя программа должна выполняться на явном хосте, необходимо ввести имя или IP-адрес сервера при определении адреса назначения RFC. Для фронтальных рабочих станций и серверов приложений реальных систем SAP R/3 имена компьютеров уже стали известны во время регистрации в системе. Все серверы должны быть доступны через сеть без нового запроса имени пользователя и пароля. Внешняя запускаемая программа присваивается соединению RFC, которое будет определено.

Вместо явного запуска программы внешнего сервера RFC можно также зарегистрироваться на шлюзе SAP. Зарегистрированная программа ожидает затем запросы от различных систем SAP R/3, направленных на этот шлюз при вводе регистрации.

Логические соединения

Рекомендуется также использовать записи соединения типа L. Они называются логическими записями и ссылаются на другой адрес назначения RFC. Чтобы использовать этот механизм, сначала определяют адрес назначения RFC таким образом, который в конечном счете определяет только физическую цель — выбранный сервер. Затем создаются соединения типа L, ссылающиеся на эту запись. Соединения RFC типа L используют целевой сервер и тип соединения адреса назначения RFC, на который они ссылаются. Если нужно, логическое соединение RFC можно расширить, чтобы включить данные регистрации. Поэтому можно определять соединения RFC независимо друг от друга. Если, например, система SAP R/3 перемещается с одного сервера на другой, то потребуется только настроить адреса назначения RFC, которые используются как точки ссылки для определения соединений типа L.

Типы соединений RFC

Различают несколько типов коммуникации RFC, для которых можно задать дополнительные специальные конфигурационные параметры:

? Синхронный RFC

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

? Асинхронный RFC

Для асинхронного RFC вызывающая программа выдает запрос удаленной системе и немедленно продолжает работать локально. Запрошенный шаг обработки выполняется на удаленной системе независимо. Если удаленная система не может быть доступна во время вызова, асинхронные вызовы клиента RFC теряются.

? Транзакционный RFC

Транзакционный RFC также работает асинхронно, и, выделяя транзакционный идентификатор (ID), он гарантирует, что, если запрос послан несколько раз в связи с сетевыми проблемами, он обрабатывается только один раз. В противоположность асинхронному RFC при транзакционном RFC удаленная система не обязаны быть доступна в момент, когда клиентская программа RFC начинает вызов. Данные находятся в системе источника, пока целевая система не станет доступна. Программа отчета RSARFCSE вызывается в фоновом режиме с регулярными интервалами и пытается снова разместить неудачные запросы, идентифицированные их транзакционный ID.

? Упорядоченные (queued) RFC

Упорядоченный RFC является расширением транзакционного RFC. Для этого варианта запросы собираются в очередь и обрабатываются в транзакционном RFC только в том случае, если все предыдущие вызовы были обработаны соответствующим образом. Эта процедура гарантирует, что запросы обрабатываются в той последовательности, в которой они получены.

Характеристики определенных адресов назначения RFC можно адаптировать по данным, выводимым в определении соединения, с помощью Destination • TRFC options или ARFC options.

Коммуникационные партнеры не всегда могут получить доступ ко всем серверам приложений или серверу сообщений системы клиента RFC. Для присоединенных внешних программ при описании соединения часто требуется определить один конкретный сервер приложений. Если с внешней программой должны общаться и другие серверы приложений, можно определить сервер приложений, известный внешней программе, как шлюз для этого соединения RFC, чтобы вся коммуникация между клиентом RFC и внешней системой происходила через этот сервер приложений.

Мониторинг вызовов RFC

Транзакционные RFC контролируются с помощью ?tRFC Monitor, упорядоченные RFC с помощью ?qRFC Monitor Inbound, ?qRFC Monitor Outbound и ?qRFC Monitor.

13.2. Поддержка прикладных связей (ALE)

Нередко бизнес-процессы на предприятии невозможно представить одной центральной системой. Очень часто причиной этого является деление информационного потока между относительно независимыми подразделениями компании. Другой причиной может быть техническое узкое место, которое возникает в связи с размером одной центральной системы. Вопросы безопасности также могут играть свою роль. Кроме того, может также понадобиться общение с системами внешних программ (например, системой управления хранилищем данных). Если по одной или нескольким причинам невозможно создать систему с центральной конфигурацией, но требуется постоянное согласование данных или поток сообщений, можно попробовать соединить систему с помощью Поддержки прикладных связей (ALE). Учитывая сложность ALE как с технической, так и с прикладной точки зрения, в следующих разделах рассматриваются только основы этой технологии. Наиболее важные моменты работы ALE описаны для будущих системных администраторов.

13.2.1. Технические основы

Поддержка прикладных связей (ALE — Application Link Enabling) является методом и технологией в SAP R/3 для поддержки управляемого деятельностью обмена сообщениями между слабо связанными системами. ALE содержит сценарии деятельности и модули функций, которые позволяют передавать и согласовывать данные системы SAP R/3 без специального участия пользователя.

Вопросы реализации

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

? Какие процессы должны быть представлены в разных системах?

? Какие объекты вовлечены в эти процессы?

? Какие данные должны рассматриваться на различных системах?

? В каком формате должны быть доступны данные, и какая информация должна передаваться для форматирования?

? Какая технология передачи подходит для удовлетворения требований? Критерием здесь является частота, необходимость возврата информации, быстрота и т.д.

? Какую форму будет принимать поток данных между вовлеченными системами?

Технология ALE интегрирована одновременно в приложения и в настройку (Customizing). Она предоставляет ряд служб распространения, и информация может посылаться отправителю в ходе обработки. Часто происходит не только перенос данных: последующие действия также могут запускаться в целевой системе.

Данные обмена

С точки зрения SAP R/3 передаваемые данные включают:

? Данные транзакций — Данные приложений и данные транзакций

? Основные данные — Например, основные данные о заказчиках или материалах

? Данные настройки — Данные, которые обеспечивают однородное, глобальное представление ALE

Данные могут передаваться между системами SAP R/3, между системами SAP R/3 и SAP R/2 и между SAP R/3 и внешними системами. Основным фокусом реализованных сценариев является распространение между системами SAP R/3. Это распространение не зависит от версии системы в максимально возможной степени, что означает, что нет необходимости обновлять все системы SAP R/3 в системной инфраструктуре в одно время. Системы связаны слабыми синхронными (чтение) или асинхронными (изменение) коммуникациями. Технические характеристики соединения задаются в определении порта (port definition). Типы портов соответствуют выбранным методам коммуникации. В настоящее время используются файловые интерфейсы, RFC, CPI-C и интерфейсы Интернета.

Тип сообщения

Семантика сообщения, которое будет передано, на удаленную систему описывается типом сообщения (message type). Главные данные материалов, которые хранятся в центральной исходной системе и которые, например, должны автоматически распространяться на подчиненные системы в случае изменений, являются одним из примеров типа сообщений.

Типы IDoc

Реальная информация может посылаться с помощью промежуточного документа (IDoc — Intermediate Document). Тип IDoc, содержащий описание структуры данных, присваивается типу сообщения как контейнер для данных, которые будут пересылаться. Специальный тип IDoc существует для всех прикладных областей, которые должны готовить данные для обмена. Посылаемые данные, включая таблицы и поля, должны определяться на основе типов IDoc. Когда тип IDoc заполнен конкретными данными в соответствии с правилами структуры, он называется IDoc (промежуточный документ).

Генерация IDoc

В зависимости от приложения для генерации IDoc может использоваться один из трех методов (см. рис. 13.4).

Рис. 13.4. Методы генерации IDoc

Часто IDoc создается прямо из приложения. Прикладная программа либо заполняет внутреннюю таблицу в формате IDoc и переносит ее в службу ALE, либо использует BAPI с интерфейсом ALE.

Вторым методом является генерация IDoc из индикаторов изменения (change indicators). Основой деятельности является автоматическая синхронизация систем в терминах определенных основных данных. Для каждого изменения в наблюдаемом объекте (например, основной записи материала) индикатор изменения записывается для этой записи в таблице базы данных. С помощью планирования отчетов ALE или вручную IDoc генерируется из этих записей изменений и реплицируется в одну или несколько целевых систем.

В третьем методе используется управление сообщениями SAP R/3 для генерации соответствующего IDoc. Отправка сообщения формирует часть стандартных сценариев во многих приложениях, таких как создание заказа на покупку. Сообщение можно напечатать или послать в электронной форме с помощью базовой службы управления сообщениями. Для этого метода рассматриваемое приложение делает записи сообщений типа ALE в таблице NAST. В зависимости от конфигурации записи могут анализироваться либо немедленно системой управления сообщениями SAP R/3, либо с периодическими интервалами с помощью программы отчета RSNAST00; IDoc генерируется из этих записей.

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

Структура IDoc

IDoc состоит из нескольких различных сегментов. Каждый сегмент имеет свое собственное определение структуры и документацию. Для хранения данных используется несколько таблиц на уровне базы данных. IDoc организован иерархически (см. рис. 13.5).

Рис. 13.5. Структура IDoc

Каждый документ IDoc содержит одну управляющую запись, которая состоит из необходимой для переноса технической информации, такой как отправитель, получатель и тип сообщения. Управляющая запись определяет, какие операции обработки необходимы для переносимых данных. Реальные данные сообщения ALE идут после управляющей записи. Данные хранятся в различных сегментах согласно иерархии. Таблица кластеров определяет структуру сегмента и содержит данные, которые будут распространятся, в одном поле. Имя и структура этой таблицы зависит от версии SAP R/3. Третий компонент структуры IDoc является статусной информацией.

За определение обмена данных отвечает настройка (Customizing). Однако техническое определение соединений ALE обычно выполняет системный администратор SAP R/3, работая в тесном сотрудничестве с менеджером приложения или консультантом, отвечающим за прикладную сторону.

13.2.2. Ограничение и ослабление соединения с помощью BAPI

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

Ограничение соединения

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

Ослабление соединений

Чтобы запустить BAPI на целевой системе асинхронно, можно послать в виде IDoc необходимые параметры интерфейса. Получение этой информации запускает обработку предпочтительного метода на целевой системе с пересланными параметрами.

13.2.3. Конфигурация

В этом разделе используется простой пример в качестве иллюстрации базового процесса для конфигурирования метода распространения ALE между двумя системами SAP R/3. Задача состоит в том, чтобы настроить Central User Administration (CUA, см. главу 8). Основное внимание будет здесь сконцентрировано не на приложении, а на системном администраторе и его задачах.

Процедура состоит из следующих шагов:

1. Определение партнера в инфраструктуре ALE

2. Создание представления модели для метода распространения ALE

3. Генерация профиля партнера

Точкой входа для ?ALE Customizing является подузел Implementation Guide (см. главу 6).

Порядок задач более или менее соответствует последовательности их обработки. Описанные ниже настройки всегда основываются на экране ALE Customizing.

Организация логических систем

Партнеры коммуникации в сценарии ALE называются логическими системами и должны быть сначала определены. В инфраструктуре SAP логические системы реализуются клиентами. При настройке коммуникации ALE не имеет значения, будут ли партнеры физически находиться в одной или в разных системах SAP R/3. При присвоении имени логической системе необходимо, насколько возможно, придерживаться соглашения об именах <SID>CLNT<Client>. Это соглашение делает партнера очевидным просто по использованному имени. На рис. 13.7 показаны записи логической системы, которые могут быть доступны прямо из дерева Customizing при использовании символа выполнения.

Рис. 13.6. ALE Customizing (Basis Release 4.6C)

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

Обслуживание модели распространения

Используя логические системные имена, модель распространения описывает партнеров коммуникации и посылаемые данные. Чтобы обеспечить наличие только одной активной версии модели для всех подходящих систем, она создается и поддерживается в одной системе. Для этого в ?ALE Customizing выберите ?Modeling and Implementing Business Processes • Maintain Distribution Model and Distribute Views • Create Model View или прямой подход ?Maintenance of Distribution Model • Create Model View. Введите подходящий короткий текст и техническое имя для планируемого представления модели (см. рис. 13.9).

Рис. 13.8. Присвоение логической системы клиенту

Рис. 13.9. Создание представления модели для Central User Administration

BAPI/тип сообщения

Чтобы определить посылающую и получающую логические системы и тип данных для распространения, выберите из следующих представлений модели:

? Add message type

С помощью нового представления модели присвоенный типу сообщения IDoc должен быть послан удаленной системе.

? Add BAPI

С помощью нового представления модели должен быть активирован метод BAPI или доставлен с параметрами на удаленную систему.

В данном примере CUA посылающей логической системой является «ЕРА_001», а получающей логической системой — «EPACLNT001». Типы бизнес-объектов User и UserCompany (адрес компании) должны быть заполнены с помощью метода Clone (см. рис. 13.10).

Рис. 13.10. Описательные данные модели распространения

Фильтры

Объем пересылаемых данных можно сократить, определяя фильтры. При фильтрации типов сообщений, если ввести пару типа объекта/значение, сегменты IDoc и их подсегменты не пересылаются, если они содержат поле типа объекта, которое не имеет определенного значения. Фильтрация BAPI проверяет пары параметр/значение. Только если параметр соответствует заданному значению, BAPI будет создавать и распространять IDoc.

Специальные настройки

Следующие настройки являются дополнительными параметрами для моделирования бизнес-процесса и реализацией настройки ALE:

? Конфигурирование предварительно определенных бизнес-процессов ALE

? Конфигурирование распространения основных данных

? Конфигурирование синхронизации данных Customizing

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

Коммуникация

Во всех участвующих клиентах необходимо создать специального пользователя для коммуникации между системами. По причинам безопасности это должен быть не диалоговый пользователь, а пользователь с типом communication (см. раздел 8.2.1).

В каждой системе должно быть создано соединение RFC (см. раздел 13.2) с типом 3 (соединение с системой SAP R/3) для коммуникации между партнерами в группе ALE. В примере центрального управления пользователями адреса назначения RFC должны создаваться из центральной системы во всех дополнительных системах, а в зависимости от настроек параметра изменяемости также и в противоположном направлении (см. главу 8).

Если имя адреса назначения RFC соответствует имени логической получающей системы, дополнительные настройки могут генерироваться автоматически.

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

В следующем разделе ?Partner profiles в ALE Customizing описываются параметры для входящей и исходящей обработки для вовлеченных систем (см. раздел 13.11). После генерации профиля партнера этот раздел распространяется на все выбранные партнерские системы или, если задано только модельное представление без каких-либо явных имен партнеров, на всех партнеров в модельном представлении. При определении партнерского профиля в центральной системе в данном примере дополнительные системы являются партнерами.

Размер пакета и режим вывода задаются с помощью параметров вывода. Можно немедленно послать каждый сгенерированный IDoc получателю или собрать несколько IDoc в группу и послать их, когда группа будет заполнена. Недостатком нескольких небольших пакетов является то, что требуется устанавливать соединение с целевой системой и выполнять процедуру регистрации для каждого пакета. Этот подход может привести к деградации производительности. Однако если собирать документы IDoc и затем посылать их, то пул данных в посылающей и получающей системах может со временем различаться. Передача большого числа документов IDoc создает также пиковые нагрузки на получающей системе. Следовательно, необходимо найти разумный компромисс между этими подходами. Обычно SAP рекомендует собирать несколько документов IDoc и передавать их одним пакетом.

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

Рис. 13.11. Генерация партнерского профиля

Рис. 13.12. Технические настройки

Порт

Порт определяет тип соединения с партнером. Данные могут передаваться через tRFC с помощью последовательных файлов, с помощью CPI-C в систему SAP R/2 или через Интернет. Каждому порту присваивается уникальный номер.

Партнерские профили могут успешно генерироваться только тогда, когда имена соединений RFC согласованы с именами логических систем. Если это не так, необходимо определить партнерские профили вручную.

Чтобы обеспечить работу сделанных и сгенерированных настроек, можно выполнить функцию Check all partner profiles for consistency в ?IDoc Check, чтобы осуществить проверку на согласованность всех партнерских профилей.

Настройки модели распространения

Настройки распространения должны быть известны всем партнерским системам. Соответственно последний шаг распространяет настройки модели: ?Maintenance of distribution model • Edit • Model view • Distribute.

Этот шаг завершает определение соединения ALE.

13.2.4. Мониторинг и анализ

Если соединение ALE было задано таким образом, что получатель передает отправителю сообщение о том, что было выполнено, то отправитель может быстро проверить успех передачи. Преимущество этой процедуры состоит в том, что в случае ошибки сообщения от ответственной стороны будут доставлены немедленно, поэтому ошибку можно будет исправить, а процедуру запустить снова. Для этой проверки доступен тип сообщения ALEAUD: можно использовать ALEAUDдля передачи сообщений отправителю о полученных IDoc и их обработке. В качестве предварительного условия для использования этого подтверждения необходимо определить поток сообщений в модели распространения для этого типа сообщений, а затем периодически запускать фоновое задание на получающей системе для получения контрольных данных.

?ALE status monitor (см. рис. 13.13) предлагает обзор статуса обработки документов IDoc, который можно профильтровать согласно нескольким критериям. Можно из обзора перейти к подробному представлению. Когда причина ошибки найдена и исправлена, можно также запустить повторную обработку документов IDoc, которые содержат ошибки и были обработаны не полностью.

Для поддержки различных типов анализа можно перечислить записи в мониторе состояния и отсортировать их согласно различным критериям. Можно дважды щелкнуть мышью, чтобы увидеть дополнительные детали, или щелкнуть на записи IDoc, чтобы вывести его определение (см. рис. 13.14).

?IDoc list предоставляет также подробный вывод документов IDoc, но без возможности повторной отправки.

Описанный здесь монитор статуса и дополнительные функции анализа интегрированы в мониторы для администрирования ALE. В управление ALE можно попасть из SAP Menu через Tools • ALE • ALE Administration. He существует транзакции для замены этого пути доступа.

Рис. 13.13. Монитор статуса для сообщений ALE

Рис. 13.14. Отдельный вывод IDoc в мониторе ALE

Таблица 13.2. Управление ALE

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

Таблица 13.3. Фоновые задания для мониторинга

Если обработка документа IDoc прерывается, можно использовать ?IDoc error handling для включения ручной повторной обработки после исправления ошибки.

Кроме конфигурируемого подтверждения с помощью типа сообщения ALEAUD, можно также выполнить синхронный запрос статуса для определенных документов IDoc. Для этого можно щелкнуть на кнопке Trace IDocs в окне монитора статуса ALE или ?IDoc Tracing.

Диалоговые рабочие процессы обрабатывают полученные документы IDoc. Следовательно, обработка документов IDoc в целевой системе требует присутствия не только обычных диалоговых рабочих процессов для диалоговых пользователей, но и процессов для функций ALE. Можно сконфигурировать параллельную или последовательную обработку полученных документов IDoc. Для параллельной обработки необходимо создать дополнительные диалоговые процессы в количестве, соответствующем среднему числу документов IDoc, которые получаются параллельно. Последовательная обработка требует меньше диалоговых рабочих процессов, но только один документ IDoc может обрабатываться в данный момент, так что может возникнуть затор и падение производительности на получающей стороне. При этом также исключается возможность обработки одного документа IDoc раньше другого, если это понадобится. Техническая команда должна обсудить преимущества и недостатки каждого метода с подразделениями пользователей, а затем создать подходящее техническое решение. Кроме распределения нагрузки между инстанциями SAP R/3, при создании групп в определении соединения RFC может быть полезно в некоторых ситуациях использовать отдельную инстанцию SAP R/3 для обработки документов IDoc. Конечно, такое решение требует анализа стоимости и эффективности, так как для его реализации нужно дополнительное оборудование.

13.3. Перенос данных

Если данные унаследованной системы должны быть перенесены в новое бизнес-решение как часть проекта реализации, то гибкая и высокопроизводительная поддержка потребуется для следующих задач:

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

? Переноса преобразованных данных в новую систему SAP R/3, определяя, какие данные должны отображаться в какие поля таблиц и не требуется ли дополнительная настройка при условии различных структур данных в новой и унаследованной системах.

? Обеспечения полного переноса

Используемый тип переноса для миграции внешних данных в систему SAP R/3 зависит от приложения, которое их получает. Поскольку для каждого прикладного компонента важны различные данные, большинство приложений содержит свои собственные программы переноса данных, которые должны использоваться. Кроме этого фактора, выбор определенной методики переноса данных зависит от важных вопросов: от количества данных для переноса и от того, как часто они будут переноситься (один раз или постоянно).

Методы переноса данных

SAP R/3 поддерживает различные методы переноса данных: пакетный ввод, операция вызова, прямой ввод и перенос с помощью BAPI. Если приложение не имеет своего собственного интерфейса для переноса внешних данных (этот случай является исключением), то можно использовать запись транзакции с пакетным вводом или транзакцией вызова для создания данных, которые будут обрабатываться.

13.3.1. Пакетный ввод

Процедура пакетного ввода является стандартным подходом, который давно используется в среде SAP для переноса данных в систему SAP R/3, имитируя диалог пользователя. Согласованность данных гарантируется, так как процедура включает все транзакционные проверки. Перенос данных происходит в два шага:

1. Создание сеанса пакетного ввода, который содержит все необходимые данные (транзакции, экраны, поля и значения полей)

2. Обработка сеанса в системе. Выполнение сеанса пакетного ввода импортирует данные в систему SAP R/3.

Сеансы пакетного ввода

Обычно можно использовать предварительно определенные программы для форматирования внешних данных и переноса их в сеансе пакетного ввода. В исключительных случаях может понадобиться разработка своей собственной программы пакетного ввода. Программа пакетного ввода читает данные (они должны быть представлены в форме, которую может обработать SAP R/3), форматирует и записывает их в сеансе пакетного ввода. Этот сеанс моделирует диалоговый ввод кодов транзакции и связанный ввод данных. Фактически значения, которые были прочитаны, присваиваются полям экрана каждой транзакции. Структура сеанса пакетного ввода описывает используемые поля, которые возникают из присвоенных транзакций и применяемых в них структур SAP.

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

Автоматическая запись

Автоматическая запись транзакций особенно полезна. Соответствующие структуры сеанса пакетного ввода и программа пакетного ввода могут генерироваться автоматически из записанных транзакций. Автоматическая запись начинается с помощью ?Transaction recorder. После запуска программа записи транзакции выполняет транзакции, которые позже будут перенесены с помощью процедуры пакетного ввода. Сеансы можно генерировать из записей и корректировать их необходимым образом. Затем на следующем шаге можно сгенерировать и при необходимости подкорректировать соответствующую программу АВАР. Такой подход сокращает ручную работу по программированию, которая требовалась ранее.

Когда экранные поля присвоенных транзакций сеанса пакетного ввода были заполнены, сеанс пакетного ввода помещается в очередь пакетного ввода. Сеанс может обрабатываться из очереди: транзакции, которые он содержит, выполняются в фоновом режиме, и данные обрабатываются. База данных использует таблицу APQD для хранения сеанса; таблица одновременно реализует очередь пакетного ввода.

Для выполнения сеанса пакетного ввода имеется два метода:

? Запуск вручную с помощью ?Batch Input; выполнение в диалоге ил в фоновом режиме.

? Автоматический запуск с помощью программы АВАР RSDBCSUB

Для системного администратора мониторинг процессов пакетного ввода является одной из важнейших задач. Во время процедуры пакетного ввода большие объемы данных импортируются в базу данных SAP R/3 в относительно короткое время. Соответственно, системный администратор должен уделять повышенное внимание требуемой в базе данных памяти, увеличенному числу операций записи и возникающему росту объема данных, содержащихся в журналах базы данных. Если планируется перенос данных с помощью пакетного ввода, системный администратор должен быть включен в процесс планирования.

Во время разработки программы пакетной обработки необходимо отметить длину транзакции. Поскольку программы пакетной обработки выполняется в фоновом режиме, на экране не происходит никаких изменений, поэтому с точки зрения базы данных не происходит фиксации изменений (commit). Следовательно, необходимо контролировать длину транзакции с помощью явной фиксации изменений в программе. Доступ к анализу потоков выполнения пакетного ввода и запуск выполнения выполняются с помощью ?Batch Input (см. рис. 13.16). Для анализа есть различные представления. Технические вопросы программы и проблемы содержимого можно разрешить при тесном сотрудничестве между системным администратором, отделами пользователей и разработчиками.

Иногда успешно завершенные сеансы должны удаляться из базы данных, чтобы освободить пространство. Для этого можно использовать отчет RSBDCREO для фоновой обработки. Этот отчет должен выполняться ежедневно как часть стандартных заданий Basis (см. главу 9).

Рис. 13.15. Основной поток данных в процедуре пакетного ввода

Рис. 13.16. Доступ к анализу пакетного ввода

13.3.2. Прямой ввод

При прямом вводе данные в файле переноса данных подвергаются всем проверкам, которые будут происходить при диалоговом вводе; однако он затем переноситься прямо в систему SAP R/3.

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

Программы прямого ввода могут запускаться просто для целей тестирования. В этом случае никакой журнал не создается, а повторное выполнение в случае ошибки выполнить невозможно. Соответственно для производственных целей пересылка данных с помощью прямого ввода должна контролироваться в фоновом режиме с помощью ?Direct input administration.

Процедура прямого ввода быстрее; однако, в отличие от процедуры пакетного ввода, она не может перезапускаться автоматически и является менее удобной для пользователей при возникновении ошибок.

13.3.3. Быстрый ввод/транзакция вызова

Метод быстрого ввода использует другую технику вместо начального переноса данных в сеанс. Переносимые данные сначала записываются во внутреннюю таблицу. Оттуда они обрабатываются с помощью специальной транзакции с помощью оператора АВАР CALL TRANSACTION. Поэтому структура внутренней таблицы должна следовать структуре данных, необходимых для транзакции. При использовании быстрого метода ввода разработчик отвечает за запись в журнал потока выполнения. Поскольку быстрый ввод требует меньше записей в журнале, чем пакетный, то этот ввод быстрее пакетного, но обычно медленнее, чем прямой ввод.

13.3.4. BAPI

Для переноса данных можно использовать также BAPI. Данные обрабатываются с помощью модели ALE, вызывая BAPI в получающем приложении. Для работы этого метода данные источника должны быть представлены в формате IDoc.

Этот процесс выполняет такие же проверки, что и во время диалогового ввода.

13.3.5. Рабочая среда миграции унаследованных систем

Для однократного или периодического переноса данных из систем, отличных от SAP, можно использовать рабочую среду миграции унаследованных систем (LSMW — Legacy System Migration Workbench). Миграция происходит следующим образом:

1. Чтение структуры данных из одного или нескольких файлов, представленных на сервере приложений или представлений.

2. Преобразование файлов согласно правилам преобразования, многие из которых предписаны. Программы преобразования генерируются по правилам для специальных ситуаций миграции объектов данных, которые не работают на уровне таблиц или полей.

3. Импорт данных в целевую систему через стандартный интерфейс (пакетный ввод, прямой ввод, BAPI или IDoc). Во время переноса данные подвергаются тем же проверкам, что и во время диалогового ввода.

LSMW полностью интегрирована в систему SAP R/3, но не в стандартную поставку до Basis Release 6.10 включительно. Можно загрузить требуемые переносы из SAP Service Marketplace по быстрой ссылке lsmw. Начиная с Basis Release 6.10, требуется Version 3; LSMW 4.0 является интегральным компонентом SAP Web Application Server.

Начиная с SAP R/3 4.6C, среда LSMW интегрирована в рабочую среду переноса данных (Data Transfer Workbench).

13.3.6. Рабочая среда переноса данных

Рабочую среду переноса данных (?Data Transfer Workbench) можно использовать для миграции больших объемов данных в систему SAP. Перенос данных управляется проектом: рабочая среда осуществляет управление проектами, которое состоит из извлечения, очистки, преобразования, загрузки и проверки.

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