Appel de fonction à distance (RFC) dans SAP Tutoriel ABAP
⚡ Résumé intelligent
L'appel de fonction à distance (RFC) est le SAP mécanisme de communication permettant à un programme ABAP d'appeler un module de fonction s'exécutant sur un autre SAP ou système externe. Il abstracIl gère l'infrastructure réseau, convertit les formats de données et renvoie clairement les erreurs à l'appelant.
Qu'est-ce qu'une RFC ? SAP?
RFC qui veut dire Appel de fonction à distanceIl s'agit du mécanisme qui permet aux applications métier de communiquer et d'échanger des informations — dans des formats prédéfinis — avec d'autres systèmes. RFC est la méthode la plus courante. SAP Le système communique avec un autre, et il sert également de pont entre eux. SAP systèmes aux non-SAP applications.
RFC propose deux interfaces :
- Une interface d'appel pour Programmes ABAP.
- Une interface d'appel pour les non-SAP programmes.
Tout programme ABAP peut appeler une fonction distante en utilisant FONCTION D'APPEL…DESTINATION déclaration. le DESTINATION Le paramètre indique le SAP système selon lequel la fonction appelée s'exécute sur un système différent de celui de l'appelant.
Syntaxe
CALL FUNCTION 'remotefunction'
DESTINATION dest
EXPORTING f1 = ...
IMPORTING f2 = ...
TABLES t1 = ...
EXCEPTIONS ...
Les destinations logiques sont définies par transaction. SM59 et stockés dans la table RFCDES.
Fonctions de l'interface RFC
L'environnement d'exécution RFC est responsable de trois choses lors de chaque appel :
- Conversion de toutes les données de paramètres dans la représentation attendue par le système distant.
- Appel des routines de communication nécessaires pour parler au système distant.
- Gérer les erreurs de communication et les signaler à l'appelant via le
EXCEPTIONSparamètre deCALL FUNCTION.
RFC est le SAP Protocole gérant la communication entre systèmes et simplifiant la programmation associée. Il s'agit du processus d'appel d'un module fonction situé sur une machine différente de celle du programme appelant. Les RFC peuvent techniquement être utilisées pour appeler un module fonction sur la machine distante. même Ces systèmes sont utilisés pour établir des connexions RFC entre différentes machines, mais ils sont le plus souvent employés lorsque les programmes appelant et appelé s'exécutent sur des machines distinctes. Le système d'interface RFC permet d'établir des connexions RFC entre différentes machines. SAP les systèmes, Ainsi qu'entre SAP et externes (non-SAP) systèmes.
Informations essentielles sur les RFC
- SAP utilise l' CIPC CPIC est un protocole (interface de programmation commune pour la communication) permettant de transférer des données entre systèmes. SAP-spécifique. RFC est une interface de communication construite sur CPI-C, mais avec plus de fonctions et une surface plus conviviale pour les programmeurs d'applications.
- Les fonctions de la bibliothèque RFC prennent en charge le Langage de programmation C et Visual Basic sur Windows les plates-formes.
- Les connexions RFC fonctionnent sur l'ensemble du système. Une connexion RFC définie dans le client 000 peut également être utilisée depuis le client 100 sans aucune différence.
- RFC est le protocole permettant d'appeler des sous-programmes spécialisés (modules de fonction) sur le réseau. Les modules de fonction sont comparables aux fonctions C ou aux procédures Pascal : ils exposent une interface définie par laquelle sont échangés des données, des tables et des codes de retour. Les modules de fonction sont gérés au sein du système. SAP système dans une bibliothèque dédiée, le Générateur de fonctions.
- Le générateur de fonctions (transaction) SE37) offre aux programmeurs d'applications un environnement pour écrire, documenter et vers les tests Des modules fonctionnels pouvant être appelés localement et à distance. Le système génère automatiquement le code supplémentaire (le Ébauche de RFC) nécessaire pour les appels à distance.
- Les connexions RFC sont maintenues à l'aide d'une transaction SM59. SAP expédie également un SDK RFC (Kit de développement logiciel) qui utilise de vastes bibliothèques C afin que des programmes externes puissent se connecter au SAP système.
- La seule différence entre un appel distant vers un autre serveur et un appel local est la
DESTINATIONparamètre qui spécifie le serveur cible sur lequel le programme doit s'exécuter.
Avantages du RFC
RFC réduit l'effort de programmation en éliminant la nécessité de réimplémenter des modules et des méthodes côté distant. La couche RFC prend en charge :
- Convertir les données dans un format compréhensible par le système distant (cible).
- Appel des routines nécessaires à l'établissement de la communication avec le système distant.
- Gestion des erreurs survenant lors de la communication.
- Fournir une sémantique transactionnelle fiable lorsque des variantes transactionnelles ou en file d'attente sont utilisées.
Types de RFC
SAP Il prend en charge quatre variantes RFC. Chacune offre un compromis différent entre latence, fiabilité et garanties d'ordonnancement.
1. SyncRFC héroïque (sRFC)
SyncLe type RFC héroïque exige que le client et le serveur soient disponibles au moment de l'appel. C'est le type le plus courant et il est utilisé lorsque l'appelant a besoin du résultat immédiatement après l'exécution.
sRFC est un protocole de communication entre systèmes nécessitant des accusés de réception. Les ressources du système source attendent la réception du message accompagné d'un accusé de réception par le système cible. Les données échangées sont ainsi cohérentes et fiables.
L'inconvénient est que si le système cible est indisponible, les ressources du système source attendent son retour, ce qui peut mettre les processus du système source en mode veille/RFC/CPIC sur le système cible et bloquer les ressources.
Utilisé pour:
- Communication en temps réel entre les systèmes.
- La communication entre le SAP Serveur d'applications Web et le SAP GUI.
2. RFC asynchrone (aRFC)
Une RFC asynchrone est une communication entre systèmes ne nécessitant pas d'accusé de réception, comparable à une perte de paquets.ping une carte postale. Les deux systèmes n'ont pas besoin d'être disponibles au moment de l'exécution, et le résultat n'est pas immédiatement renvoyé au système appelant.
La ressource du système source n'attend pas le système cible ; elle transmet les données et poursuit son chemin. Cela rend aRFC rapide, mais peu fiable en soi : des données peuvent être perdues si le système cible est indisponible.
Utilisé pour:
- Communication de type « tirer et oublier » entre les systèmes.
- Traitement parallèle entre systèmes.
3. RFC transactionnel (tRFC)
La RFC transactionnelle est une forme particulière de RFC asynchrone. Elle garantit un traitement transactionnel des étapes de traitement qui seraient autrement autonomes.
tRFC exécute le module fonction appelé sur le serveur RFC une seule fois, même si les données sont envoyées plusieurs fois en raison de problèmes réseau. Le système distant n'a pas besoin d'être disponible au moment où le client RFC effectue l'appel. Le composant tRFC stocke la fonction appelée et ses données dans le SAP base de données sous un unique ID de transaction (TID)Si le système cible est indisponible, les données sont écrites dans des tables RFC (visibles dans la transaction). SM58) et repris plus tard par le rapport du planificateur RSARFCSE, qui s'exécute toutes les 60 secondes.
Utilisé pour:
- Extension des RFC asynchrones avec une livraison au plus une fois.
- Communication fiable entre systèmes où l'exécution unique est essentielle.
4. RFC en file d'attente (qRFC)
Le protocole RFC en file d'attente étend le protocole tRFC en garantissant que chaque étape est traitée dans l'ordre spécifié par l'application appelante. Pour assurer le traitement de plusieurs unités logiques de travail (LUW / transactions) dans l'ordre prévu, le protocole tRFC peut être sérialisé à l'aide de files d'attente entrantes et sortantes ; d'où son nom.
Utilisé pour:
- Extension de la RFC transactionnelle avec un ordre strict.
- Scénarios où une séquence de traitement définie est obligatoire.
- Cas où plusieurs transactions doivent être traitées dans un ordre prédéfini.
Comparaison des types RFC
| Type | L'appelant attend-il ? | Fiable? | Ordonné? | Meilleur pour |
|---|---|---|---|---|
| sRFC | Oui | Oui | N/A (appel unique) | Recherches en temps réel |
| aRFC | Non | Non | Non | Fonctionnement autonome, travail en parallèle |
| tRFC | Non | Oui (une seule fois) | Non | Mises à jour asynchrones fiables |
| qRFC | Non | Oui (une seule fois) | Oui | Mises à jour strictement ordonnées |
Types de connexions RFC
Le protocole SM59 prend en charge plusieurs types de connexion. Les trois plus courants sont résumés ci-dessous.
Type 3 — ABAP vers ABAP
Les entrées de type 3 spécifient la connexion entre Systèmes ABAPLe nom d'hôte ou l'adresse IP est obligatoire ; les informations de connexion sont facultatives. Le type 3 s'applique aussi bien aux RFC entre systèmes ABAP qu'aux appels externes vers des systèmes ABAP.
Type I — Pair de même base de données
Les entrées de type I spécifient les systèmes ABAP qui partagent la même base de données que le système actuel. Ces entrées sont prédéfinies et ne peuvent pas être modifiées. Un nom d'entrée typique ressemble à : ws0015_K18_24:
- ws0015 — nom d'hôte
- K18 — nom du système (base de données)
- 24 — Nom du service TCP
Type T — Programme externe
Les destinations de type T se connectent à des programmes externes qui utilisent l'API RFC pour recevoir des RFC. Le type d'activation peut être l'un ou l'autre des suivants : Commencer or InscriptionSi l'option est « Démarrer », le nom d'hôte et le chemin d'accès au programme à lancer doivent être fournis.
Comment Code une RFC
La fabrication complète d'un RFC comporte cinq étapes. Les trois premières consistent en des clics mécaniques dans les commutateurs SE37 et SM59 ; les deux dernières concernent l'obtention du contrôleur.tracC'est exact.
Étape 1 : Dans l'onglet attributs du module de fonction de la transaction SE37, définissez le type de traitement sur Module activé à distance pour indiquer que le module fonctionnel est compatible RFC.
Étape 2 : Saisissez le code du module fonction dans l'éditeur de code source.
Étape 3 : Définissez la destination du serveur RFC dans le système client RFC qui appelle la fonction distante — effectué dans une transaction SM59.
Étape 4 — Déclaration des paramètres : Tous les champs de paramètres d'un module fonction distant doivent être définis comme des champs de référence, c'est-à-dire typés par rapport aux champs du dictionnaire ABAP. Les paramètres de valeur ne sont pas autorisés pour les modules fonction distants.
Étape 5 — Exceptions : Le système soulève ÉCHEC DE COMMUNICATION et DÉFAILLANCE DU SYSTÈME Les exceptions internes sont gérées en cas d'erreurs au niveau du transport. Les exceptions au niveau de l'application peuvent être levées dans une fonction distante de la même manière que dans une fonction locale.
Débogage des appels de fonction à distance
- Il est pas possible de déboguer un appel de fonction distante vers un système non-ABAP de manière classique — l'environnement d'exécution étranger est opaque.
- Toutefois, pour les appels RFC ABAP-à-ABAP, le débogueur ABAP peut être utilisé pour surveiller l'exécution de la fonction RFC au sein du système distant.
- Lors d'appels distants, le débogueur ABAP (y compris son interface utilisateur) s'exécute sur le système local. Les valeurs des données et autres informations d'exécution de la fonction distante sont renvoyées par le système distant.
ACTIVITES SAP Transactions RFC
La boîte à outils RFC utilisée au quotidien se résume à une poignée de codes de transaction que tout développeur ABAP et administrateur Basis devrait connaître par réflexe.
| Code T | Interet |
|---|---|
| SM59 | Conserver les destinations RFC — hôte, connexion, type, sécurité. |
| SE37 | Générateur de fonctions — créez ou modifiez des modules de fonctions accessibles à distance. |
| SM58 | Surveillez les RFC transactionnelles ayant échoué et retraitez-les. |
| SMQ1 / SMQ2 | Surveiller les files d'attente qRFC sortantes (SMQ1) et entrantes (SMQ2). |
| CONFIANCE | Maintenir les certificats SSL utilisés par les destinations RFC protégées par HTTPS. |
| ST22 | Examinez les vidages mémoire courts provoqués par des appels distants ayant échoué. |
Meilleures pratiques pour SAP RFC
Une couche RFC bien conçue garantit des intégrations rapides, observables et faciles à faire évoluer. Les bonnes pratiques suivantes méritent d'être intégrées à chaque projet.
- Choisissez la bonne variante pour l'arnaquetract. Utilisez sRFC pour les recherches synchrones, tRFC pour les mises à jour asynchrones au plus une fois et qRFC lorsque l'ordre est important.
- Réutiliser une destination par système cible plutôt que de répartir les noms d'hôtes sur de nombreuses destinations, il effectue une rotation des identifiants. tractableau.
- Ne jamais intégrer en dur les identifiants d'accès. En ABAP, utilisez des connexions système de confiance ou des tickets d'ouverture de session sécurisés lorsque cela est possible.
- Surveillez régulièrement les modules SM58 et SMQ2. Les entrées tRFC bloquées retardent silencieusement les processus métier jusqu'à leur retraitement.
- N'utilisez que des paramètres de type référence. Les paramètres de valeur interrompent les modules de fonction activés à distance.
- Utilisez STRUST pour gérer les certificats TLS Pour les destinations HTTPS, les certificats expirés sont une cause majeure d'erreurs mystérieuses de type COMMUNICATION_FAILURE.








