SAP PI – Создаем асинхронный интерфейс. Часть 4: чудеса преобразования или Mapping.

mapping


Предыдущие части:
Часть 1. SAP PI – Создаем асинхронный интерфейс.
Часть 2: Подготовка к разработке в ESR. Активация объектов.
Часть 3: Разработка интерфейсов в ESR.


Продолжаем учиться интеграции в SAP PI и строить простой асинхронный интерфейс. В прошлый раз мы остановились на том, что создали в ESR два интерфейса – исходящий из внешней системы и входящий в SAP ERP.

Напомню схему компонент асинхронного интерфейса в ESR:

Рис.4: Асинхронный интерфейс и его составляющие

Рис.1: Асинхронный Интерфейс и его составляющие

и схему нашего интерфейса:

Рис.1: схема асинхронного интерфейса

Рис.2: схема асинхронного интерфейса

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

Объекты мэппинга в SAP PI.

В SAP PI существует несколько способов преобразовать данные из исходной структуры в целевую:

  • определить правила преобразования с помощью внутреннего графического редактора в ESR (message mapping);
  • использовать внешние программы, написанные на Java;
  • использовать технологию XSLT(eXtensible Stylesheet Language Transformations).

В инсталляции ABAP+J2EE можно использовать еще и мэппинги на ABAP, но я не рекомендую этого делать. Во-первых, SAP упорно пытается “избавится” от ABAP-части в PI; во-вторых, по опыту – ABAP мэппинг медленней, чем все остальные; в-третьих – не получится использовать Integrated Configurations. Мне кажется, достаточно причин, чтобы не использовать этот вид преобразований в своих проектах.

Все преобразования в ESR представляют собой отдельные объекты репозитария:

Тип объекта Описание
Operation mapping Задает исходящую и входящую операции соответствующих интерфейсов; также определяет, какие программы преобразования будут выполнены в процессе передачи сообщения между этими операциями и порядок выполнения этих программ.
Message mapping Объект, в котором определяются преобразования данных из исходного сообщения в целевое. Правила задаются в графическом редакторе мэппингов, входящем в состав Enterprise Service Builder.
Imported archive Архив с внешними программами преобразования (Java или XSLT).
Mapping template Частичные преобразования данных, которые можно использовать как образцы в своих мэппингах.
Function library Библиотека пользовательских функций (Java), которые можно использовать при создании своих мэппингов.

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

Рис. 3: Связь объектов ESR

Рис. 3: Связь объектов ESR

На этом теоретическая часть заканчивается, переходим к практике.

Создание Operation Mapping и Message Mapping в Enterprise Service Builder.

Открываем Enterprise Service Builder, создаем новый объект – Operation Mapping. Определяем его имя, пространство имен, желательно также указать описание.

Рис.4: Создание Operation Mapping

Рис.4: Создание Operation Mapping

Не забываем про корпоративное соглашение об именах или о собственном стандарте наименования объектов репозитария. Здесь я использую следующую схему:
O[peration]M[apping]_<исходящий_интерфейс>_<входящий_интерфейс>
Имена интерфейсов для простоты указываю без префиксов и суффиксов. У вас может быть свой стандарт имен – старайтесь только всегда его придерживаться.

После нажатия кнопки “Create” открывается окно редактирования Operation Mapping. Выбираем исходящий интерфейс (блок Source Operation) – с помощью кнопки выбора рядом с полем ввода. Находим созданный нами на предыдущем шаге интерфейс SI_NewCustomer_out.

Рис.5: задание исходящей операции/интерфейса.

Рис.5: задание исходящей операции/интерфейса.

Затем задаем входящий интерфейс (блок Target Operation). На этот раз, для разнообразия, используем функцию Drag-n-Drop – “перетащим” мышкой импортированный из ERP BAPI_CUSTOMER_CREATEFROMDATA1 из дерева объектов в пустое поле блока Target Operation.

Рис.6: задание целевой операции/интерфейса.

Рис.6: задание целевой операции/интерфейса.

Нажмем кнопку “Read Operations” – PI прочитает операции заданных интерфейсов и подставит соответствующие типы сообщений.

Обратите внимание, что до считывания операций на экране было две вкладки – “Request” и “Response”, а после считывания осталась только одна. Это потому, что наш интерфейс – асинхронный, то есть данные идут в одном направлении и мэппинг для ответа(“Response”) не нужен. В синхронном интерфейсе используются обе вкладки.

Получаем слева message type MT_Customer, справа – импортированную из ERP структуру BAPI_CUSTOMER_CREATEFROMDATA1. Между ними – пустое поле для задания правил преобразования. Впишем туда имя и пространство имен создаваемого мэппинга сообщений:

  • MM_Customer_to_BAPI_CUSTOMER_CREATEFROMDATA1
  • http://sap.pitroff.ru/examples/async1
