Freigeben über


Host-Initiierte Verarbeitung

Die vom Host initiierte Verarbeitung (HIP) ermöglicht es einer Hostanwendung, eine Methode eines COM- oder .NET-Objekts aufzurufen, Parameter an die Methode zu übergeben und Parameter zurück von der Methode 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 der Überwachung eingehender Verbindungen in einer Liste von Endpunkten, die durch eine lokale Umgebungsdefinition angegeben sind.

  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 eine etablierte Zuordnung zwischen dem Endpunkt und dem Hostnamen oder der IP-Adresse des Clients vorhanden ist. Wenn keine Zuordnung gefunden wird, wird die Verbindung abgebrochen.

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

    1. Endpunkt

    2. Transaktionsanforderungsnachricht

    3. Daten.

Endpunkt

Der Endpunktarbeitsplan besteht aus einem einzelnen endgültigen 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. Packt die zurückgegebene Parameter in die Clientdaten

  5. Sendet Clientdaten

  6. Schließt die Verbindung.

Transaktionsanforderungsnachricht

Der Arbeitsplan für die Transaktionsanforderungsnachricht (Transaction Request Message, TRM) besteht aus zwei Workflows: TRM und finaler Workflow. Der TRM-Workflow behandelt den ersten Teil der Unterhaltung, wenn der Client das TRM sendet und der Workflow mit der TRM-Antwort antwortet. Je nach TrM-Typ kann der TRM-Workflow einen von drei TRM-Handlern verwenden: Microsoft Gleichzeitiger Server, Microsoft Link, IBM Gleichzeitiger 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, die als Zeichendaten erwartet werden, 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 Lö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 mit dem zugewiesenen Ausgabeformat gepackt und gesendet. Im negativen Fall wird die Verbindung abgebrochen.

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

Daten

Der Arbeitsplan "Data Determinant" besteht aus zwei Workflows: "Data Determinant" und "Final Workflow". Der Data Determinant-Workflow verarbeitet die Kundendaten und versucht, eine Übereinstimmung mit einer der für die Assoziation definierten Determinanten zu finden. Der Bestimmungsfaktor umfasst eine Zeichenfolge und die Position der Zeichenfolge in den Clientdaten. Jede Determinante wird einer Methode eines Objekts zugeordnet. Beim Start werden die Determinanten vorkonvertiert in alle Codeseiten von Hosts, die determinanten zugeordnet sind. Die Regeln schreiben vor, dass Determinanten für einen Endpunkt – Hostassoziation nicht dupliziert werden und dass eine Determinante nicht Teil der anderen ist. Der Workflow führt die folgenden Schritte aus:

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

  2. Die erste Determinante stammt aus der Liste

  3. Ein Teil der Clientdaten wird empfangen

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

  5. Falls keine Übereinstimmung gefunden wird, wird die nächste Determinante aus der Liste genommen, bei Bedarf werden mehr Clientdaten empfangen, und die Daten werden mit der Determinante verglichen.

  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 endgültigen Workflow übergeben. Es könnte eine Situation geben, in der sich die Determinantendaten innerhalb oder sogar nach der Zuordnung der Clientdaten zu den Methodenparametern befinden.

Hinweis

Ein HIP MVS-Client muss einen Socket unmittelbar nach dem Senden und vor dem Empfangen herunterfahren. Wenn ein sofortiges Herunterfahren des Sockets nicht ausgeführt wird, wird die TI-Laufzeit die Daten verweigern, die Verbindung unterbrechen und eine Ereignismeldung von 808 protokollieren (Eine Transaction Integrator HIP-Anwendung hat mehr Daten empfangen als erwartet.) im Ereignisprotokoll der Serveranwendung. Darüber hinaus kann das Paket, das die an die Arbeitsstation gesendeten Daten enthält, irreführend wirken: Der Microsoft Network Monitor zeigt die Daten im Paket sowie die Datenlänge, die nicht übermäßig ist.

Siehe auch

Windows-initiierte Verarbeitung
Programmiermodelle