Предыдущие части:
Часть 1. SAP PI – Создаем асинхронный интерфейс.
Часть 2: Подготовка к разработке в ESR. Активация объектов.
Часть 3: Разработка интерфейсов в ESR.
Часть 4: чудеса преобразования или Mapping.
В предыдущей части мы закончили разработку интерфейса. Теперь переходим к настройке.
Настройка интерфейсов – инструменты и объекты конфигурации.
По традиции – сначала чуть-чуть теории.
Я уже описывал базовые понятия в статье “Основы SAP PI. Часть 5 – “Integration Directory, настройка интерфейса”.
Напомню, что разработка интерфейса – это создание набора интерфейсных объектов с описанием формата исходных и целевых данных, а также правил преобразования для этих форматов. На данном этапе технические подробности передачи – откуда, куда, по какому протоколу – нас не интересовали.
Настройка интерфейса – это процесс включения созданного интерфейса в системный ландшафт. На этом этапе мы указываем, какие конкретно системы и каким способом (например, HTTP, файл, e-mail) будут обмениваться данными.
Репозитарий настройки интерфейсов в SAP PI называется Integration Directory.
Для работы с Integration Directory используется Integration Builder – инструмент, включенный в состав SAP PI.
В простейшем случае, когда обмен информацией ведут две системы (в более сложных вариантах их может быть больше), объекты настройки для интерфейса можно представить в виде следующей схемы:
Деление на участников обмена и объекты маршрутизации введено мной, так удобнее для понимания принципов работы маршрутизации. Объект Party является необязательным объединяющим объектом для бизнес-систем и бизнес-компонент, но обычно, в рамках одного системного ландшафта не используется.
Для настройки нашего интерфейса мы должны создать следующие объекты конфигурации:
- Систему-отправитель и систему-получатель.
- Каналы связи – для отправителя и для получателя
- Цепочку объектов маршрутизации (Sender Agreement – Receiver Determination – Interface Determination – Receiver Agreement) или объект Integrated Configuration.
Цепочку объектов маршрутизации можно создать только в инсталляции ABAP+J2EE; в J2EE доступен только Integrated Configuration.
Бизнес-система и бизнес-компонент, по сути, одно и тоже – описание участника обмена. Различие в том, что первый объект создается в SLD и импортируется в ID; второй – создается сразу в ID.
Более подробно об объектах маршрутизации и принципе их работы читайте в статье “Основы SAP PI. Часть 6 – “Правила маршрутизации и pipeline. Почтальон Пиайкин за работой”.”
Настраиваем бизнес-системы и каналы связи.
Переходим к практике.
Открываем Integration Builder, нажав на ссылку на главной странице SAP PI (http://<host>:<port>/dir).
Так как у нас обе системы заведены в SLD (см. “SAP PI – Создаем асинхронный интерфейс. Часть 1.”), то оперировать мы будем объектом Business System.
В левой части окна (дерево объектов) раскрываем “Communication Component Without Party” и вызываем контекстное меню пункта “Business System”. В меню жмем на “Assign Business System…”.
В открывшемся окне читаем (или просто пропускаем) текст Introduction, а на следующем шаге получаем список систем, определенных в SLD. Выбираем системы, относящиеся к нашему интерфейсу – BS_EXT_CUSTOMERS и BS_NEW_FI_ERP.
Опцию “Create Communication Channels for..” не ставим.
После окончания процесса импорта получаем два объекта в дереве бизнес-систем. Пока не активируем их – выполним активацию позже, для всех созданных объектов.
Теперь займемся каналами связи. Вызываем контекстное меню на узле Communication Channels под системой BS_EXT_CUSTOMERS и нажимаем “New..”
.Задаем техническое имя (помним про соглашение по именам!) и описание канала.
Открывается редактор каналов связи.
Первое, что нам нужно сделать – определить тип адаптера, который будет использован в этом канале. Помним, что исходная система присылает нам данные в виде файла в локальной файловой системе сервера PI.
Открываем список выбора параметра Adapter Type, в списке адаптеров выбираем File.
Так как этот канал связи будет у нас отправлять данные в PI – то устанавливаем соответствующий параметр в Sender.
После подтверждения выбора видим, что параметры канала связи поменялись – вместо общих параметров появились параметры канала для выбранного типа адаптера.
Параметры Transport Protocol, Message Protocol и Adapter Engine оставляем по умолчанию – File System, File и Central Adapter Engine соответственно.
Настройку начнем со вкладки Source – укажем на ней путь к исходному файлу и его имя.
Внимание, прошу прощения за повторное напоминание, но путь к файлу здесь – это локальный путь на сервере SAP PI! При необходимости работы с локальным файлом на другом компьютере, необходимо организовать сетевую папку и доступ к ней с сервера SAP PI, либо использовать промежуточный FTP-сервер.
К сведению – доступ к файлу на ОС Windows идет под пользователем SAPService<SID> (для Unix – SAP<SID>), соответственно этот пользователь должен иметь права на чтение и запись в используемой локальной или сетевой папке.
Теперь перейдем на вкладку Processing – параметры обработки файла.
- Quality of Service установим в Exactly Once – это означает, что данные из файла будут отправлены в PI, как асинхронное сообщение. Если бы мы строили синхронный интерфейс, то параметр нужно было бы поменять.
- Poll Interval – с какой периодичностью опрашивать указанную папку на наличие файла. По умолчанию – 60 секунд.
Далее нас интересует Processing Mode – что будет происходить с файлом после обработки. По умолчанию установлено Test – то есть ничего не делать.
Для нашего эксперимента это не очень удобно. Чтобы понимать, что файл уже обработан, мы его будем переименовывать и перемещать в архивную папку.
Устанавливаем Processing Mode на Archive, в Archive Directory указываем директорию для архивирования (не забудьте дать права пользователю, указанному выше) и устанавливаем галочку в параметре Add Time Stamp – что заставит PI добавлять временную метку в имя архивируемого файла.
Остальные параметры оставляем по умолчанию. Сохраняем получившийся канал связи.
Теперь создадим канал связи для передачи в ERP вызова RFC.
Создаем новый канал связи для системы BS_NEW_FI_ERP, задаем его техническое имя.
Выбираем тип используемого адаптера – RFC.
Так как этот канал связи будет у нас получать данные из PI – то устанавливаем соответствующий параметр в Receiver.
В появившихся параметрах заполняем все параметры RFC-соединения с SAP ERP: сервер, номер системы, пользователь-пароль, язык входа и мандант системы. Если сомневаетесь – уточните значения параметров у специалистов базиса.
Сохраняем изменения.
Наши каналы связи готовы.
Теперь перейдем к маршрутизации сообщений – то есть правилам, по которым PI определяет, куда направить полученные от каналов-отправителей данные.
Настраиваем правила маршрутизации.
Я уже рассказывал, как работают правила маршрутизации.
Для нашего интерфейса я создам Integrated Configuration – объект настройки, в котором все правила маршрутизации собраны, что называется, в один комплект. Его одинаково можно использовать как в ABAP+J2EE, так и в J2EE-only инсталляции SAP PI.
В дереве объектов ищем ветку Integrated Configuration, из контекстного меню этой ветки выбираем “New..”.
В открывшемся диалоговом окне задаем интерфейс отправителя – систему и исходящий интерфейс, BS_EXT_CUSTOMER и SI_NewCustomer_out соответственно. При выборе интерфейса через список пространство имен интерфейса подставится автоматически.
В открывшемся редакторе начнем определять, откуда взять, а также кому и куда доставить данное сообщение (SI_NewCustomer_out).
На первой вкладке Inbound Processing выбираем канал связи, с которого получается данное сообщение.
Остальные параметры оставляем по умолчанию.
Фактически, мы сейчас определили, что все поступающие с этого канала связи сообщения будут считаться сообщениями интерфейса SI_NewCustomer_out.
Переходим на следующую вкладку – Receiver. Здесь мы указываем, какой системе будет отправлен результат – BS_NEW_FI_ERP.
Дополнительные параметры не трогаем, нам пока достаточно значений по умолчанию.
На следующей вкладке – Receiver Interfaces – мы указываем интерфейс получателя (BAPI_CUSTOMER_CREATEFROMDATA1), а также программу преобразования (OM_NewCustomer_to_BAPI_CUSTOMER_CREATEFROMDATA1)
Переходим к следующей вкладке – Outbound Processing и указываем канал связи – получатель CC_RFC_Receiver.
Все, остальные параметры и вкладки оставляем по умолчанию.
Сохраняем наш объект и активируем все, что мы настроили до этого.
Все, с настройкой интерфейса мы закончили, если не было допущено ошибок – то файловый канал связи уже ищет исходный файл, а канал RFC подключился к ERP и ждет вызова от PI.
Поздравляю! Интерфейс готов, осталось лишь протестировать наше творение.
В следующей, завершающей статье я расскажу про тестирование и мониторинг нашего интерфейса.
Ваш Pitroff.
Добрый день! Спасибо за ваш блог, очень интересно, доходчиво и познавательно! 🙂
Хотелось бы спросить, как настраивать, в случае, когда инициирование обмена(изнутри-наружу) осуществляется из самой ERP(например, вызов интерфейса по кнопке на форме)?
Спасибо.
Спасибо на добром слове!
Обратный интерфейс настраивается точно также, те же правила маршрутизации, каналы связи, и т.д.
Вызов из ABAP может быть отправлен в PI через Consumer Proxy (генерируется в SPROXY на базе outbound интерфейса) или RFC (RFC destination нужно будет настроить на канал связи Sender RFC).