Remote Function Call (RFC) in SAP Урок за ABAP

Какво е RFC SAP?

RFC стойки за Отдалечено извикване на функцияТова е механизмът, който позволява на бизнес приложенията да комуникират и обменят информация – в предварително дефинирани формати – с други системи. RFC е най-разпространеният начин. SAP системата общува с друга и е и мостът, който свързва SAP системи към не-SAP приложения.

RFC предлага два интерфейса:

1. Интерфейс за повикване за ABAP програми.
2. Интерфейс за повиквания за не-SAP програми.

Всяка ABAP програма може да извика отдалечена функция, използвайки ФУНКЦИЯ ЗА ПОВЕДЕНИЕ…ДЕСТИНАЦИЯ изявление. The DESTINATION параметърът казва на SAP система, на която извиканата функция се изпълнява на различна система от извикващата.

Синтаксис

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Логическите дестинации се определят чрез транзакция SM59 и се съхранява в таблица RFCDES.

Функции на RFC интерфейса

RFC средата за изпълнение е отговорна за три неща при всяко извикване:

• Преобразуване на всички параметри в представянето, очаквано от отдалечената система.
• Извикване на комуникационните процедури, необходими за разговор с отдалечената система.
• Обработка на комуникационни грешки и представянето им на обаждащия се чрез EXCEPTIONS параметър на CALL FUNCTION.

RFC е SAP протокол, който обработва комуникацията между системите и опростява свързаното програмиране. Това е процесът на извикване на функционален модул, който се намира на различна машина от извикващата програма. RFC-тата технически могат да се използват за извикване на функционален модул на един и същ машина, но те се използват най-често, когато извикващата и извикваната програма се изпълняват на отделни машини. RFC интерфейсната система се използва за установяване на RFC връзки между различни SAP системи, както и между SAP и външни (не-SAP) системи.

Задължителни подробности за RFC

• SAP използва CPIC протокол (Общ програмен интерфейс за комуникация) за прехвърляне на данни между системи. CPIC е SAP-специфичен. RFC е комуникационен интерфейс, изграден върху CPI-C, но с повече функции и по-удобна повърхност за приложните програмисти.
• Функциите на RFC библиотеката поддържат C език за програмиране и Visual Basic на Windows платформи.
• RFC връзките работят в цялата система. RFC връзка, дефинирана в клиент 000, може да се използва и от клиент 100 без никаква разлика.
• RFC е протоколът за извикване на специализирани подпрограми (функционални модули) по мрежата. Функционалните модули са сравними с C функции или Pascal процедури: те предоставят дефиниран интерфейс, чрез който се обменят данни, таблици и кодове за връщане. Функционалните модули се управляват вътре в SAP система в специална библиотека, Конструктор на функции.
• Конструкторът на функции (транзакция SE37) предоставя на приложните програмисти среда за писане, документиране и тестване функционални модули, които могат да бъдат извиквани локално, както и дистанционно. Системата автоматично генерира допълнителния код ( RFC документ) необходими за отдалечени разговори.
• RFC връзките се поддържат чрез транзакции SM59. SAP също така изпраща RFC-SDK (Комплект за разработка на софтуер), който използва обширни C библиотеки, така че външни програми могат да се свързват с SAP система.
• Единствената разлика между отдалечено повикване към друг сървър и локално повикване е... DESTINATION параметър, който указва целевия сървър, на който програмата трябва да се изпълни.

Предимства на RFC

RFC намалява усилията за програмиране, като премахва необходимостта от повторно имплементиране на модули и методи от отдалечения край. RFC слоят се грижи за:

• Преобразуване на данните във формат, който отдалечената (целевата) система може да разбере.
• Извикване на рутините, необходими за установяване на комуникация с отдалечената система.
• Обработка на грешки, възникнали по време на комуникация.
• Осигуряване на надеждна транзакционна семантика, когато се използват транзакционни или опашечни варианти.

Видове RFC

SAP поддържа четири RFC варианта. Всеки от тях предлага различен компромис между латентност, надеждност и гаранции за подреждане.

