Freigeben über


Vom Host initiierte Verarbeitung

Hostinitiierte Verarbeitung (HIP) ermöglicht es einer Hostanwendung, eine Methode eines COM- oder .NET-Objekts aufzurufen, Parameter an die -Methode zu übergeben und Parameter von der -Methode zurück zu empfangen. Wenn Daten zuerst vom Host zum Client und dann vom Client zum Host übertragen werden, werden die Daten von einem vom Host verständlichen Format in das für den Client geeignete Format transformiert.

Die vom Host initiierte Verarbeitung wird in den folgenden Schritten implementiert:

  1. Der HIP-Dienstprozess, der als Anwendung bezeichnet wird, beginnt mit dem Lauschen auf eingehende Verbindungen in einer Liste von Endpunkten, die durch eine lokale Umgebungsdefinition angegeben werden.

  2. Die Clientanwendung, die auf dem Host ausgeführt wird, initiiert eine TCP-Verbindung mit einem HIP-System mithilfe eines der Endpunkte.

  3. Der HIP-Dienstprozess überprüft, ob zwischen dem Endpunkt und dem Hostnamen oder der IP-Adresse des Clients eine feste Zuordnung vorhanden ist. Wenn keine Zuordnung gefunden wird, wird die Verbindung abgebrochen.

  4. Die Zuordnung identifiziert eindeutig den Arbeitsplan, bei dem es sich um eine Sequenz von Workflows handelt, die zum Abschließen der Clientanforderung ausgeführt werden sollen. Es gibt drei Arten von Arbeitsplänen:

    1. Endpunkt

    2. Transaktionsanforderungsnachricht

    3. Daten.

Endpunkt

Der Endpunktarbeitsplan besteht aus einem einzelnen abschließenden Workflow. Die Zuordnung wird direkt einer Methode eines COM-Objekts zugeordnet, das für die Clientanforderungsverarbeitung aufgerufen werden soll. Der Endpunktworkflow führt Folgendes aus:

  1. Empfängt Clientdaten

  2. Entpackt Daten und füllt Parameter für die Methode auf.

  3. Erstellt das -Objekt und ruft die -Methode auf.

  4. Pakete, die Parameter in den Clientdaten zurückgegeben wurden

  5. Sendet Clientdaten

  6. Schließt die Verbindung.

Transaktionsanforderungsnachricht

Der TrM-Arbeitsplan (Transaction Request Message) besteht aus zwei Workflows: TRM und Final Workflow. Der TRM-Workflow verarbeitet den ersten Teil der Konversation, wenn der Client das TRM und die Workflowantworten mit der TRM-Antwort sendet. Je nach TRM-Typ kann der TRM-Workflow einen von drei TRM-Handlern verwenden: Microsoft Concurrent Server, Microsoft Link, IBM Concurrent Server. Der TRM-Workflow führt Folgendes aus:

  1. Empfängt und entpackt das TRM mithilfe des zugewiesenen Eingabeformats

  2. Übergibt das TRM an den zugewiesenen Handler.

  3. Der Handler gibt die Auflösungsinformationen und die positive TRM-Antwort zurück.

  4. Die Auflösungsinformationen, bei denen es sich um Zeichendaten handelt, werden mithilfe der Codepage, die der Hostumgebung zugeordnet ist, in Unicode konvertiert.

  5. Workflow fragt die Datenbank ab, wenn eine Zuordnung zu einer Methode eines Objekts vorhanden ist, das für die Auflösungsinformationen definiert ist.

  6. Falls die Übereinstimmung nicht gefunden wird, wird der Handler aufgerufen, um die negative TRM-Antwort abzurufen.

  7. Die TRM-Antwort wird im zugewiesenen Ausgabeformat gepackt und gesendet. Im negativen Fall wird die Verbindung abgebrochen.

  8. Workflow übergibt die Steuerung zusammen mit der gefundenen Methodenidentität an den endgültigen Workflow.

Daten

Der Arbeitsplan der Determinante Data besteht aus zwei Workflows: Data Determinant und Final Workflow. Der Data Determinant-Workflow verarbeitet die Clientdaten vor, um eine Übereinstimmung mit einer der für die Zuordnung definierten Determinanten zu finden. Determinant umfasst eine Zeichenfolge und die Position der Zeichenfolge in den Clientdaten. Jede Determinante wird einer Methode eines Objekts zugeordnet. Beim Start werden die Determinanten in alle Codepages von Hosts konvertiert, die Determinanten zugeordnet sind. Die Regeln werden erzwungen, dass Determinanten für einen Endpunkt – Hostzuordnung nicht dupliziert werden oder eine Determinante nicht Teil der anderen ist. Der Workflow führt die folgenden Schritte aus:

  1. Die Liste der Determinanten für die angegebene Kombination Endpunkt – Host wird abgerufen und nach der Summe der Länge und Position in aufsteigender Reihenfolge sortiert.

  2. Die erste Determinante wird aus der Liste entnommen.

  3. Ein Teil der Clientdaten wird empfangen

  4. Die Daten werden überprüft, wenn sie mit der Determinante übereinstimmen.

  5. Falls keine Übereinstimmung besteht, wird die nächste Determinante aus der Liste entnommen, bei Bedarf werden mehr Clientdaten empfangen, Daten im Vergleich zu Determinanten

  6. Wenn keine verfügbare Determinante mit den Daten übereinstimmt, wird die Verbindung abgebrochen.

  7. Wenn eine Determinante gefunden wird, wird das Steuerelement zusammen mit der Methodenidentität und den bereits gelesenen Clientdaten an den Final-Workflow übergeben. Es kann eine Situation geben, in der sich die determinanten Daten innerhalb oder sogar nachdem die Clientdaten den Methodenparametern zugeordnet wurden.

Hinweis

Ein HIP MVS-Client muss unmittelbar nach dem Senden eines Sockets und vor dem Empfang eines Sockets ein Socket heruntergefahren werden. Ein Fehler beim sofortigen Herunterfahren des Sockets führt dazu, dass die TI-Runtime die Daten ablehnt, die Verbindung unterbrochen und eine 808-Ereignismeldung (Eine Transaction Integrator HIP-Anwendung hat mehr Daten als erwartet empfangen) im Ereignisprotokoll der Serveranwendung protokolliert. Darüber hinaus kann das Paket, das die Daten enthält, die an die Arbeitsstation gesendet werden, irreführend erscheinen: Der Microsoft-Netzwerkmonitor zeigt an, dass die Daten innerhalb des Pakets und die Datenlänge nicht übermäßig sind.

Weitere Informationen

Von Windows initiierte Verarbeitung
Programmiermodelle