Добрый день!
Серия публикаций по основам SAP PI продолжается.
Надеюсь, что предыдущая серия была для вас интересна и полезна.
На этот раз мы будем создавать асинхронный интерфейс, попутно продолжая разбираться в инструментах и терминах.
Постановка бизнес-задачи.
Предположим, мы сейчас работаем специалистом по SAP PI в ООО “Выпученные глазки”, компания занимается дистрибуцией товаров народного потребления в широком географическом пространстве. До настоящего времени вся информация от филиалов (клиенты, заказы, поставки, оплаты и пр.) собиралась как попало: кто-то присылал файлы в архивах по почте, кто-то откладывал до последнего момента и привозил все сразу в конце месяца.
В связи с переходом на SAP возникла идея собирать всю информацию более упорядоченным способом. Было разработано новое интеграционное решение на базе SAP Netweaver Process Integration.
Одним из элементов будущего интеграционного решения должен стать интерфейс, обрабатывающий информацию о новом клиенте. При появлении нового покупателя от информационной системы филиала приходит XML-файл и записывается в определенную папку на ftp-сервере.
Задача интерфейса – обработать файл и передать информацию в ERP, автоматически создав основную запись клиента.
Техническая постановка задачи.
Разберем с технической точки зрения – что за интерфейс нам предстоит создать?
- Интерфейс у нас асинхронный, так как исходная система не ожидает немедленного ответа, то есть данные идут в одном направлении.
- Исходная система присылает XML-файл, значит будем использовать файловый адаптер.
- Целевая система – ERP, значит есть выбор интерфейсных технологий – PROXY, IDOC, RFC.
Для минимизации настроек в ERP – будем использовать RFC-интерфейс.
Схематично это будет выглядеть так:
Рис.1: схема асинхронного интерфейса
Ну что же, приступим. Начнем мы с основного – определим участников обмена, то есть интеграционный ландшафт.
Определение интеграционного ландшафта – SLD.
Что и зачем есть в SLD – мы уже разбирали.
I. Подключение SAP ERP.
Запускаем SAP GUI, входим в SAP ERP, вызываем транзакцию RZ70:
Рис.2: Транзакция RZ70 – передача в SLD данных ABAP-системы
1) Здесь нужно заполнить параметры SLD Bridge: Gateway Information – данные сервера, на котором расположен SLD. В нашем случае SLD установлен вместе с PI, значит значения будут следующие:
| Параметр | Значение |
|---|---|
| Host | IP или DNS-адрес сервера PI |
| Service | Сервис gateway, обычно sapgw<XX>, где XX – номер инстанции |
Сервер и номер инстанции можно найти в SAP Logon или непосредственно в системе. Если сомневаетесь в параметрах – уточните у администраторов системы.
2) Далее выбираем необходимые программы для сбора данных, то есть определяем – какая информация пойдет в SLD (данные серверов приложений, базы данных, SAP Gateway и т.д).
В общем случае, если у вас не режим повышенной секретности – достаточно нажать на кнопку “Proposal”.
3) После этого, если нужно, задаем период автоматического обновления данных в SLD (полезно, если система постоянно обновляется).
4+5) Затем нажимаем последовательно кнопки “Activate”(F8) и “Start Data Collection and Job Scheduling”(F5).
Система запустит программы сбора данных, затем вызовет SLD по RFC и передаст собранный пакет данных о системе.
В случае успешного выполнения вызова на экране появится следующий текст:
Рис.3: Успешная передача данных в SLD.
Проверяем: заходим в SLD и в разделе “Technical Systems” обнаруживаем новую техническую ABAP-систему:
Рис.4: Техническая система в SLD
Обратите внимание на дату и время обновления – они должны совпадать с текущими на сервере.
II. Подключение внешней non-SAP системы.
Теперь очередь системы, которая передает файлы.
Как я уже писал ранее – для заведения нового не-SAP участника обмена в SLD необходимо сначала создать продукт и программный компонент. Программный компонент затем будет нужен в качестве базы для создания интерфейсов в в ESR.
В SLD переходим по ссылке “Products” в блоке “Software Catalog”, нажимаем кнопку “New”:
Рис.5: Создание нового продукта в SLD
Выбираем “New product and product version”,
Рис.6: Создание нового продукта в SLD
затем заполняем параметры продукта – наименованию, разработчика, версию и техническое имя:
Рис.7: Создание нового продукта в SLD
Каждый продукт должен состоять как минимум из одного программного компонента – на следующей вкладке создаем этот программный компонент:
Рис.8: Создание нового программного компонента в SLD
Завершаем процедуру, теперь у нас есть все, чтобы создать техническую систему.
На самом деле, все не-SAP технические системы для SLD, как говорится, “на одно лицо”. Фактические параметры соединения настраиваются непосредственно в параметрах канала связи, а в SLD нужно просто обозначить, что такая система есть и создать запись о стороннем программном обеспечении
Для подключения возвращаемся на начальный экран SLD, выбираем “Technical Systems” из блока “Landscape”, затем нажимаем кнопку “New Technical System..”.
Рис.9: Создание технической системы в SLD
Параметр “System Type” устанавливаем в Third-Party,
Рис.10: Создание технической системы в SLD
затем придумываем и указываем уникальное имя системы и имя сервера, на котором она установлена (сервер может и не существовать на самом деле – это чисто информационное поле).
Рис.11: Создание технической системы в SLD
Далее указываем установленное на системе ПО, находим и выбираем созданный нами на предыдущем шаге продукт.
Рис.12: Создание технической системы в SLD
Завершаем процедуру создания технической системы.
Теперь осталось только создать интеграционный ландшафт.
III. Бизнес-системы.
Теперь нужно обозначить системы, как участников обмена в интеграционном ландшафте SAP PI.
В SLD с основной страницы переходим по ссылке “Business Systems” в блоке “Landscape”.
Рис.13: Создание бизнес-систем в SLD
Сначала создадим бизнес-систему для SAP ERP.
Нажимаем кнопку “New Business System..”, указываем тип технической системы – AS ABAP.
Рис.14: Создание бизнес-систем в SLD – тип системы
Далее выбираем техническую систему ABAP, лежащую в основе (мы ее создали в SLD автоматически, через RZ70);
выбираем также мандант, с которым будем работать (каждый мандант ABAP-системы – это отдельная бизнес-система).
Поле URL – оставляем пустым, нам оно в работе не понадобится.
Рис.15: Создание бизнес-систем в SLD – задание технической системы
Затем задаем имя бизнес-системы. Оно должно быть уникально в рамках ландшафта и, по возможности, содержать информацию о системе (ID, мандант, тип, и тп.).
Рис.16: Создание бизнес-систем в SLD – задание имени
Желательно заранее определить правило задания таких имен и следовать ему при создании бизнес-систем.
На следующем шаге определяется, какие продукты и программные компоненты, установленные на технической системе, относятся к создаваемой бизнес-системе. Поскольку всю информацию о ПО мы автоматически передали из SAP ERP, и все программные компоненты участвуют в работе этой бизнес-системы – ничего не меняем и просто переходим на следующий шаг.
Рис.17: Создание бизнес-систем в SLD – продукты и программные компоненты
И в завершении – определяем роль бизнес-системы (ставим “Application System”). Тип “Integration Server” используется только для интеграционного сервера SAP PI.
Также выбираем соответствующий сервер PI для нашей бизнес-системы (параметр “Related Integration Server”).
Рис.18: Создание бизнес-систем в SLD – тип системы и соответствующий интеграционный сервер
Наша бизнес-система для SAP ERP готова.
Осталось задать бизнес-систему для файлового обмена.
Создаем новую бизнес-систему, задаем тип “Third-Party/Other”.
Рис.19: Создание бизнес-систем в SLD – не-SAP системы
Указываем, какую техническую систему мы имеем в виду. Поле “Logical System” оставляем пустым (оно необходимо только при работе с ALE).
Рис.20: Создание бизнес-систем в SLD – техническая система
Задаем имя бизнес-системы.
Рис.21: Создание бизнес-систем в SLD – имя.
Задаем продукт и программный компонент (создан нами до этого).
Рис.22: Создание бизнес-систем в SLD – продукт и программный компонент
Задаем соответствующий сервер интеграции.
Рис.23: Создание бизнес-систем в SLD – соответствующий сервер интеграции.
Все, бизнес-система создана.
На этом работа в SLD закончена, интеграционный ландшафт определен.
Рис.24: бизнес-системы в SLD
Схема созданных объектов выглядит так:
Рис.25: асинхронный интерфейс – определение в SLD участников обмена
Процедура создания бизнес-систем кажется долгой и сложной только в первый раз. В дальнейшем, подключение новых участников обмена выполняется быстро и без особых сложностей. На большом ландшафте/крупном проекте желательно выделить отдельного администратора SLD, и сделать так, чтобы права на создание/изменения ландшафта в SLD были только у авторизованных персон.
Теперь можно закрыть SLD и перейти в Enterprise Service Repository.
Продолжение следует..