1. Syncхроничен RFC (sRFC)

SyncХроничният RFC изисква както клиентът, така и сървърът да са налични по време на извикването. Това е най-разпространеният тип и се използва винаги, когато извикващата функция се нуждае от резултата веднага след изпълнението.

sRFC е средство за комуникация между системи, където се очакват потвърждения. Ресурсите на изходната система чакат целевата система и гарантират, че съобщението пристига с ACK. Обменените данни са последователни и надеждни.

Недостатъкът е, че ако целевата система не е налична, ресурсите на изходната система чакат, докато тя се върне, което може да тласне процесите на изходната система в режим Sleep/RFC/CPIC на целевата система и да блокира ресурсите.

Използвани за:

• Комуникация в реално време между системите.
• Комуникация между SAP Сървърът за уеб приложения и SAP GUI.

2. Асинхронен RFC (aRFC)

Асинхронният RFC е комуникация между системи, при която не се изисква потвърждение - сравнимо с dropping пощенска картичка. Не е необходимо и двете системи да са налични по време на изпълнението и резултатът не се връща веднага на извикващата система.

Ресурсът на изходната система не чака целевата система; той доставя данните и продължава напред. Това прави aRFC бърз, но ненадежден сам по себе си — данните могат да бъдат загубени, ако целевата система не е налична.

Използвани за:

• Комуникация „изстреляй и забрави“ между системите.
• Паралелна обработка в различни системи.

3. Транзакционен RFC (tRFC)

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

tRFC изпълнява извикания функционален модул на RFC сървъра точно веднъж, дори ако данните се изпращат многократно поради мрежови проблеми. Отдалечената система не е необходимо да е достъпна в момента, в който RFC клиентът изпълнява повикването. Компонентът tRFC съхранява извиканата функция и нейните данни в SAP база данни под уникална Идентификационен номер на транзакцията (TID)Ако целевата система не е налична, данните се записват в RFC таблици (видими в транзакцията). SM58) и по-късно взето от отчета на планировчика RSARFCSE, който се изпълнява на всеки 60 секунди.

Използвани за:

• Разширяване на асинхронния RFC с доставка най-много веднъж.
• Надеждна комуникация между системи, където е важно изпълнението „точно веднъж“.

4. RFC на опашка (qRFC)

Queued RFC разширява tRFC, като гарантира, че отделните стъпки се обработват в последователността, зададена от извикващото приложение. За да се гарантира, че множество LUW (логически единици работа / транзакции) се обработват в желания ред, tRFC може да бъде сериализиран с помощта на входящи и изходящи опашки - откъдето идва и името „queued RFC“.

Използвани за:

• Разширяване на транзакционния RFC със строго подреждане.
• Сценарии, при които определена последователност на обработка е задължителна.
• Случаи, при които няколко транзакции трябва да бъдат обработени в предварително определен ред.

Сравнение на типове RFC

Тип	Обаждащият се чака?	Надежден?	Поръчано?	Най-добър за
sRFC	Да	Да	Няма данни (еднократно обаждане)	Търсения в реално време
aRFC	Не	Не	Не	Работа по принципа „изстреляй и забрави“
tRFC	Не	Да (точно веднъж)	Не	Надеждни асинхронни актуализации
qRFC	Не	Да (точно веднъж)	Да	Строго подредени актуализации

Видове RFC връзки

SM59 поддържа няколко типа връзки. Трите, с които ще се сблъскате най-често, са обобщени по-долу.

Тип 3 — ABAP-към-ABAP

Записите от тип 3 определят връзката между ABAP системиИмето на хоста или IP адресът са задължителни; информацията за влизане може да се предостави по избор. Тип 3 е приложим както за RFC между ABAP системи, така и за външни повиквания към ABAP системи.

Тип I — партньор от същата база данни

Записите от тип I указват ABAP системи, които споделят същата база данни като текущата система. Тези записи са предварително дефинирани и не могат да бъдат променяни. Типичното име на запис изглежда така: ws0015_K18_24:

• ws0015 — име на хост
• K18 — име на системата (базата данни)
• 24 — Име на TCP услугата

Тип T — Външна програма

Дестинациите тип T се свързват с външни програми, които използват RFC API за получаване на RFC. Типът активиране може да бъде един от следните: Начало or РегистрацияАко е Start, трябва да се предоставят името на хоста и пътят на програмата, която ще бъде стартирана.

How to Code RFC (Рекламно предложение)

Цялостното изграждане на RFC има пет стъпки. Първите три са механични щраквания в SE37 и SM59; последните две са за получаване на кон...tracправилно.

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

Стъпка 2: Напишете кода за функционалния модул в редактора на изходния код.

Стъпка 3: Дефинирайте местоназначението на RFC сървъра в RFC клиентската система, която извиква отдалечената функция — извършва се в транзакция SM59.

Стъпка 4 — Деклариране на параметри: Всички полета с параметри за отдалечен функционален модул трябва да бъдат дефинирани като референтни полета – т.е., въведени спрямо полетата на ABAP речника. Параметрите със стойности не са разрешени за отдалечено активирани функционални модули.

Стъпка 5 — Изключения: Системата повишава КОМУНИКАЦИОННА_ГРЕШКА намлява СИСТЕМНА_ПОВРЕДА вътрешно при грешки на ниво транспорт. Изключения на ниво приложение могат да бъдат генерирани в отдалечена функция, точно както в локална.

Отстраняване на грешки при извиквания на отдалечени функции

• Е не е възможно отстраняване на грешки отдалечено извикване на функция в система, която не е ABAP, по класическия начин — външната среда за изпълнение е непрозрачна.
• Въпреки това, за ABAP-към-ABAP RFC повиквания, ABAP дебъгерът може да се използва за наблюдение на изпълнението на RFC функцията в отдалечената система.
• При отдалечени повиквания, ABAP дебъгерът (включително неговият потребителски интерфейс) се изпълнява на локалната система. Стойностите на данните и друга информация по време на изпълнение за отдалечената функция се предават обратно от отдалечената система.

ключ SAP RFC транзакции

Ежедневният набор от RFC инструменти се свежда до няколко T-кода, които всеки ABAP разработчик и Basis администратор би трябвало да знае интуитивно.

Т-код	Цел
SM59	Поддържайте RFC дестинации — хост, влизане, тип, сигурност.
SE37	Конструктор на функции — създаване или редактиране на функционални модули с дистанционно активиране.
SM58	Следете неуспешните транзакционни RFC-та и ги обработвайте повторно.
SMQ1 / SMQ2	Следете изходящите (SMQ1) и входящите (SMQ2) qRFC опашки.
ДОВЕРИЕ	Поддържайте SSL сертификати, използвани от HTTPS-защитени RFC дестинации.
ST22	Проверете кратките дъмпове, причинени от неуспешни отдалечени повиквания.

Най-добри практики за SAP RFC

Добре проектираният RFC слой осигурява бързина, видимост и лесна за развитие на интеграциите. Струва си да се включат следните навици във всеки проект.

• Изберете правилния вариант за конфузиятаtract. Използвайте sRFC за синхронни търсения, tRFC за асинхронни актуализации с максимум веднъж и qRFC при подреждане на въпроси.
• Използвайте повторно една дестинация на целева система вместо да разпространява имена на хостове в много дестинации — това прави ротация на идентификационните данни tracмасата.
• Никога не кодирайте твърдо идентификационните данни в ABAP. Използвайте надеждни системни връзки или защитени билети за влизане, където е възможно.
• Рутинно наблюдавайте SM58 и SMQ2. Заседналите tRFC записи тихомълком забавят бизнес процесите, докато не бъдат обработени повторно.
• Предавайте само параметри от референтен тип. Параметрите на стойностите прекъсват дистанционно активираните функционални модули.
• Използвайте STRUST за управление на TLS сертификати за HTTPS дестинации — изтеклите сертификати са основна причина за мистериозни дъмпове COMMUNICATION_FAILURE.

Въпроси и Отговори