Рис.7: создание мэппинга для сообщений.

Рис.7: создание мэппинга для сообщений.

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

Рис.8: создание мэппинга для сообщений.

Рис.8: создание мэппинга для сообщений.


Соглашаемся на создание.

Message Mapping – редактор.

Открывается экран редактирования Message Mapping, в котором мы видим слева структуру исходного сообщения, справа – целевого.

Рис.9: Message Mapping редактор

Рис.9: Message Mapping редактор

Начнем с самой простой задачи – проведем мэппинг тех полей, значения которых должны перейти в целевую структуру без изменений. Это, в частности, поля адреса (city, street, и т.п.)
Выбираем нужное нам поле в целевой структуре, а соответствующее ему поле исходной структуры перетаскиваем мышкой в окно редактирования. Каждое поле будет представлено в области редактирования в виде прямоугольника с белой полосой сбоку (у исходящего – справа, у целевого – слева). При помощи мыши соединяем эти две области. Если все произошло успешно, то оба прямоугольника станут зелеными, а между ними появится соединительная линия.

Рис.10: мэппинг полей "один-к-одному"

Рис.10: мэппинг полей “один-к-одному”

Поступаем так со всеми остальными полями, не требующими изменений.

Теперь посмотрим общую картину связей между полями исходной и целевой структур. Нажимаем кнопку “Dependencies”, выбираем “Show all” и видим все уже связанные между собой поля.

Рис.11: инструмент "Dependencies"

Рис.11: инструмент “Dependencies”(“Зависимости”)

Рис.12: Результат работы инструмента "Dependencies" - отображение связи между полями.

Рис.12: Результат работы инструмента “Dependencies” – отображение связи между полями.

В текущей версии наблюдается странность – если нажать “Detach window”, то есть отделить окно редактора мэппингов от остальных инструментов, то в таком режиме линии связи перестают отображаться. Нажатие “Attach window” возвращает отображение связей. Будьте внимательны. Возможно, в следующих версиях эта ошибка будет исправлена.

Как быть с теми полями исходного сообщения, для которых в структуре BAPI нет соответствующего поля (Client_code,Class)?
Все зависит от их необходимости в целевой системе. Если они не нужны – можно просто не использовать их в правилах преобразования.

Если же их значения нужны – то возможно два варианта:

  • дополнить целевую структуру необходимыми полями или выбрать другой интерфейс;
  • перенести значения в целевую систему при помощи неиспользуемых полей.

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

Возьмем второй вариант и перенесем значения следующим образом:

Client_code -> PI_PERSONALDATA-SECOND_NAME

Class -> PI_PERSONALDATA-TITLE_P

Поле Manager использовать не будем.

С точки зрения бизнес-логики это означает следующее: в целевой системе, при необходимости определить тип клиента или его номер, пользователю нужно будет смотреть в параметры “second name” и “title” соответственно; а в качестве даты рождения клиента используется дата регистрации клиента в исходной системе. На практике такой прием хранения информации используется достаточно часто – это позволяет минимизировать собственные разработки в SAP ERP в тех случаях, когда стандартного поля для информации в ERP не существует.

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

Рис.13: Инструменты работы с функциями в Message Mapping Editor.

Рис.13: Инструменты работы с функциями в Message Mapping Editor.

Выберем целевое поле для редактирования. Затем выбираем функции для работы с константами (“Constants”).

Рис.14: функции работы с константами.

Рис.14: функции работы с константами.

