Intégration des interfaces de dialogue 

Utilisation

L’échange de données dans des environnements répartis est effectué sans intervention de l’utilisateur.

Dans certains cas toutefois, il est possible que vous deviez appeler les interfaces de dialogue à partir de systèmes distants. Un exemple typique consiste à afficher le document source d’un document situé dans un autre système.

Le système HR transmet les résultats de paie à la gestion comptable. Les documents concernés y sont enregistrés. Chaque document de la gestion comptable fait référence au document source dans HR. Dans le système intégré, l’affichage du document est programmé dans la gestion comptable de façon à ce que vous puissiez passer à l’affichage du document source dans HR.

Si le système HR et la gestion comptable tournent sur des systèmes différents, la lecture par la gestion comptable des données via une BAPI et la reprogrammation d’un nouvel affichage du document HR sont sans objet. Au lieu de cela, l’affichage du document HR est appelé à partir du système distant.

Les interfaces de dialogue ne sont pas fournies à la place des interfaces BAPI, mais bien en plus de celles-ci. Nous vous recommandons de définir, pour chaque interface de dialogue, une BAPI qui affiche les données comme une interface d’arrière-plan.

Actuellement, les interfaces de dialogue offrent principalement des fonctions d’affichage dans des scénarios de répartition R/3 vers R/3. Les méthodes de dialogue ayant des fonctions de modification ne sont pas supportées actuellement.

Les interfaces de dialogue peuvent également être appelées à partir de plates-formes externes.

Procédure

RFC est utilisé pour appeler les fonctions de dialogue à partir de systèmes distants. Des images peuvent être transférées par RFC.

Une méthode de dialogue est implémentée par un module fonction appelé via le RFC. La méthode de dialogue est ensuite appelée dans ce module fonction.

Ce module fonction doit remplir les mêmes exigences en matière de qualité que les modules fonction pour les interfaces BAPI :

Le module fonction est modélisé dans le BOR. Les mêmes règles que pour les interfaces BAPI s’appliquent, à deux exceptions près :

Une méthode de dialogue est créée comme une méthode API, de la même façon qu’une interface BAPI dans le BOR. Ceci vous donne la garantie que le codage nécessaire est généré dans le BOR et que la méthode de dialogue peut également être appelée via l’environnement d’exécution BOR. Si des modifications sont apportées par la suite à une méthode de dialogue, assurez-vous que le code BOR est également modifié en conséquence. Une méthode de dialogue doit pouvoir être appelée via l’environnement d’exécution BOR.

La libération interne indique que cette méthode est utilisée pour des scénarios R/3 vers R/3. Le témoin API indique que cette méthode peut être appelée à partir d’un système distant. Le témoin de dialogue est activé parce qu’une interface de dialogue est utilisée par opposition à une interface d’arrière-plan. Le témoin de dialogue différencie les méthodes de dialogue des interfaces BAPI.

Appellation des méthodes de dialogue

Vous pouvez accéder à chaque type d’objet dans le BOR via la méthode Display. Toutefois, dans beaucoup de cas, la méthode n’a pas été implémentée. Si la méthode de dialogue à implémenter doit afficher l’objet, Display est la méthode à utiliser, dans la mesure du possible.

Si Display a déjà été implémenté et si des modifications incompatibles avec les exigences BAPI concernant la qualité BAPI ont été introduites, une méthode différente doit être utilisée.

En dehors de la méthode Display, nous vous recommandons d’utiliser le suffixe WithDialog pour les méthodes de dialogue lorsque vous les modélisez dans le BOR.

Appel des méthodes de dialogue

Les méthodes de dialogue sont appelées à partir d’un système R/3 de la même manière que les interfaces BAPI sont appelées via RFC.

Il existe deux types d’appel différents :

Le système logique doit être déterminé à partir du modèle de répartition.

Les exemples ne prétendent pas être adaptés à toutes les situations possibles d’appel des méthodes. Notamment, nous ne pouvons pas vous recommander une procédure standard pour la correction des erreurs parce qu’elle dépend de l’application impliquée et des circonstances de l’appel. Avant d’incorporer un appel de méthode de dialogue dans votre codage, étudiez soigneusement la stratégie de traitement des erreurs.

Si, par exemple, aucune destination pour les appels de dialogue ne peut être déterminée pour un système serveur, c’est peut être parce que le serveur n’offre pas la fonctionnalité de dialogue pour des raisons techniques ou de sécurité. Cette situation peut également se produire dans les systèmes productifs. Ce cas ne constitue pas une incohérence dans la configuration du système.

Vous devez également garder à l’esprit que le RFC exécute implicitement un commit de base de données, c’est-à-dire que le LUW est effectué. Si vous ne connaissez pas bien l’utilisation des appels RFC, vous devez d’abord lire l’aide interactive sur l’élément de langage ABAP call function ainsi que destination .