SAP BAPI Connector
Наконец-то нашлось время написать об ещё одном варианте SAP коннектора, который также активно используется в работе!
Итак, встречаем: SAP BAPI Connector!
SAP BAPI Connector работает с функциональными модулями в SAP.
Функциональный модуль (ФМ, он же FM) — код ABAP, оформленный в виде отдельной функции, которая может быть повторно использована в других разработках.
Имеет два вида параметров:
Как раз с этими параметрами и работает коннектор, передает определенные значения на вход и получает запрашиваемый результат.
Импортируемые параметры могут быть как определенными значениями или переменными, так и таблицами. Результат обычно в виде таблицы.
Использование SAP BAPI Connector
Мы используем SAP BAPI коннектор в двух случаях:
Так как на таблицы SAP у нас есть строго только права для чтения, этот функционал оказался очень удобной возможностью для взаимодействия QlikView и SAP.
Теперь по шагам расскажу о каждом из двух случаев.
Создание коннекта и получение данных из ФМ SAP
Для начала нужно создать строку коннекта.
Выбираем среди вариантов коннекта QvSAPBAPIConnector (при наличии установленного SAP коннектора)
Специалисты SAP с удовольствием сообщат необходимые параметры, остается нажать Test Connection:
При корректном заполнении получим:
Далее переходим в режим работы с функциональными модулями и нажимаем на кнопку BAPI:
В появившемся окне последовательно выполняем действия:
В полученном скрипте вместо значений параметра можно указать переменные.
Как результат получаем таблицу ET_CALENDAR_TB и далее либо используем её при построении ассоциативной модели, либо выгружаем данные в файл формата qvd.
Передача данных в SAP с помощью BAPI Connector
Этот случай мне кажется более интересным и необычным, поэтому подробно его рассмотрим.
Примерный алгоритм работы для передачи данных в виде таблицы в качестве параметра при использовании SAP BAPI Connector таков:
Пример
Давайте разберём на примере передачи данных в SAP по приходам денежных средств от инкассаций.
У нас есть таблица Result, которую нам надо передать в SAP:
Result:
Это самый большой пункт!
Во-первых, нам нужно узнать у специалистов SAP структуру таблицы, в которую будут заливаться данных.
Структура целевой таблицы SAP в данном случае такова:
MANDT, — номер манданта
BUKRS, — наименование балансовой единицы
KUNNR, — номер магазина
WRBTR, — сумма в валюте
HBKID — банк зачисления
У нас есть не все столбцы, поэтому недостающие столбцы создаём самостоятельно, остальное преобразуем. В итоге получаем такой код:
Так как логика выгрузки была такой, чтобы мы перезаписывали обновленные значения на будущие даты, возникла необходимость добавить одну проверку, на случай, если в новой выгрузке нет данных по каким-либо магазинам. Данную проверку можно реализовать и на стороне SAP, мы же сделали в QlikView таким образом:
Num(Дата_прихода_корр) & ‘|’& ApplyMap(‘BankNameMap2’, Банк_план) &’|’& ПФМ as ПФМ_БАНК_ДАТА
Concatenate (T1)
LOAD
If(isNum(KUNNR), Num(KUNNR),KUNNR) as KUNNR,
HBKID,
100 as MANDT,
‘RUB’ as WAERS,
‘BSTP’ as BUKRS,
0 as WRBTR,
Year(BUDAT)&Num(Month(BUDAT),’00’)&Num(Day(BUDAT),’00’) as BUDAT
Where not Exists(ПФМ_БАНК_ДАТА, Num(BUDAT)&’|’& HBKID &’|’& If(isNum(KUNNR), Num(KUNNR),KUNNR));
SELECT
KUNNR,
HBKID,
WRBTR,
BUDAT
From Z_TABLE_IN_SAP
WHERE BUDAT >= ‘$(vTodayYear)$(vTodayMonth)$(vTodayDay)’;
Подготовка данных завершена, но это еще не все.
Теперь нужно преобразовать их для дальнейшей передачи в функциональный модуль.
Данные передаются в функциональный метод следующим образом (часть скрипта для поля MANDT):
«table»:
[
<
«field»:»MANDT»,
«length»:3,
«type»:»CHAR»,
«values»:
[ «100» ]
>,
Внутри фигурных скобок мы должны передать все значения. Чтобы сделать это за одну команду, мы нашли такое решение — использовать переменные.
В качестве разделителя нужно использовать «,».
На примере поля BUDAT:
LET vMandt = Peek(‘MANDTx’); //Присваиваем переменным значения полей для дальнейшей загрузки в SAP
LET vBukrs = Peek(‘BUKRSx’);
LET vBudat = Peek(‘BUDATx’);
LET vKunnr = Peek(‘KUNNRx’);
LET vWaers = Peek(‘WAERSx’);
LET vWrbtr = Peek(‘WRBTRx’);
LET vHbkid = Peek(‘HBKIDx’);
Производим коннект, как в предыдущем примере.
В данном случае, в качестве входного параметра представлена таблица:
Для примера и лучшего понимания заполним несколько записей, нажав на строку с таблицей:
Нажимаем Add call to script
В полученном скрипте остается заменить значения в квадратных скобках на созданные ранее переменные!
«field»:»KUNNR»,
«length»:10,
«type»:»CHAR»,
«values»:
[ «555», «777» ]
«field»:»KUNNR»,
«length»:10,
«type»:»CHAR»,
«values»:
[ «$(vKunnr)» ]
Важно: поставить переменную в кавычках.
Заметки:
Возможности SAP BAPI Connector оказались очень востребованы, мы смогли перенести в отчёты QlikView некоторые полезные отчёты напрямую из функциональных модулей, а возможность передачи таблицы в качестве параметра позволила отказаться от схем с выкладыванием файлов на сетевые папки. Стабильность, скорость и гибкость передачи данных увеличились.
ABAP Blog
Все о разработке в решениях от SAP
ABAP Blog
Все о разработке в решениях от SAP
Ссылки
Цитаты
Технические навыки — это мастерство сложности, а творчество — мастерство простоты. // E. Zeeman
Новое
Последние комментарии
Remote Function Call
Remote Function Call (RFC, удалённый вызов функций) – стандартный интерфейс для обмена данными между SAP и не SAP системами. Интерфейс передачи данных основан на CPI-C или TCP/IP. Стандартная справка по теме RFC или курс BC415.
Особенности RFC функций
Настроить назначение для RFC вызова можно через транзакцию SM59 (Таблица RFCDES). Подробнее о настройке RFC соединений можно посмотреть в курсе BC415.
Назначение RFC вызовов
Назначение RFC вызова определяется с помощью ключевого слова DESTINATION. В качестве параметра может принимать имя удаленной системы, SPACE, NONE, BACK.
Обработка исключений при вызовах RFC
При вызове RFC модуля могут возникать следующие исключения:
Типы RFC функций:
В случае, когда вы вызываете несколько sRFC подряд из одной группы функций, глобальные данные группы функций будут доступны до тех пор, пока не будет вызвана последняя функция из данной группы.
Если в sRFC внутри себя вызывает CALL SCREEN, CALL TRANSACTION или отображение списка, вызываемые экраны будут отображены в программе запустившей sRFC, но только если в SM59 указан диалоговый удаленный доступ, иначе система выдаст исключение SYSTEM_FAILURE.
Процедура не должна иметь в своем теле операторы, прерывающие выполнение программы, такие как: CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, RFC вызовы, сообщения с типами W и I.
Пример программы запускающей 2 aRFC функции и ожидающей выполнение обоих:
Если в качестве имени задачи в вызове aRFC указать TASK3, условия выполнены не будут.
Пример распараллеливания вычислений с помощью групп:
aRFC вызовы так же как и sRFC могут вызывать внутри себя диалоги, но их использование в данном контексте выглядит сомнительно, более подробно рассмотрено в курсе (BC415).
Все tRFC вызовы сохраняются в таблицах: ARFCSSTATE и ARFCSDATA. Если вы не хотите вызывать tRFC немедленно после COMMIT WORK, вы можете вызвать ФМ START_OF_BACKGROUNDTASK (до COMMITWORK) и задать время и дату запуска для накопленных tRFC вызовов.
После выполнения COMMIT WORK в случае успешного локального обновления (в рамках LUW основной программы), накопленные данные создают фоновую задачу, в случае успешного выполнения этой задачи все данные из таблиц tRFC удаляются. Если задача не была выполнена, срабатывает механизм повтора или отката.
Так, например если связь с удаленной системой не была установлена, срабатывает автоматический повтор выполнения задания. По умолчанию количество повторов равно 30, интервал ожидания равен 15 минутам.
В случае если во втором из двух tRFC вызовов произошел сбой, сообщение с типом A или X или вызов исключения через RAISE после успешного выполнения первого происходит следующее:
Для принудительного отката всех изменений или отмены tRFC-LUW служит ФМ — RESTART_OF_BACKGROUNDTASK.
В случае если вызовы tRFC происходят на разных системах (DESTINATION ‘A’, DESTIONATION ‘B’), для каждой из них создается свой tRFC-LUW, вызовы tRFC группируются в зависимости от назначения.
Для вызова tRFC отдельно от остальных можно воспользоваться ключевым словом: AS SEPARATE UNIT.
Каждый tRFC-LUW имеет свой уникальный ID, для его получения можно использовать ФМ: ID_OF_BACKGROUNDTASK (вызывать перед COMMIT WORK). Используя данный ID можно определить статус для tRFC-LUW через ФМ — STATUS_OF_BACKGROUNDTASK.
Для размещения tRFC вызовов в порядке FIFO (первый пришел, первый вышел) необходимо перед каждым tRFC вызовом указывать имя очереди, делается это с помощью ФМ: TRFC_SET_QUEUE_NAME:
Имя очереди может содержать 24 символа, исключая % и *.
Для администрирования qRFC вместо транзакции SM58 используется транзакция — SMQ1. Таблица, в которой хранятся данные qRFC — TRFCQOUT.
Более подробная информация о bgRFC находится тут.
Транзакции, используемые при работе с RFC
BAPI функции
Для обмена бизнес данными, между SAP и не SAP системами, был создан так называемый Business Framework. Центральной его частью является хранилище бизнес объектов (BOR – Business Object Repository). Каждый бизнес объект обеспечивает объектно-ориентированный подход к хранению бизнес данных и работы с бизнес процессами. Например, вызывая методы бизнес объектов, мы тем самым манипулируем бизнес данными, за которые он отвечает, не заботясь о техническом вопросе (связях в таблицах и т.п.)
Бизнес объект состоит из следующих частей:
BAPI – реализация метода бизнес объекта, представляет собой функциональный модуль RFC. BAPI могут вызываться как синхронно (COMMIT WORK AND WAIT), так и асинхронно т.е. ожидая выполнения работы функции или нет.
BAPI могут представлять различные действия над объектом:
BAPI могут вызываться из различных приложений: офисных приложений (через VBA), JAVA и С++ программ и т.п.
Все BAPI после своей работы возвращают результат в виде внутренней таблицы с одной из структур: BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2, BAPIRET1_FIX. В связи с этим в BAPI нет обработки исключений как в стандартных ФМ. Все эти структуры содержат в себе следующие поля:
Если транзакция выполнена успешно, то в таблице RETURN не будет существовать записей с типом ошибки «Е». Должно присутствовать сообщение с типом ошибки «S».
Обновление в BAPI всегда происходит в IN UPDATE TASK (см. документацию по ключевому слову IN UPDATE TASK или курс по обновлению БД – BC414). Внутри BAPI никогда не вызывается COMMIT WORK. Для подтверждения или отката LUW всегда должны использоваться ФМ: BAPI_TRANSCATION_COMMIT, BAPI_TRANSACTION_ROLLBACK, разница между данными ФМ и COMMIT WORK (ROLLBACK WORK) в том что они чистят внутренние переменные используемые при вызовах BAPI, если этого не делать могут возникать проблемы при повторном вызове BAPI. Все BAPI вызванные в программе до вызова BAPI_TRANSCATION_COMMIT (BAPI_TRANSCATION_ROLLBACK) вызываются в одном LUW. Для просмотра всех имеющихся в системе BAPI служит транзакция BAPI (запускает BAPI EXPLORER).
Курс, в котором рассматривается создание собственных BAPI — BC417.
Транзакция LSMW инструкция по применению. Часть 7
Транзакция LSMW инструкция по применению
Башкатов Олег Викторович
В этой книге приводятся практические решения задач с использованием транзакции
LSMW для загрузки данных на основе методов Batch Input, BAPI и
Direct Input. Примеры базируются на бизнес-сценарии миграции данных.
Загрузка остатков ОЗМ методом BAPI в транзакции LSMW
Продолжение книги.
В этой главе будет описано использование BAPI-метода на примере загрузки остатков (создание документов материала 561 видом движения). В основе подхода лежит использование типа сообщения MBGMCR, который вызывает BAPI_GOODSMVT_CREATE. BAPI-метод уже был подробно описан в главе 2, поэтому в настоящей главе не будут описываться шаги подробно, а детальное описание будет уделено новой информации. В решении бизнес-задачи мы находимся на этапе загрузки остатков по созданным ОЗМ (рис. 5.1). В примере будет показано, как создать множество документов материалов с несколькими позициями, используя один входной файл.
Рис. 5.1. Задача загрузки остатков в общей схеме задач миграции
Задача состоит в загрузке начальных остатков по разным субсчетам счета запасов (10-го счета в плане счетов Минфина РФ). В главе будет показан пример использования одного файла для двух входных структур (использование опции Identifying Field Content); будет показан пример использования маски в имени файла (Wildcard option); пример создания и применения параметра селекционного экрана, а также примеры дополнительного ABAP-кода посредством user-defined routines и работа с полями типа DDMY (дата) и AMT1 (сумма).
5. 1. Операционные условия
Требуется прогрузить остатки на склад с помощью 561-го вида движения на основные записи материалов; при этом нужно обеспечить загрузку нескольких позиций документов материала с помощью одного входного файла; также необходимо сделать возможным параллельную загрузку по разным субсчетам (чтобы для разных субсчетов был свой файл на сервере). Вводные данные для загрузки представлены в таблице 5.1. Для загрузки нескольких позиций в документе материала нам нужно использовать две структуры-источника. Однако для этих двух структур мы можем использовать один файл с данными. Для этого часть полей нам придется задублировать в структурах, но дублирования данных при этом не будет.
Табл. 5.1. Используемые переменные поля для загрузки остатков
Пройдемся вручную через MIGO по полям документ материала, обозначенным в таблице 5.1, и создадим документ материала. Созданный документа материала представлен на рис. 5.2.
Рис. 5.2. Создание документа материала для начальной загрузки остатков
5.2. Пошаговое решение задачи
Шаг 1: создание/выбор проекта, подпроекта и объекта
Для создания нового проекта транзакции LSMW будем использовать данные из таблицы 5.2.
Табл. 5.2. Данные для создания объекта LSMW
После указания данных подтверждаем ввод и запускаем проект. Система откроет перед нами основное меню транзакции LSMW.
Шаг 2: параметры метода загрузки: выбор объекта и метода
Дважды щелкаем по пункту меню Maintain Object Attributes. В качестве объекта метода Business Object выбираем BUS2017 (Goods Movement), метод — CREATEFROMDATA (Post Goods Movement) (рис. 5.3).
Рис. 5.3. Указываем объект и метод для использования BAPI-метода
Сохраняем и выходим к обзору списка шагов, чтобы перейти к следующему шагу.
Шаг 3: создание структуры источника [данных]
Переходим к пункту Maintain Source Structures. Создаем структуры ZDOCHEAD (Заголовок документа материала) и ZDOCITEM (Позиции документа материала). Система отобразит экран, как на рис. 5.4. Затем сохраняем и выходим, чтобы перейти к следующему шагу.
Рис. 5.4. Созданная структура загрузки данных
Шаг 4: ведение полей структуры источника [данных]
Щелкаем дважды по пункту Maintain Source Fields. Ставим курсор на структуру ZDOCHEAD (Заголовок документа материала) и нажимаем на кнопку Table Maintenance (рис. 5.5). Поля для структур ZDOCHEAD и ZDOCITEM приведены в таблице 5.3. При заполнении типов данных полей обратим внимание, что для даты имеется три формата DDMY, DMDY, DYMD, при этом каждый из форматов может быть как с разделителем, так и без него. Для суммы имеется четыре формата: AMT1, AMT2, AMT3, AMT4. Из описания видно, чем отличаются форматы (рис. 5.6).
Табл. 5.3. Поля структуры источника ZDOCHEAD (заголовок документа материала)
Рис. 5.5. Используем ввод через таблицу (Table Maintenance)
Рис. 5.6. Пояснение к форматам даты и суммы в транзакции LSMW
После заполнения данных касательно полей структур система отобразит экран, как показано на рис. 5.7.
Рис. 5.7. Входные структуры с полями
На этом шаге нам нужно заполнить атрибут Identifying Filed Content в заголовочной и позиционной структурах. Это поле позволит нам использовать один файл для двух структур. Использование одного файла удобнее и надежнее, чем использование двух. Поле, которое позволит нам различить заголовок и позицию, будет HEAD_OR_ITEM. Дважды щелкаем по этому полю для структуры ZDOCHEAD, система отобразит экран, в котором мы укажем значение для поля Identifying Field Content — HEAD (рис. 5.8).
Рис. 5.8. Заполнение поля Identifying Field Content для структуры ZDOCHEAD значением HEAD
Затем проделаем похожие действия, но для структуры ZDOCITEM поля HEAD_OR_ITEM. Дважды щелкнем по этому полю и укажем значение для поля Identifying Field Content — ITEM (рис. 5.9).
Рис. 5.9. Заполнение поля Identifying Field Content для структуры ZDOCITEM значением ITEM
Нам необходимо вывести поле TESTRUN на селекционный экран. Для этого дважды щелкаем по полю TESTRUN в структуре ZDOCHEAD и отмечаем галкой атрибут Selection Parameter for Import/Convert Data (рис. 5.10).
Рис. 5.10. Обозначаем поле в качестве селекционного параметра экрана
В основном экране шага сохраняем данные и выходим к обзору шагов, чтобы перейти к следующему шагу.
Шаг 5: соответствие структур источника данных и записи
Дважды щелкаем по шагу Maintain Structure Relations. Создаем соответствие структур, как показано на экране (рис. 5.11). Сохраняем, выходим, переходим к следующему шагу.
Рис. 5.11. Присвоение структуры входного файла и внутренних структур и структур типа сообщения
Шаг 6: мэппинг (соответствие) полей источника [данных] и полей структур BAPI и User-defined routines
Дважды щелкаем по шагу Maintain Field Mapping and Conversion Rules. На данном шаге производим мэппинг полей входного файла и структуры BAPI. Предварительно с помощью кнопки Layout откроем дополнительные области, где можно указать ABAP-код (рис. 5.12).
Рис. 5.12. Открываем поля для дополнительного ABAP-кода
Пройдемся по блокам и полям и произведем мэппинг; данные для мэппинга приведены в таблицах 5.4.а–5.4.б.
Табл. 5.4.а. Мэппинг полей структур BAPI и входного файла
Табл. 5.4.б. Мэппинг полей структур BAPI и входного файла
Чтобы присвоить фиксированное значение (Fixed Value) полю, нужно поставить курсор на поле и нажать на кнопку Fixed Value, в открывшемся поле ввести переменную (если она не существует, то система предложит создать ее) (рис. 5.13).
Рис. 5.13. Указание Fixed Value (фиксированного значения) для поля
Также заметим, что мы можем вести подпрограммы для всего проекта (так называемые user defined routines) и ABAP-routines для конкретного загрузчика, которые доступны в самом конце загрузчика (рис. 5.14).
Рис. 5.14. Место в загрузчике для ABAP-подпрограмм, специфичных для отдельного объекта LSMW (загрузчика)
В нашем случае мы будем создавать подпрограмму, общую для всего проекта, то есть в пункте меню Maintain Fixed Values, Translations, User-Defined Routines (рис. 5.15).
Рис. 5.15. Пункт меню Maintain Fixed Values, Translations, User-Defined Routines
Мы сослались на несколько фиксированных значений (Fixed Value) и одну подпрограмму (User defined routines). Чтобы задать значение для Fixed Value, нужно поставить курсор на нужное Fixed Value и нажать пиктограмму Change / Изменить (рис. 5.16), затем ввести нужное описание и значение.
Рис. 5.16. Задаем описание и значение для FixedValue TARGET_PLANT
Данные по остальным фиксированным значениям (Fixed Value) приведены в таблице 5.5.
Табл. 5.5. Данные по фиксированным значениям (Fixed Value)
Обратим внимание, что на экране фиксированное значение может идентифицироваться, например, как MOVE_CODE, а вот обращение к ней в программе происходит по имени переменной fv_move_code (то есть добавляется префикс fv).
Теперь переходим к определенной пользователем подпрограмме SKIP_RECORD. Назначение этой подпрограммы — правильно указать системе, что текущую запись нужно пропустить. В нашем случае запись — это позиция документа материала, а транзакция — весь документ материала. Мы пропускаем весь документ материала в случае, если единица измерения на входе отсутствует хотя бы в одной позиции. Ставим курсор на нужную нам User-Defined Routines и переходим к изменению с помощью пиктограммы Change / Изменить (кнопка с карандашом) (рис. 5.17).
Рис. 5.17. Переходим к редактированию подпрограммы skip_rec
Обратим внимание, что техническое имя подпрограммы — ur_SKIP_REC. Нужный код для подпрограммы приведен в таблице 6. Обратим внимание и на то, что ни одну из переменных мы не определяем. Переменные g_skip_record, g_transfer_record, g_skip_transaction и g_transfer_transaction специально служат для целей пропуска записей и определены глобально; равно как и константы yes и no (таблица 5.6).
Табл. 5.6. Код для user-defined routines SKIP_REC
Затем сохраняем и переходим к основному меню транзакции LSMW (рис. 5.18).
Рис. 5.18. Сохранение user-defined routines
Рис. 5.19. Проверка синтаксиса программы
В случае наличия ошибок система откроет ABAP-редактор, в котором необходимо снова запустить проверку программы, и тогда система явно укажет, в чем ошибка. В нашем случае ошибок нет, но сообщение могло бы выглядеть, как показано на рис. 5.20.
Рис. 5.20. Пример сообщения об ошибке в ABAP-редакторе
Теперь можно переходить к следующему шагу для указания входного файла и его параметров.
Шаг 7: указание пути к файлу
Прежде чем указывать путь к файлу, необходимо создать файлы по нужному нам формату. Для создания входного файла будем использовать Excel. Первую строку в Excel заполним техническими именами полей входной структуры. А строки, начиная со 2-й, заполним уже конкретными значениями. В нашем случае у нас может быть несколько входных файлов, так как данные по каждому субсчету мы будем хранить в отдельном файле. Для разделения файлов мы будем использовать Wildcard. При этом для заполнения заголовка и позиций документа материала мы будем использовать один и тот же файл. На рис. 5.21 показан файл для загрузки субсчета 10–01, а на рис. 5.22 показан файл для загрузки субсчета 10–08. Как видно, формат файлов одинаков, но данные в них разные и контроль за данными также будет осуществляться по-разному.
Рис. 5.21. Пример заполнения входного шаблона по субсчету 10–01 (сырье и материалы)
С помощью атрибута HEAD_OR_ITEM мы сделали разделение строк на данные заголовка и данные позиции. Таким образом, мы можем использовать один и тот же файл для наполнения данных заголовка и данных позиций и при этом загружать более чем одну позицию в документе материала. А за счет того что часть столбцов мы продублировали в позиционной структуре, мы можем себе позволить вести файл в табличном формате. Дважды щелкнем по Specify Files (рис. 5.22).
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