Одинарным кликом по функции “Constant” создаем константу в поле редактирования связей. Двойным кликом по появившемуся прямоугольнику открываем окно задания значения константы (“Value”) и заносим туда X. Затем связываем “выход”(белое поле справа от блока константы) со “входом” (белое поле слева от блока целевого поля. Все, занесение константы в целевое поле закончено.

Рис.15: занесение константы в поле целевой структуры

Рис.15: занесение константы в поле целевой структуры

В редакторе Message Mapping заложено достаточно большое количество стандартных функций – математических, логических, текстовых и других назначений. Мы сейчас подробно их разбирать не будем, если вам интересно – то узнать о них можно на help.sap.com

Переходим к следующему полю, требующему внимания – Reg_date. Как мы помним, в исходных условиях дата передается как ДДММГГГГ, а в BAPI стандартным форматом является YYYYMMDD.
Для перевода формата будем использовать стандартную функцию DateTrans из группы стандартных функций Date. Выход поля RegDate подаем на вход этой функции, выход функции – на вход поля PI_PERSONALDATA-DATE_BIRTH. Теперь зададим значения параметров функции (через двойной клик по блоку функции, либо через контекстное меню блока):

Рис.16: изменение формата даты при помощи  функции DateTrans

Рис.16: изменение формата даты при помощи функции DateTrans

Осталось необработанным только одно поле – Name. И тут мы сталкиваемся с проблемой – исходная система отдает полное ФИО человека одной строкой, целевая система
требует разделения этой строки на отдельные поля для имени, фамилии и отчества. Для простоты будем считать, что полное имя из исходной системы приходит в строгом порядке: фамилия+пробел+имя+пробел+отчество.

Стандартные функции здесь не помогут (к сожалению, разбиение строковых значений в список стандартных функций не входит). Но мы можем использовать пользовательские функции (User Defined Functions или UDF) – с использованием языка Java.

Для этого нажимаем в блоке функций самую левую кнопку – “Create new function”. В открывшемся окне заполняем параметры:

Рис.17: создание User Defined Function

Рис.17: создание User Defined Function

Задаем имя функции – SplitName, Execution type устанавливаем в All Values of a Context, затем задаем один входящий аргумент (fullName) и три результата (lastName, firstName, midName). Нажимаем “Create function”. Открывается редактор кода, в котором можно писать программу на Java.

Рис.18: создание User Defined Function - редактирование кода функции

Рис.18: создание User Defined Function – редактирование кода функции

Код функции будет следующий:
for (int i = 0; i < fullName.length; i++) { String tokens[] = fullName[i].split(" "); lastName.addValue(tokens[0]); firstName.addValue(tokens[1]); midName.addValue(tokens[2]); }

Закрываем редактор и в списке функций, в разделе User-Defined появляется наша новая функция. Переносим ее в поле редактирования, туда же переносим исходное поле Name и три целевых поля: LASTNAME, MIDDLENAME и FIRSTNAME. Соединяем соответствующие поля со входом и выходами нашей пользовательской функции.

Рис.19:  создание мэппинга с использованием UDF

Рис.19: создание мэппинга с использованием UDF

На этом создание мэппинга можно считать законченным. Теперь нужно протестировать то, что у нас получилось.

Тестирование Message Mapping.

Созданный мэппинг можно сразу же протестировать, даже не выходя из редактора. Для этого переходим на вкладку Test:

Рис.20: тестирование мэппинга

Рис.20: тестирование мэппинга

Слева мы заполняем тестовыми значениями исходную структуру. Для удобства, набор значений можно сохранить - нажимаем кнопку "Create test instance":

Рис.21: Создание тестовой инстанции

Рис.21: Создание тестовой инстанции

Задаем название этого тестового набора и сохраняем его.

Рис.22: задание технического имени для тестового набора

Рис.22: задание технического имени для тестового набора


Теперь этот набор будет храниться вместе с message mapping и после изменений можно будет не вводить все значения заново.

Давайте теперь запустим тест:

Рис.23: запуск тестирования

Рис.23: запуск тестирования


Ну что же, результат положительный и в правой части мы видим получившуюся целевую структуру.
Рис.24: результат тестирования

Рис.24: результат тестирования

Теперь сохраняем и закрываем наш message mapping, затем сохраняем и закрываем Operation Mapping - в нем уже создано все, что нужно для работы.
Активируем оба объекта - Operation Mapping и Message Mapping.
Правила преобразования готовы, и, учитывая сделанное в предыдущих статьях - мы закончили работу в Enterprise Service Builder по созданию интерфейса и переходим к его настройке в Integration Builder.


Вообще, в создании Message Mapping есть одна тема, которая требует отдельного разбора - это понятие контекста и, связанные с этим функции группы "Node Functions". В рамках основ эту тему раскрывать рановато, оставим это на более сложный этап.

3 thoughts on “SAP PI – Создаем асинхронный интерфейс. Часть 4: чудеса преобразования или Mapping.

  1. Viacheslav

    Добрый день! Спасибо за столь познавательный блог!

    Вопрос по мэппингу – требуется ли нам в сценарии объект MessageMapping, если исходящее и входящее сообщение в соотв. интерфейсах одного и того же типа (ссылаются на один и этот же MessageType)? Можно в этом случае обойтись без MessageMapping?

    Reply
    1. pitroff.ru Post author

      Здравствуйте, Вячеслав!

      Спасибо на добром слове. )

      Да, если исходящее и целевое сообщения ссылаются на один и тот же Message Type – мэппинг можно не создавать и в правилах маршрутизации в поле “мэппинг” ничего не указывать.

      Reply
  2. Евгений

    Здравствуйте, Алексей!
    С удовольствием читаю Ваши статьи для расширения кругозора, так сказать.
    Насчет контекстов: когда планируете рассматривать? На собственном опыте убедился, что разбираться с этим надо сразу, очень много времени экономит в дальнейшем. Да и большинство мэппингов (особенно графических) требуют хотя бы элементарного понимания очередей, смены контекстов и т.д.
    Так что ждем-с 🙂
    P.S. После того, как более-менее разобрался, был поражен: оказалось, в графическом мэппинге можно довольно легко реализовать преобразования, для которых ранее требовалось использовать java или xslt.

    Reply

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *