SAP PI - Изграждане на асинхронен интерфейс

SAP PI - Създаване на асинхронен интерфейс. Част 4: чудеса на трансформация или картографиране.

Продължаваме да се учим как да се интегрираме в SAP PI и да изградим прост асинхронен интерфейс. Последния път се спряхме на това, че създадохме два интерфейса в ESR - изходящ от външна система и включен в SAP ERP.

Позволете ми да ви напомня диаграмата на компонентите на асинхронния интерфейс в ESR:

Фиг.1: Асинхронен интерфейс и неговите компоненти

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

Фигура 2: Схема на асинхронен интерфейс

Днес ще изградим правила за трансформиране от изходен към целеви интерфейс или картографиране на структура на данни.

Картографиране на обекти в SAP PI.

В SAP PI има няколко начина за трансформиране на данни от изходна структура в целева структура:

Можете също да използвате ABAP съпоставяне в ABAP+J2EE инсталация, но не препоръчвам да правите това. Първо, SAP се опитва усилено да се отърве от частта ABAP в PI; второ, от опит - картографирането на ABAP е по-бавно от всички останали; трето, няма да работи за използване на интегрирани конфигурации. Струва ми се, че има достатъчно причини да не използвате този вид трансформация във вашите проекти.

Всички трансформации в ESR са отделни обекти на хранилище:

Връзката между тези обекти може да бъде представена като следната диаграма, където стрелките показват връзки от един обект към друг:

Ориз. 3: Свързване на ESR обекти

Това завършва теоретичната част, нека да преминем към практиката.

Създаване на картографиране на операции и картографиране на съобщения в Enterprise Service Builder.

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

Фигура 4: Създаване на картографиране на операция

Не забравяйте за корпоративната конвенция за именуване или вашия собствен стандарт за именуване на обекти в хранилището. Тук използвам следната схема: O[operation]M[apping]_ _ За простота посочвам имена на интерфейси без префикси и суфикси. Можете да имате свой собствен стандарт за именуване - просто се опитвайте да се придържате към него през цялото време.

След като щракнете върху бутона "Създаване", се отваря прозорецът за редактиране на картографиране на операции. Избираме изходящия интерфейс (блок Source Operation) - чрез бутона за избор до полето за въвеждане. Намерете интерфейсаSI_NewCustomer_out, който създадохме в предишната стъпка.

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

След това задаваме входящия интерфейс (Target Operation block). Този път за промяна използваме функцията Drag-n-Drop - „плъзгаме“ с мишката импортираното от ERPBAPI_CUSTOMER_CREATEFROMDATA1 от дървото на обектите в празното поле на блока Target Operation.

Фиг.6: Дефиниране на целевата операция/интерфейс.

Щракнете върху бутона "Операции за четене" - PI ще прочете операциите на посочените интерфейси и ще замени подходящите типове съобщения.

Моля, обърнете внимание, че преди четене на операциите на екрана имаше два раздела - "Заявка" и "Отговор", а след четене остана само един. Това е така, защото нашият интерфейс е асинхронен, т.е. данните вървят в една посока и картографирането за отговора („Отговор“) не е необходимо. Синхронният интерфейс използва и двата раздела.

Отляво получаваме типа съобщение MT_Customer, отдясно получаваме структурата BAPI_CUSTOMER_CREATEFROMDATA1, импортирана от ERP. Между тях има празно поле за задаване на правилата за трансформация. Нека въведем там името и пространството от имена на създаденото съпоставяне на съобщения:

Фиг.7:създаване на картографиране за съобщения.

Сега, като кликнете два пъти върху името на картографирането, системата ще съобщи, че то не съществува и ще предложи да го създадете.

Фиг.8: създаване на картографиране за съобщения.

Отваря се екранът за редактиране на Message Mapping, в който виждаме структурата на изходното съобщение отляво и целевото съобщение отдясно.

Фигура 10: картографиране на полето едно към едно

Правим това с всички други полета, които не изискват промени.

Сега нека разгледаме общата картина на връзките между полетата на изходната и целевата структура. Натискаме бутона "Зависимости", избираме "Покажи всички" и виждаме всички полета, които вече са свързани едно с друго.

Фиг. 11: Инструмент "Зависимости".

Фиг.12: Резултатът от инструмента "Зависимости" е показване на връзката между полетата.

Какво ще кажете за онези полета от оригиналното съобщение, за които няма съответстващо поле в структурата на BAPI (Client_code,Class)? Всичко зависи от тяхната нужда в целевата система. Ако не са необходими, можете просто да не ги използвате в правилата за преобразуване.

