Freigeben über


IBM i Distributed-Programmaufrufe

Das IBM i-DPC-Programmiermodell (Remote Command and Distributed Program Calls) ermöglicht es den meisten IBM i-Anwendungen, mit TI auf Anforderungs-Antwort-Weise (nur vom Client initiiert) mit minimalen Änderungen zu interagieren. DPC ist ein dokumentiertes Protokoll, das die Programmintegration auf einem IBM i unterstützt, auf das über PC-basierte Anwendungen mithilfe des TCP/IP-Netzwerkprotokolls problemlos zugegriffen werden kann.

Hinweis

Diese Schnittstelle unterstützt keine vom Host initiierte Verarbeitung (HIP). Die IBM i-Integration ist nur für clientinitiierte Aufrufe vorgesehen.

Die folgende Abbildung fasst den Workflow zusammen, der zwischen dem Client, dem DPC-Standardserver und dem IBM i-Transaktionsprogramm auftritt. Die Zahlen in Klammern geben die ungefähre Reihenfolge an, in der Ereignisse auftreten. Nach der Abbildung folgt eine ausführliche Beschreibung der Ereignisse.

Abbildung, die den IBM i-Modellfluss zeigt.
IBM i-Modellflow

Zusammenfassung des Workflowdiagramms für das IBM i DPC-Programmiermodell

Das IBM i DPC-Programmiermodell funktioniert wie folgt:

  1. Eine Anwendung ruft eine Methode in einer TI-Komponente auf, die in Komponentendiensten oder dem .NET Framework konfiguriert ist.

  2. Die TI-Runtime ruft den TI Automation-Proxy auf.

  3. Wenn es sich bei der Anwendung um eine COM+-Komponente handelt, führt der TI Automation-Proxy Folgendes aus:

    1. Einlesen der zuvor vom TI-Designer erstellten Typbibliotheken.

    2. Ordnet die Automatisierungsdatentypen IBM i RPG-Datentypen zu.

      Wenn es sich bei der Anwendung um eine .NET Framework-Assembly handelt, führt der TI Automation-Proxy Folgendes aus:

    3. Einlesen der Assembly und der Metadaten, die zuvor vom TI-Designer erstellt wurden.

    4. Ordnet die .NET Framework Datentypen IBM i RPG zu.

      Der TI Automation-Proxy führt dann Folgendes aus:

    5. Ruft die Konvertierungsroutinen auf, um die Anwendungsdaten in IBM i RPG-Typen zu konvertieren.

    6. Erstellen des parametrisierten Nachrichtenpuffers, der die RPG-PLIST darstellt.

    7. Übergibt die Nachricht an die IBM i DPC-Transportkomponente.

  4. Der TI TCP-Transport sendet eine Verbindungsanforderung an das DPC-Serversystem unter Verwendung der IP-Adresse (Internet Protocol) des IBM i-Computers und der Portadresse des Servers. Der TI-TCP-Transport wartet dann auf eine Antwort.

  5. Der DPC-Server auf ibm i akzeptiert die Sitzungsanforderung und gibt einen Empfang aus. Der DPC-Server wartet dann auf die Anforderung zum Starten des Servers.

  6. Der TI Automation-Proxy sendet dem DPC-Server eine „Server starten“-Anforderung und gibt eine Empfangsbestätigung aus. Der TI-TCP-Transport wartet dann auf eine „Server starten“-Antwort.

  7. Der DPC-Server verarbeitet die „Server starten“-Anforderung, sendet eine „Server starten“-Antwort und gibt dann eine Empfangsbestätigung aus. Der DPC-Server wartet dann auf eine „Attribute austauschen“-Anforderung.

  8. Die TI-Runtime verarbeitet die „Server starten“-Antwort, sendet die Attributanforderung und gibt eine Empfangsbestätigung aus. Die TI-Runtime wartet dann auf eine „Attribute austauschen“-Antwort.

  9. Der DPC-Server verarbeitet die „Attribute austauschen“-Anforderung, sendet eine „Attribute austauschen“-Antwort und gibt eine Empfangsbestätigung aus. Der DPC wartet dann auf eine Remoteprogrammaufrufanforderung.

  10. Die TI-Runtime verarbeitet die „Attribute austauschen“-Antwort und sendet dann eine Remoteprogrammaufruf-Anforderung, worauf unmittelbar die Remoteprogrammaufruf-Antwort und die konvertierten Daten folgen.

  11. Der DPC-Server verarbeitet die Anforderung und sendet eine Remoteprogrammaufruf-Antwort, gefolgt von Remoteprogrammaufruf-Parametern und -Daten.

  12. Der TI Automation-Proxy empfängt die Antwortdaten und verarbeitet die Antwort. Der TI Automation-Proxy führt Folgendes aus:

    1. Empfängt die Nachricht von der TCP-Transportkomponente.

    2. Liest den Nachrichtenpuffer.

      Wenn es sich bei der Anwendung um eine COM+-Komponente handelt, führt der TI Automation-Proxy Folgendes aus:

    3. Ordnet die IBM i-Datentypen den Automatisierungsdaten zu.

    4. Ruft die Konvertierungsroutinen auf, um die IBM i RPG-Typen in die Anwendungsdaten zu konvertieren.

      Wenn es sich bei der Anwendung um eine .NET-Assembly handelt, führt der TI Automation-Proxy Folgendes aus:

    5. Ordnet die IBM i-Datentypen den .NET Framework-Datentypen zu.

    6. Ruft die Konvertierungsroutinen auf, um die IBM i RPG-Typen in die Anwendungsdaten zu konvertieren.

  13. Die TI-Runtime sendet die konvertierten Daten zurück an die COM- oder .NET Framework-Anwendung, die die Methode aufgerufen hat.

    Hinweis

    Die maximale Größe einer Nachricht beträgt einschließlich Feldheadern und Daten 32.767 Bytes.

    Hinweis

    RMTPGMCALL kann maximal 35 Parameter als IN oder OUT oder in beliebiger IN/OUT-Kombination übergeben.

    Host Integration Server enthält Beispielcode, der zeigt, wie das IMS Connect-Programmiermodell implementiert wird. Der Beispielcode befindet sich hier: \Installationsverzeichnis\SDK\Samples\AppInt. Starten Sie Microsoft Visual Studio, öffnen Sie das gewünschte Tutorial, und befolgen Sie die Anweisungen in der Readme-Datei.

    Informationen zum Konfigurieren des Mainframes und zum Schreiben von Serveranwendungen für IBM IBM ie finden Sie im ILE RPG/400 Programmers Guide Version 4 (IBM Document #SC09-2507-02) und im ILE RPG/400 Reference Version 3 (IBM Document #SC09-2077-01).

Weitere Informationen

Komponenten von Transaction Integrator
Konvertieren von RPG-Datentypen zu Automatisierungsdatentypen
Konvertieren von Automatisierungsdatentypen zu RPG-Datentypen
IBM i Security
COMTIContext-Schnittstelle
TI-Runtime
Auswählen des geeigneten Programmiermodells
Programmiermodelle