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". В рамках основ эту тему раскрывать рановато, оставим это на более сложный этап.

Поделиться:
Share on FacebookShare on VKShare on LinkedInTweet about this on TwitterShare on Google+Digg thisPin on PinterestShare on RedditShare on TumblrEmail this to someonePrint this page

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

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

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