Remote Function Call (RFC, віддалений виклик функцій) - стандартний інтерфейс для обміну даними між SAP і не SAP системами. Інтерфейс передачі даних заснований на CPI-C або TCP / IP. Стандартна довідка по темі RFC або курс BC415.
Особливості RFC функцій
- Коли ви викликаєте ФМ локально, він працює в тому ж робочому процесі що і зухвала програма. Якщо ви викликаєте ФМ віддалено, він запускається в окремому робочому процесі (Лер - LUW, логічна одиниця роботи) якщо віддалена система є R / 3 системою.
- Як віддаленої системи можуть бути R / 3 система, R / 2 система або інша зовні не SAP система, для НЕ SAP систем існує спеціальна RFC-SDK бібліотека, за допомогою якої може бути реалізований клієнт-сервер для RFC.
- При виклику RFC модуля, в програмі його викликає спрацьовує неявний DB Commit (виняток tRFC, qRFC, bgRFC). Тому виклики RFC не повинні знаходитися між OpenSQL операторами.
- В інтерфейсі ФМ RFC необхідно явно визначати тип для кожного параметра, посилання (LIKE) заборонені.
Призначення RFC викликів
Призначення RFC виклику визначається за допомогою ключового слова DESTINATION. Як параметр може приймати ім'я віддаленої системи, SPACE, NONE, BACK.
- SPACE - локальний виклик ФМ (за замовчуванням). У разі якщо не вказати DESTINATION в параметрах виклику RFC, функція буде виконана локально, як звичайна без створення свого LUW.
- NONE - Запуск відбувається так само локально, основна відмінність в тому, що виклик доходить до зазначеного в налаштуваннях шлюзу і реєструється в якості віддаленого виклику. Створюється свій DB LUW.
- BACK - використовується всередині синхронних RFC функцій, для запуску RFC функцій в тій системі яка їх викликала.
Обробка винятків при викликах RFC
При виклику RFC модуля можуть виникати такі винятки:
- COMMUNICATION_FAILURE - виникає в тому випадку, коли не налаштоване з'єднання для зазначеної системи в поле DESTINATION, або коли з'єднання не могло бути встановлено.
- SYSTEM_FAILURE - виникає в разі, якщо на віддаленій системі не існує викликається модуля, або в разі інших неполадок в RFC виклики.
- RESOURCE_FAILURE - виникає при виклику асинхронних RFC, в разі якщо немає вільних ресурсів на сервері додатків групи.
Типи RFC функцій:
- СінхронниеRFC (sRFC) - при виклику sRFC робочий процес призупиняє свою роботу, до тих пір, поки не буде виконано sRFC модуль. Модуль виконується в окремому DB LUW.
У разі, коли ви викликаєте кілька sRFC поспіль з однієї групи функцій, глобальні дані групи функцій будуть доступні до тих пір, поки не буде викликана остання функція цієї групи опитаних.
Якщо в sRFC всередині себе викликає CALL SCREEN, CALL TRANSACTION або вiдтворення списку, що викликаються екрани будуть відображені в програмі запустила sRFC, але тільки якщо в SM59 вказано діалоговий віддалений доступ, інакше система видасть виняток SYSTEM_FAILURE.
- АсінхронниеRFC виклики (aRFC) - дистанційна функція починає працювати паралельно відразу після її виклику, при цьому робочий процес не зупиняє свою роботу. Асинхронний виклик спрацьовує при виклику ФМ з ключовими словами: STARTING NEW TASK <ИмяЗадачи>. Модуль виконується в окремому DB LUW. aRFC можна так само використовувати працювали у фоновому режимі.
Для отримання результатів роботи aRFC необхідно при виклику вказати на процедуру обробки результатів, задається вона за допомогою ключового слова: PERFORMING <ИмяПроцедуры> ON END OF TASK. Процедура в якості першого параметра повинна містити змінну, в яку буде записано ім'я завдання (ім'я даної змінної не має значення). Для отримання даних з aRFC, всередині даної процедури, використовується обов'язкова команда (якщо її не поставити в процедурі, система видасть виняток - COMMUNICATION_FAILURE): RECEIVE RESULTS FROM FUNCTION <ИмяARFC>, c параметрами IMPORTING, TABLES, EXCEPTIONS які будуть передані з aRFC.
Процедура не повинна мати в своєму тілі оператори, переривають виконання програми, такі як: CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, RFC виклики, повідомлення з типами W і I.
Для очікування виконання aRFC викликів існує ключове слово WAIT UNTIL <Условие>. Якщо після виклику aRFC умова виконується, програма відразу ж починає своє виконання після WAIT UNTIL. У разі якщо не виконується, програма знову перевіряє умова. Даний процес повторюється до тих пір, поки умова не буде виконана або не будуть виконані всі aRFC виклики.
Приклад програми запускає 2 aRFC функції і яка чекає на виконання обох:
aRFC виклики так само як і sRFC можуть викликати в собі діалоги, але їх використання в даному контексті виглядає сумнівно, більш детально розглянуто в курсі (BC415).
Все tRFC виклики зберігаються в таблицях: ARFCSSTATE і ARFCSDATA. Якщо ви не хочете викликати tRFC негайно після COMMIT WORK, ви можете викликати ФМ START_OF_BACKGROUNDTASK (доCOMMITWORK) і задати час і дату запуску для накопичених tRFC викликів.
Після виконання COMMIT WORK в разі успішного локального оновлення (в рамках LUW основної програми), накопичені дані створюють фонову задачу, в разі успішного виконання цього завдання всі дані з таблиць tRFC видаляються. Якщо завдання не було виконано, спрацьовує механізм повтору або відкату.
Так, наприклад якщо зв'язок з віддаленої системою не була встановлена, спрацьовує автоматичний повтор виконання завдання. За замовчуванням кількість повторів одно 30, інтервал очікування дорівнює 15 хвилинам.
У разі якщо в другому з двох tRFC викликів стався збій, повідомлення з типом A або X або виклик виключення через RAISE після успішного виконання першого відбувається наступне:
- Всі зміни зроблені в поточному LUW (а він один на все tRFC) відкочуються
- Відбувається запис в журнал виклику tRFC (тр. SM58)
Для примусового відкату всіх змін або скасування 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.
- qRFC -RFC функціївиконувані в порядку черги. При використанні tRFC ми не можемо контролювати порядок запуску tRFC модулів, іншими словами порядок їх виклику може не відповідати порядку їх запуску. qRFC на відміну від tRFC, дозволяють нам контролювати порядок їх запуску.
Для розміщення tRFC викликів в порядку FIFO (перший прийшов, перший вийшов) необхідно перед кожним tRFC викликом вказувати ім'я черги, робиться це за допомогою ФМ: TRFC_SET_QUEUE_NAME:
Ім'я черзі може містити 24 символу, виключаючи% і *.
Для адміністрування qRFC замість транзакції SM58 використовується транзакція - SMQ1. Таблиця, в якій зберігаються дані qRFC - TRFCQOUT.
Більш детальна інформація про bgRFC знаходиться тут.
Транзакції, які використовуються при роботі з RFC
BAPI функції
Для обміну бізнес даними, між SAP і не SAP системами, був створений так званий Business Framework. Центральної його частиною є сховище бізнес об'єктів (BOR - Business Object Repository). Кожен бізнес об'єкт забезпечує об'єктно-орієнтований підхід до зберігання бізнес даних і роботи з бізнес процесами. Наприклад, викликаючи методи бізнес об'єктів, ми тим самим маніпулюємо бізнес даними, за які він відповідає, не піклуючись про технічне питання (зв'язках в таблицях і т.п.)
Бізнес об'єкт складається з наступних частин:
- Технічні дані - внутрішній номер, номер релізу SAP системи, з якої він доступний і т.п.
- Список інтерфейсів, які підтримує об'єкт - інтерфейс визначає поведінкову структуру об'єкта
- Ключові поля - атрибути, які однозначно ідентифікують об'єкт. (Номер закупівельного замовлення)
- Атрибути - можуть бути як поля з бази даних, так і розраховуються під час роботи з об'єктом (віртуальні), посилання на інші об'єкти (Бізнес об'єкт «Замовлення на закупівлю» наприклад, може мати посилання на об'єкти входять поставок)
- Методи - представляють собою виклики R / 3 транзакцій, функціональних модулів або іншого ABAP коду. BAPI якраз і є реалізацією методів бізнес об'єктів.
- Події - використовуються в основному в Workflow. Наприклад, зробити розсилку постачальникам при створенні закупівельного замовлення.
BAPI - реалізація методу бізнес об'єкта, являє собою функціональний модуль RFC. BAPI можуть викликатися як синхронно (COMMIT WORK ANDWAIT), так і асинхронно тобто чекаючи виконання роботи функції чи ні.
BAPI можуть представляти різні дії над об'єктом:
- створення об'єкта
- Запит атрибутів об'єкта
- Зміна атрибутів об'єкта
BAPI можуть викликатися з різних додатків: офісних додатків (через VBA), JAVA і С ++ програм і т.п.
Все BAPI після своєї роботи повертають результат у вигляді внутрішньої таблиці з однієї з структур: BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2, BAPIRET1_FIX. У зв'язку з цим в BAPI немає обробки виключень як в стандартних ФМ. Всі ці структури містять у собі наступні поля:
- TYPE - тип повідомлення: S (uccess), E (rror), W (arning), I (nformation)
- ID (клас повідомлень)
- NUMBER (номер повідомлення в класі)
- MESSAGE (текст повідомлення)
- MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, MESSAGE_V4 (змінні повідомлень)
Якщо транзакція пройшла успішно, то в таблиці RETURN не існуватиме записів з типом помилки «Е». Повинно бути присутнім повідомлення з типом помилки «S».
Курс, в якому розглядається створення власних BAPI - BC417.