Ако са необходими техните стойности, тогава са възможни две опции:

• допълнете целевата структура с необходимите полета или изберете различен интерфейс;
• прехвърлете стойности към целевата система, като използвате неизползвани полета.

И в двата случая са необходими консултации с разработчици/консултанти на целевата система.

Нека вземем втората опция и прехвърлим стойностите, както следва:

Полето Мениджър няма да се използва.

От гледна точка на бизнес логиката това означава следното: в целевата система, ако е необходимо, за да определи вида на клиента или неговия номер, потребителят ще трябва да погледне параметрите „второ име“ и „заглавие“.съответно; а датата на раждане на клиента е датата на регистрация на клиента в изходната система. На практика този метод за съхранение на информация се използва доста често - това ви позволява да минимизирате собствените си разработки в SAP ERP в случаите, когато в ERP няма стандартно поле за информация.

Фиг.13: Инструменти за работа с функции в редактора за съпоставяне на съобщения.

Изберете целевото поле за редактиране. След това избираме функции за работа с константи (“Константи”).

Фиг.14: Функции за работа с константи.

С едно кликване върху функцията "Константа" създаваме константа в полето за редактиране на връзката. Щракнете двукратно върху появилия се правоъгълник, отворете прозореца за задаване на стойността на константата (“Стойност”) и въведете там X. След това свързваме “изхода” (бяло поле отдясно на блока с константа) с “вход” (бяло поле отляво на блока на целевото поле. Това е всичко, въвеждането на константата в целевото поле е завършено.

Фиг.15: Въвеждане на константа в полето на целевата структура

Нека да преминем към следващото поле, което изисква внимание - Reg_date. Както си спомняме, в първоначалните условия датата се предава катоДДММГГГГ, а в BAPI стандартният формат е ГГГГММДД. За да преведем формата, ще използваме стандартната функция DateTrans от групата стандартни функции за дата. Изходът от полето RegDate се подава на входа на тази функция, изходът на функцията се подава на входа на полето PI_PERSONALDATA-DATE_BIRTH. Сега нека зададем стойностите на функционалните параметри (чрез двукратно щракване върху функционалния блок или чрез контекстното меню на блока):

Фигура 16: Промяна на формата на датата с помощта на функцията DateTrans

Само едно поле остана необработено - Име. И тук се сблъскваме с проблем - оригиналната система дава пълното име на лицето на един ред,целевата система изисква този низ да бъде разделен на отделни полета за име, фамилия и бащино име. За простота ще приемем, че пълното име от изходната система идва в строг ред: фамилия + интервал + собствено име + интервал + бащино име.

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

За да направите това, натиснете най-левия бутон във функционалния блок - „Създаване на нова функция“. В прозореца, който се отваря, попълнете параметрите:

Фигура 17: Създаване на дефинирана от потребителя функция

Фигура 18: Създаване на дефинирана от потребителя функция - Редактиране на кода на функцията

Функционалният код ще бъде следният: for (int i = 0; i

Фигура 19: Създаване на картографиране с помощта на UDF

На това създаването на картографирането може да се счита за завършено. Сега трябва да тестваме какво имаме.

Тестване на картографиране на съобщения.

Фиг. 20: Тест за картографиране

Отляво попълваме първоначалната структура с тестови стойности. За удобство наборът от стойности може да бъде запазен - щракнете върху бутона "Създаване на тестов екземпляр":

Фигура 21: Създаване на тестов екземпляр

Задайте името на този тестов пакет и го запазете.

Фигура 22: Задаване на техническо име за тестов случай

Нека стартираме теста сега:

Фиг.23: пробно стартиране

Фиг.24: резултат от теста

Като цяло, при създаването на Message Mapping има една тема, която изисква отделен анализ - това е концепцията за контекста и свързаните с него функции от групата "Node Functions". В рамките на основите тази тема е разкритатвърде рано, нека го оставим за по-труден етап.

Навигация на публикации

3 мнения относно „ SAP PI – Изграждане на асинхронен интерфейс. Част 4: чудеса на трансформация или картографиране. ”

Добър ден Благодаря за толкова информативен блог!

Mapping въпрос - имаме ли нужда от MessageMapping обект в скрипта, ако изходящото и входящото съобщение съгл. интерфейси от един и същи тип (отнасящи се до същия MessageType)? Възможно ли е да се направи без MessageMapping в този случай?

Благодаря ти за милите думи. )

Да, ако изходящите и целевите съобщения се отнасят за един и същ тип съобщение, картографирането може да бъде пропуснато и нищо не може да бъде посочено в полето „картографиране“ в правилата за маршрутизиране.

---