Интеграция с продуктами SAP через вызовы RFC-функций
Подключение
Для подключения к SAP RFC используется SAP.Net Connector 3.0. Важной частью является наличие библиотек sapnco.dll и sapnco_utils.dll. Для получения данных библиотек обратитесь в SAP Market Place, при этом вы должны иметь идентификатор пользователя и пароль для скачивания. Если идентификатор и пароль отсутствуют, то обратитесь к специалистам SAP Basis за помощью в получении указанных библиотек. Разрядность используемой версии «Форсайт. Аналитическая платформа» должна быть такой же, какую имеют полученные библиотеки.
Если всё для использования SAP.Net Connector 3.0 имеется, то выполните следующие действия:
Добавьте ссылку на библиотеки SAP sapnco.dll и sapnco_utils.dll:
Добавьте код для подключения к SAP и вызова различных RFC-функций, указанный ниже.
Код для работы с RFC-функциями
При запуске процедуры Main выполняется два действия:
Вызывается процедура Connection, которая осуществляет подключение к серверу SAP.
Вызывается функция executeSAPFunction, которая выполняет RFC-функцию и возвращает результат. Список параметров, формируемых в переменной SAPParams, а также наименование RFC-функции и наименование возвращаемой таблицы, указываемые в процедуре executeSAPFunction, должны соответствовать сигнатуре вызываемой RFC-функции.
Результат выполнения функции будет доступен в переменной DataTable и в дальнейшем может быть использован для получения и обработки данных с помощью различных инструментов «Форсайт. Аналитическая платформа».
Public Class StartParams Private m_Metabase: Prognoz.Platform.Interop.Metabase.IMetabase; Public Property Metabase: Prognoz.Platform.Interop.Metabase.IMetabase Get Begin Return m_Metabase End Get Set Begin m_Metabase := Value; End Set End Property Metabase; End Class ;
Public Class Program Public Shared ConfigInitialized: boolean; Public Shared rfcDestination: RfcDestination;
Private Shared Sub Connection(); Var config: IDestinationConfiguration; Begin If Not ConfigInitialized Then config := New SAPDestinationConfig(); config.GetParameters( «TEST» ); RfcDestinationManager.RegisterDestinationConfiguration(config); ConfigInitialized := True ; End If ; rfcDestination := RfcDestinationManager.GetDestination( «TEST» ); rfcDestination.Ping(); End Sub ;
Private Shared Function executeSAPFunction(functionName: string; resultTableName: string; Paramarray params: array Of SAPParam): IRfcTable; Var func: IRfcFunction; Begin func := getSapFunction(functionName, params); Try func.Invoke(rfcDestination); Return func.GetTable(resultTableName); Except On e: RfcBaseException Do System.Diagnostics.Debug.WriteLine(e.Message); Finally End Try ; End Function ;
Private Shared Function getSapFunction(functionName: string; Paramarray params: array Of SAPParam): IRfcFunction; Var func: IRfcFunction; param: SAPParam; Begin func := rfcDestination.Repository.CreateFunction(functionName); For Each param In params Do func.SetValue(param.name, param.value); End For ; Return func; End Function ; End Class ;
Public Class SAPParam Public name: string; Public value: object;
Public Constructor SAPParam(_name: string; _value: object); Begin name := _name; value := _value; End Constructor ; End Class ;
Class SAPDestinationConfig: IDestinationConfiguration Public Function ChangeEventsSupported(): boolean; Begin Return False ; End Function ;
RFC (Remote Function Call) — протокол обмена данными между системами (подробно о SAP RFC написано в курсе BC415). RFC применяются для интеграции SAP и не SAP систем, обработки данных в новой сессии, параллельной обработки данных и т.п.
Классификация RFC
Вызывать по RFC можно любой функциональный модуль, который объявлен как «дистанционный».
Целевая система
Целевая система определяется с помощью DESTINATION dest, где dest — название RFC соединения. Для настройки RFC соединений используется транзакция SM59. Если в качестве dest передать пустую строку, то функция будет выполнена локально. В качестве dest можно передать ‘NONE’ или ‘BACK’.
Исключения
В RFC функциях, помимо запрограммированных исключений, можно обработать системные исключения:
Примечание Системные исключения COMMUNICATION_FAILURE и SYSTEM_FAILURE можно объявить с MESSAGE msg. Тогда, при наступлении исключения в msg вернется любое сообщение из целевой системы.
Синхронный RFC (sRFC)
При синхронном вызове RFC, рабочий процесс приостанавливает свою работу пока вызываемый модуль не завершит свою работу. Вызов выполняется в отдельном DB LUW. При вызове sRFC в основном процессе происходит неявный COMMIT. Поэтому вызовы sRFC не должны находиться между OpenSQL операторами, обновляющие БД. При повторном вызове sRFC, глобальные данные группы функций вызываемого ФМ будут доступны до тех пор, пока не будет закрыто указанное соединение. Если в sRFC вызывает CALL SCREEN, CALL TRANSACTION или отображение списка, то вызываемые экраны будут отображены в программе запустившей sRFC, но только если в настройках соединения разрешен диалоговый удаленный доступ, в противном случае возникнет исключение SYSTEM_FAILURE.
Пример ниже демонстрирует синхронный вызов RFC и обработку возможных видов исключений.
Результат
Аинхронный RFC (aRFC)
Пример ниже демонстрирует вызов нескольких aRFC и возврат результата в основной процесс. Функциональный модуль Z_TEST_RFC взят из примера sRFC.
Для установки сервиса SAP RFC необходимо выполнить следующие действия.
Скопируйте файлы из поставки Продукта (содержимое папки SapRfc Windows Service ) в созданную папку.
Сервис SAP RFC может работать под локальной учетной записью, либо от имени пользователя, имеющего права локального администратора на сервере.
Удаление сервиса SAP RFC¶
Настройка подключения к SAP RFC¶
Перед запуском сервиса SAP RFC необходимо настроить конфигурационный файл appsettings.json в папке компонента.
Для этого укажите (измените) параметры:
ApiConnectAddress – адрес REST API Продукта;
Login – имя пользователя Продукта;
Password – пароль пользователя Продукта.
Пример конфигурационного файла:
Настройка служб соединения¶
Таблица 67 Список служб соединения ¶
# SAP System Message Server Port
# SAP System Dispatcher Port
# SAP System Gateway Port
# SAP System Dispatcher Security Port
# SAP System Gateway Security Port
Настройка логирования¶
Для настройки логирования используется конфигурационный файл NLog.config в папке компонента.
Настройки аналогичны настройкам ИМ (см. раздел Настройка логирования ).
Запуск и остановка сервиса SAP RFC¶
Создание сервисного пользователя XDERFCUSER¶
В системе SAP должен быть создан сервисный пользователь XDERFCUSER с постоянно действующим паролем. Для создания сервисного пользователя необходимо выполнить следующие действия.
Откроется страница Ведение пользователей: первый экран. Введите техническое имя пользователя и нажмите (Создать).
В открывшемся окне Ведение пользователей на закладке Адрес заполните соответствующие поля данными о пользователе, указанными в таблице ниже.
Перейдите на закладку Данные входа и заполните соответствующие поля данными, указанными в таблице ниже.
Таблица 68 Данные о сервисном пользователе XDERFCUSER ¶
TerraLink xDE (заполняется автоматически)
Закладка Данные входа
Создание RFC-адреса назначения TERRALINK_XDE¶
Для осуществления двухстороннего взаимодействия с ИМ необходимо создать RFC-адрес назначения TERRALINK_XDE.
Сервис ИМ должен быть запущен до создания RFC-адреса назначения.
Для создания RFC- адреса назначения необходимо выполнить следующие действия.
SAP ALE — Application Link Enabling — технология обмена данными, разработанная компанией SAP AG. Технология, потому что это набор инструментов, протоколов, форматов, которые позволяют обмениваться данными в режиме реального времени или оффлайн режиме между САП и не-САП системами. Это огромный пласт настроек, функциональности и возможностей, которыми мы редко пользуемся. Предлагаю рассмотреть технологию комплексно в виде стека.
CPIC — Common Programming Interface for Communication — низкоуровневый коммуникационный протокол. Почитать можно вот тут https://www-01.ibm.com/software/network/commserver/windows/library/cpic.htm RFC — Remote Function Call — высокоуровневый коммуникационный протокол удаленного вызова tRFC (tansactional RFC) / qRFC (queued RFC) / aRFC (asynchronous RFC) / sRFC (synchronous RFC) — способ доставки сообщения до получателя и подверждения факта доставки IDOC — Intermediate DOCument / BAPI (Business Application Programming Interface) — формат сообщения, которое будет доставлено EDI — Electronic Data Interchange — процедура обмена данными SAP-nonSAP. Международные стандарт по-совместительству. ALE — Application Link Enabling — процедура обмена данными SAP-SAP.
Вот это и предлагаю обсудить, а спецам меня поправить. RFC — Remote Function Call, механизм для удаленного вызова функций в системах. Идея простая и заключается в том, что, если мы знаем имя какой-то функции на удаленном сервере, то мы можем сказать: «Привет, удаленный сервер. Я знаю, что у тебя есть вот такая функция, с такими параметрами. Я хочу ее запустить _у тебя_. Вот мои полномочия, вот мои данные для этой функциий, запусти и скажи, что получилось». Удаленный сервер чешет черепушку, шуршит дисками и, удостоверившись, что это не Баба-Яга, запускает у себя, на своих данных эту функцию под логином просящего. При этом программа на том же сервере может запустить эту же самую функцию локально, как бы у себя дома. Наличие галочки в транзакции SE37 для функционального модуля определяет, можно ли запускать эту функцию удаленно или нет.
Допустим мы определили что вызывать: программу или функциональный модуль. Теперь нужно решить как ее вызывать: транзакционно, синхронно, асинхронно, в очереди.
Зачем я все это вам пишу? Чтобы HR консультант понимал начинку того, что он настраивает, как он и что он должен написать в спеке программисту, ибо порядок обработки данных во внешних системах это бизнес-требование.
Поехали дальше. IDOC это структура данных, которая может быть представлена в виде плоского файла, XML, CSV, JSON, котика или любого другого формата. Структура состоит из трех частей:
Как у нас концептуально происходит процедура обмена информацией между системами? По событию или расписанию запускается программа выгрузки данных по HR (для примера). Либо по указателям изменений, либо вручную через PFAL вызывается функциональный модуль, который создает IDOC — на основании селекционного экрана, выбранных данных собирает все и заполняет все структуры IDOC.
Дальше система смотрит на модель распределения в BD64. У каждого IDOC есть свой тип сообщения, который мы указываем в модели распределения по принципу:
система отправитель — система получатель — тип сообщения — фильтры. Если все условия совпали, то IDOC помещается в очередь на отправку в указанную систему. Причем система это не всегда SAP, а виртуальный контейнер — логическая система, под которой может быть SAP, котик, Share Point или еще что угодно.
Согласно настройке партнера (об этом позже) уже на входящей стороне система определяет какой же функциональный модуль вызвать для обратного преобразования из IDOC в живые данные. Этот обработчик получает на вход IDOC и создает из них данные (где с помощью других функциональных модулей, а где напрямую — зависит от логики и данных).
Если идет удаленный вызов BAPI, то система также по модели распределения ищет кому приписан такой BAPI вызов, а затем осуществляет qRFC вызов или sRFC. Так, например, работает проверка FICO параметров при проводках в заработной плате.
Это очень упрощенно. Отдохнули?
Теперь возьмем скальпель.
IDOC — сегмент — поле, такова структура IDOC. Сам IDOC определяется типом сообщения (HRMD_A, транзакция WE81). Тип сообщения в зависимости от версии системы ссылается на тип IDOC (транзакция WE82).
Тип IDOC состоит из двух частей (транзакция WE30):
Рекламная пауза: создаем расширение IDOC:
Нужно не забыть наполнить этот сегмент данными. Это можно сделать с помощью user-exits или BAdI (смотрите в конце заметки). Нужно не забыть, что при нормальной передачи SAP — SAP данные в сегменте как записываются исходящей системой (один кусок кода), так и обрабатываются принимающей системой (второй кусок кода). Этот код нужно написать самим, а не дать угадывать системе. Для входящих айдоков нужно в транзакции WE57 указать, что IDOC был расширен на такой-то сегмент, поэтому его нужно обрабатывать тем же функциональным модулем (который в свою очередь расширен нижеукзанными user-exits или BAdI).
Допустим мы завершили наполнение IDOC данными. Умеем его наполнять, умеем распаковывать и создавать данные. Осталось самое простое — послать его куда подальше.
Для определения маршрута, куда бы его послать, существует несколько терминов, которые нужно понять, сосредоточить в едином поле и выразить в настройке. Это партнер, порт и модель распределения.
Партнер это отправитель или получатель (WE20). Порт — средство передачи IDOC (WE21). Модель распределения — маршрут, по которому система будет искать, как доставить сообщение от отправителя к получателю (BD64). Центр управления полетами — транзакция BD87.
Открываем WE21 для настройки портов. Здесь мы видим несколько вариантов, например, tRFC (отматываем повыше, чтобы вспомнить, о чем речь), File, XML HTTP, XML File, ABAP PI. По названиям несложно догадаться о форматах передачи данных. Для SAP-SAP мы выбираем tRFC и создаем новый порт. При создании система попросит RFC соединение — адрес, куда отправлять данные. Как вы помните, tRFC работает поверх CPI-C, а это значит, что для передачи данных по нестандартным протоколам можно подключить свою библиотеку, зарегистрировать ее как RFC program в SM59, а здесь указать это соединение. В итоге получится порт с отправкой данных через вашу стороннюю библиотеку. Здесь же можно указать, что данные нужно обрабатывать по схеме qRFC с помощью галочки Queue Processing is supported.
Теперь создадим партнеров. Партнер должен быть в исходящей системе для отправки данных и в принимающей для приема. В исходящей системе создаем в транзакции WE20 партнера с типом LS — логическая система. Отправка данных HR будет происходить от имени системы. Обратите внимание на то, что партнер — система приемник, а данные мы пишем в Исходящие. Мы как бы говорим системе, что вот этому партнеру нужно отправлять данные. А для принимающей системы будет наоборот, что вот от этого партнера нужно принимать данные. Чтобы обеспечить целостность в наименовании систем были придуманы так называемые логические системы, которые должны быть уникальны во всем ландшафте ИТ систем, которые интегрируются с САП. Это обязательное требование вендора.
Также создадим партнера в принимающей системе. Только теперь указываем Inbound параметр.
Осталось указать маршрут. Открываем транзакцию BD64 в исходящей системе и создаем вот такую схему для отправки данных из системы ER1 манданта 100 в ER1 мандант 200.
Если после сохранения и попытки распределения (Edit — Model View — Distribute) система вас отругает, то пугаться не стоит. Распределение модели это тоже передача IDOC. Нужно создать партнера для этого.
Открываем транзакцию PFAL и пробуем отправить. Вроде все проходит без ошибок. Так как мы в настройке порта указали, что отправка идет через формирование очереди (то есть не сразу отправляется, а по расписанию), то смотрим в BD87 наш IDOC. Выбираем его и нажимаем кнопку Process для отправки. Все улетело.
А вот во входящей системе в BD87 нас ждет ошибка.
Все дело в том, что я в системе приемнике в данных партнера указал код обработки APLI Inbound IDoc: Individual Processing. А этот код применим для типовых IDOC, но не работает для HR. Для нас есть отдельный HRMD. Код обработки нужны для того, чтобы система могла понять, как обрабатывать входящий IDOC. На один и тот же тип IDOC может быть несколько разных кодов с разной логикой обработки. Например, одни сегменты обрабатывать в единичном случае так, а при пакетном вводе иначе. Меняем в партнере код обработки на HRMD и заново запускаем обработку IDOC уже в системе получателе. Заново отправлять данные не нужно.
Обработка успешно завершается, о чем сигналит зеленый цвет светофора и код статуса обработки.
Описание статусов IDOC можно посмотреть в таблице TEDS1.
В следующие разы мы поговорим о сериализации, фильтрации, конвертации IDOC. Что-то я уже рассказывал, поэтому обобщим и сведем воеидино.
Репост, лайки, шары, решары, донаты и печеньки очень приветствуются. Вам не сложно, а мне приятно 😉
P.S. Принимаются заявки на новые темы 😉
Полезные user-exits и BAdI
•EXIT_SAPLRHA0_001: HR-CA: ALE Outbound Processing With Receiver Enhancement •EXIT_SAPLRHA0_002: HR-CA: Export Parameters for ALE Inbound Processing IDOC_INPUT_HRMD •EXIT_SAPLRHA0_003: HR-CA: Import Parameters for ALE Inbound Processing IDOC_INPUT_HRMD •EXIT_SAPLRHA0_004: HR-CA: ALE Outbound Processing: Control Record •EXIT_SAPLRHA0_005: HR-CA: ALE Inbound Processing: Check Object •EXIT_SAPLRHA0_006: HR-CA: ALE Outbound Processing: Check Object •EXIT_SAPLRHAL_001: HR-CA: ALE Outbound Processing: Change IDoc •EXIT_SAPLRHAL_002: HR-CA: ALE Inbound Processing: Change Infotype Data •EXIT_SAPLRHAL_003: HR-CA: ALE Outbound Processing: Convert Infotype / Segment •EXIT_SAPLRHAL_004: HR-CA: ALE Inbound Processing: Convert Segment / Infotype
BAdI: Inbound Processing for HR Master Data
Business Add-In in inbound processing for HR master data (used in the function module IDOC_INPUT_HRMD).
BAdI: Check/Additional Processing of Object in Inbound Proce
The CHECK_OBJECT method of this Business Add-In enables checks to be performed for an HR object in the RH_IDOC_OBJECTS_SAVE inbound function module. The method is accessed after customer exit SAPLRHA0_005.
BAdI: Customer-Defined Inbound Processing
SAP-internal inbound processing for HR master data:
The system determines which HR objects should be removed from standard processing because no data structures exist for them in the receiving system. Irrespective of the type of receiving system, you can further process these HR objects.
BAdI: Fine Tuning of Original System Mechanism
Business Add-In for Original System Mechanism
BAdI: Outbound Processing HR Master Data
Business Add-In in output processing for HR Master Data (used in the function module RH_MASTER_IDOC_DISTRIBUTE_HRMD).
В информатике существует две реальные проблемы: управление кэшем и присвоение имен.
Фил Карлтон, программист Netscape
Новое
Последние комментарии
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 ANDWAIT), так и асинхронно т.е. ожидая выполнения работы функции или нет.
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.
(Создать).
.
