Ne détestez-vous pas quand vous parlez au téléphone portable et que l’appel est coupé ? Je parlais à ma femme sur le chemin du site de mon client cette semaine et je lui parlais de ce superbe article de blog que j’écrivais lorsque l’appel a été interrompu. Déception. Puisque je voulais vraiment parler de mon blog à hSinceer, je voulais terminer la conversation. Mais d’abord, j’ai dû attendre le service. Ensuite, j’ai dû la rappeler et avoir sa réponse. Ensuite, j’ai prononcé la phrase que tous les utilisateurs de téléphones portables connaissent : « Quelle est la dernière chose que vous m’avez entendu dire ? La reprise a été assez compliquée, mais j’ai enfin pu parler de mon blog !
Lorsque deux systèmes logiciels s’intègrent, nous devons également faire face au problème des « appels interrompus ». SAP NCo 3.0 propose différents niveaux d’options de récupération de données selon que NCo est le client ou le serveur. Mais avant de pouvoir récupérer des données, la première étape consiste à rappeler l’autre partie. Cet article de blog décrit le processus général pour reconnecter un NCo RfcServer à un hôte de passerelle SAP.
J’ai lu dans d’autres blogs que SAP prétend que son objet RfcServer se reconnectera automatiquement s’il détecte une interruption de connexion. Bien que cela puisse être vrai, je n’ai pas vu cette reconnexion automatique se produire dans tous les tests que j’ai effectués. Alors, laissé à moi-même, j’ai cherché à trouver le meilleur moyen de reconnecter un RfcServer.
La première chose que j’ai faite a été de tracer le diagramme du processus « appel interrompu ».
Je sais que certains d’entre vous pensent qu’une fois un appel interrompu, il n’est pas nécessaire de raccrocher. C’est vrai. Mais la connexion doit être nettoyée. Dans l’analogie avec le téléphone mobile, le téléphone détecte automatiquement l’appel interrompu et raccroche pour vous. Ce que j’ai découvert au cours de mes recherches, c’est que NCo 3.0 ne nettoie pas automatiquement les connexions interrompues, ni les tentatives de connexion échouées.
Armé de cet organigramme, de ma nouvelle compréhension de NCo 3.0, de Diet Mountain Dew et d’un sac de Skittles, j’ai décidé de m’attaquer au codage d’une solution similaire en C# en utilisant NCo 3.0.
Mais d’abord, j’ai peaufiné mon organigramme :
Le résultat était un projet RfcServer NCo 3.0 qui récupérerait automatiquement des erreurs de connexion. Le concept clé est d’appeler la méthode Shutdown() de l’objet RfcServer après chaque échec de connexion. Ajoutez un gestionnaire d’événements pour l’événement RfcServerError et un minuteur, et le reste se met en place.