Partager via

Appels de programme distribué IBM i

  • Article

Le modèle de programmation IBM i Remote Command and Distributed Program Calls (DPC) permet à la plupart des applications IBM i d’interagir avec TI en mode demande-réponse (initié uniquement par le client) avec un minimum de modifications. DPC est un protocole documenté qui prend en charge l’intégration de programme à programme sur un IBM i, qui est facilement accessible à partir d’applications PC à l’aide du protocole de mise en réseau TCP/IP.

Notes

Cette interface ne prend pas en charge le traitement lancé par l’hôte (HIP) ; L’intégration IBM i est destinée aux appels lancés par le client uniquement.

La figure suivante résume le flux de travail qui se produit entre le client, le serveur DPC par défaut et le programme de transaction IBM i. Les nombres entre parenthèses indiquent l’ordre approximatif dans lequel les événements se produisent. Une description plus détaillée des événements est illustrée dans la figure.

Image montrant le flux de modèle IBM i.
Flux de modèle IBM i

Diagramme de flux de travail résumé pour le modèle de programmation IBM i DPC

Le modèle de programmation IBM i DPC fonctionne comme suit :

  1. Une application appelle une méthode dans un composant TI configuré dans les Services de composants ou .NET Framework.

  2. Le runtime TI appelle le proxy TI Automation.

  3. Si l’application est un composant COM+, le proxy TI Automation :

    1. lit dans les bibliothèques de types créées précédemment par le Concepteur TI,

    2. Mappe les types de données Automation aux types de données IBM i RPG.

      Si l’application est un assembly .NET Framework, le proxy TI Automation :

    3. lit l’assembly et les métadonnées créés précédemment par le Concepteur TI,

    4. Mappe les types de données .NET Framework aux types de données IBM i RPG.

      Ensuite, le proxy TI Automation :

    5. Appelle les routines de conversion pour convertir les données d’application en types IBM i RPG.

    6. crée la mémoire tampon de messages paramétrable qui représente le RPG PLIST.

    7. Transmet le message au composant de transport IBM i DPC.

  4. Le transport TCP TI envoie une demande de connexion au système serveur DPC à l’aide de l’adresse IP (Internet Protocol) de l’ordinateur IBM i et de l’adresse de port du serveur. Le transport TCP TI attend ensuite une réponse.

  5. Le serveur DPC sur IBM i accepte la demande de session et émet une réception. Le serveur DPC attend ensuite la demande de démarrage du serveur.

  6. Le proxy Automation TI envoie au serveur DPC une requête de démarrage du serveur et émet une réception. Le transport TCP TI attend ensuite une réponse de démarrage du serveur.

  7. Le serveur DPC traite la requête de démarrage du serveur, envoie une réponse de démarrage du serveur, puis émet une réception. Le serveur DPC attend ensuite une demande d’attributs Exchange.

  8. Le runtime TI traite la réponse de démarrage du serveur, envoie la demande d’attributs et émet une réception. Le runtime TI attend ensuite une réponse des attributs Exchange.

  9. Le serveur DPC traite la requête d’attributs Exchange, envoie une réponse d’attributs Exchange, puis émet une réception. Le DPC attend ensuite une demande d’appel de programme distant.

  10. Le runtime TI traite les attributs Exchange et envoie une demande d’appel de programme à distance suivie immédiatement par la réponse aux appels de programme à distance et les données converties.

  11. Le serveur DPC traite la demande, envoie une réponse à l’appel de programme à distance suivie des paramètres et des données de l’appel de programme distant.

  12. Le proxy TI Automation reçoit les données de réponse et traite la réponse. Le proxy TI Automation :

    1. reçoit le message du composant de transport TCP,

    2. lit le message dans la mémoire tampon.

      Si l’application est un composant COM+, le proxy TI Automation :

    3. Mappe les types de données IBM i aux données d’automatisation.

    4. Appelle les routines de conversion pour convertir les types IBM i RPG en données d’application.

      Si l’application est un assembly .NET, le proxy TI Automation :

    5. Mappe les types de données IBM i aux types de données .NET Framework.

    6. Appelle les routines de conversion pour convertir les types IBM i RPG en données d’application.

  13. Le runtime TI renvoie les données converties à l’application COM ou .NET Framework qui a appelé la méthode.

    Notes

    La taille maximale d’un message est de 32 767 octets, y compris les en-têtes de champ et les données.

    Notes

    Le RMTPGMCALL peut passer le maximum de 35 paramètres comme IN ou OUT, ou comme IN/OUT dans n’importe quelle combinaison.

    Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation IMS Connect. L’exemple de code se trouve dans le \répertoire d’installation\SDK\Samples\AppInt. Démarrez Microsoft Visual Studio, ouvrez le didacticiel que vous souhaitez utiliser et suivez les instructions du fichier Lisez-moi.

    Pour plus d’informations sur la configuration du mainframe et l’écriture d’applications serveur pour IBM IBM ie, consultez ile RPG/400 Programmers Guide version 4 (DOCUMENT IBM #SC09-2507-02) et ILE RPG/400 Reference Version 3 (DOCUMENT IBM #SC09-2077-01).

Voir aussi

Composants de l’intégrateur de transactions
Conversion de types de données de RPG vers Automation
Conversion de types de données d’Automation vers RPG
Sécurité IBM i
Interface COMTIContext
Runtime TI
Choisir le modèle de programmation approprié
Modèles de programmation