Предыдущие части:
Часть 1. SAP PI – Создаем асинхронный интерфейс.
Часть 2: Подготовка к разработке в ESR. Активация объектов.
Часть 3: Разработка интерфейсов в ESR.
Продолжаем учиться интеграции в SAP PI и строить простой асинхронный интерфейс. В прошлый раз мы остановились на том, что создали в ESR два интерфейса – исходящий из внешней системы и входящий в SAP ERP.
Напомню схему компонент асинхронного интерфейса в ESR:
и схему нашего интерфейса:
Сегодня мы будем строить правила преобразования из исходного интерфейса в целевой или мэппинг структуры данных.
Объекты мэппинга в 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), которые можно использовать при создании своих мэппингов. |
Связь между этими объектами можно представить в виде следующей схемы, где стрелки обозначают ссылки из одного объекта на другой:
На этом теоретическая часть заканчивается, переходим к практике.
Создание Operation Mapping и Message Mapping в Enterprise Service Builder.
Открываем Enterprise Service Builder, создаем новый объект – Operation Mapping. Определяем его имя, пространство имен, желательно также указать описание.
Не забываем про корпоративное соглашение об именах или о собственном стандарте наименования объектов репозитария. Здесь я использую следующую схему:
O[peration]M[apping]_<исходящий_интерфейс>_<входящий_интерфейс>
Имена интерфейсов для простоты указываю без префиксов и суффиксов. У вас может быть свой стандарт имен – старайтесь только всегда его придерживаться.
После нажатия кнопки “Create” открывается окно редактирования Operation Mapping. Выбираем исходящий интерфейс (блок Source Operation) – с помощью кнопки выбора рядом с полем ввода. Находим созданный нами на предыдущем шаге интерфейс SI_NewCustomer_out.
Затем задаем входящий интерфейс (блок Target Operation). На этот раз, для разнообразия, используем функцию Drag-n-Drop – “перетащим” мышкой импортированный из ERP BAPI_CUSTOMER_CREATEFROMDATA1 из дерева объектов в пустое поле блока Target Operation.
Нажмем кнопку “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
Теперь по двойному клику на имя мэппинга система сообщит, что его не существует и предложит его создать.
Соглашаемся на создание.
Message Mapping – редактор.
Открывается экран редактирования Message Mapping, в котором мы видим слева структуру исходного сообщения, справа – целевого.
Начнем с самой простой задачи – проведем мэппинг тех полей, значения которых должны перейти в целевую структуру без изменений. Это, в частности, поля адреса (city, street, и т.п.)
Выбираем нужное нам поле в целевой структуре, а соответствующее ему поле исходной структуры перетаскиваем мышкой в окно редактирования. Каждое поле будет представлено в области редактирования в виде прямоугольника с белой полосой сбоку (у исходящего – справа, у целевого – слева). При помощи мыши соединяем эти две области. Если все произошло успешно, то оба прямоугольника станут зелеными, а между ними появится соединительная линия.
Поступаем так со всеми остальными полями, не требующими изменений.
Теперь посмотрим общую картину связей между полями исходной и целевой структур. Нажимаем кнопку “Dependencies”, выбираем “Show all” и видим все уже связанные между собой поля.
В текущей версии наблюдается странность – если нажать “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(“икс”).
Здесь мы будем использовать функции редактора мэппингов, меню функций расположено под окном редактирования связей.
Выберем целевое поле для редактирования. Затем выбираем функции для работы с константами (“Constants”).
Одинарным кликом по функции “Constant” создаем константу в поле редактирования связей. Двойным кликом по появившемуся прямоугольнику открываем окно задания значения константы (“Value”) и заносим туда X. Затем связываем “выход”(белое поле справа от блока константы) со “входом” (белое поле слева от блока целевого поля. Все, занесение константы в целевое поле закончено.
В редакторе Message Mapping заложено достаточно большое количество стандартных функций – математических, логических, текстовых и других назначений. Мы сейчас подробно их разбирать не будем, если вам интересно – то узнать о них можно на help.sap.com
Переходим к следующему полю, требующему внимания – Reg_date. Как мы помним, в исходных условиях дата передается как ДДММГГГГ, а в BAPI стандартным форматом является YYYYMMDD.
Для перевода формата будем использовать стандартную функцию DateTrans из группы стандартных функций Date. Выход поля RegDate подаем на вход этой функции, выход функции – на вход поля PI_PERSONALDATA-DATE_BIRTH. Теперь зададим значения параметров функции (через двойной клик по блоку функции, либо через контекстное меню блока):
Осталось необработанным только одно поле – Name. И тут мы сталкиваемся с проблемой – исходная система отдает полное ФИО человека одной строкой, целевая система
требует разделения этой строки на отдельные поля для имени, фамилии и отчества. Для простоты будем считать, что полное имя из исходной системы приходит в строгом порядке: фамилия+пробел+имя+пробел+отчество.
Стандартные функции здесь не помогут (к сожалению, разбиение строковых значений в список стандартных функций не входит). Но мы можем использовать пользовательские функции (User Defined Functions или UDF) – с использованием языка Java.
Для этого нажимаем в блоке функций самую левую кнопку – “Create new function”. В открывшемся окне заполняем параметры:
Задаем имя функции – SplitName, Execution type устанавливаем в All Values of a Context, затем задаем один входящий аргумент (fullName) и три результата (lastName, firstName, midName). Нажимаем “Create function”. Открывается редактор кода, в котором можно писать программу на Java.
Код функции будет следующий:
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. Соединяем соответствующие поля со входом и выходами нашей пользовательской функции.
На этом создание мэппинга можно считать законченным. Теперь нужно протестировать то, что у нас получилось.
Тестирование Message Mapping.
Созданный мэппинг можно сразу же протестировать, даже не выходя из редактора. Для этого переходим на вкладку Test:
Слева мы заполняем тестовыми значениями исходную структуру. Для удобства, набор значений можно сохранить - нажимаем кнопку "Create test instance":
Задаем название этого тестового набора и сохраняем его.
Теперь этот набор будет храниться вместе с message mapping и после изменений можно будет не вводить все значения заново.
Давайте теперь запустим тест:
Ну что же, результат положительный и в правой части мы видим получившуюся целевую структуру.
Теперь сохраняем и закрываем наш message mapping, затем сохраняем и закрываем Operation Mapping - в нем уже создано все, что нужно для работы.
Активируем оба объекта - Operation Mapping и Message Mapping.
Правила преобразования готовы, и, учитывая сделанное в предыдущих статьях - мы закончили работу в Enterprise Service Builder по созданию интерфейса и переходим к его настройке в Integration Builder.
Вообще, в создании Message Mapping есть одна тема, которая требует отдельного разбора - это понятие контекста и, связанные с этим функции группы "Node Functions". В рамках основ эту тему раскрывать рановато, оставим это на более сложный этап.
Добрый день! Спасибо за столь познавательный блог!
Вопрос по мэппингу – требуется ли нам в сценарии объект MessageMapping, если исходящее и входящее сообщение в соотв. интерфейсах одного и того же типа (ссылаются на один и этот же MessageType)? Можно в этом случае обойтись без MessageMapping?
Здравствуйте, Вячеслав!
Спасибо на добром слове. )
Да, если исходящее и целевое сообщения ссылаются на один и тот же Message Type – мэппинг можно не создавать и в правилах маршрутизации в поле “мэппинг” ничего не указывать.
Здравствуйте, Алексей!
С удовольствием читаю Ваши статьи для расширения кругозора, так сказать.
Насчет контекстов: когда планируете рассматривать? На собственном опыте убедился, что разбираться с этим надо сразу, очень много времени экономит в дальнейшем. Да и большинство мэппингов (особенно графических) требуют хотя бы элементарного понимания очередей, смены контекстов и т.д.
Так что ждем-с 🙂
P.S. После того, как более-менее разобрался, был поражен: оказалось, в графическом мэппинге можно довольно легко реализовать преобразования, для которых ранее требовалось использовать java или xslt.