Partager via


Traitement lancé par l’hôte

Le traitement initié par l’hôte (HIP) permet à une application hôte d’appeler une méthode d’un objet COM ou .NET, de transmettre des paramètres à la méthode et de recevoir les paramètres de la méthode. À mesure que les données sont d’abord acheminées de l’hôte vers le client, puis du client vers l’hôte, les données sont transformées d’un format compréhensible par l’hôte vers le format approprié pour le client

Le traitement initié par l’hôte est implémenté dans les étapes suivantes :

  1. Le processus de service HIP, appelé application, commence à écouter les connexions entrantes sur une liste de points de terminaison spécifiés par une définition d’environnement local.

  2. L’application cliente, en cours d’exécution sur l’hôte, initie une connexion TCP à un système HIP à l’aide de l’un des points de terminaison

  3. Le processus du service HIP vérifie s’il existe une association établie entre le point de terminaison et le nom d’hôte ou l’adresse IP des clients. Si aucune association n’est trouvée, la connexion est abandonnée.

  4. L’association identifie de manière unique le plan de travail qui est une séquence de flux de travail à effectuer pour effectuer la demande des clients. Il existe trois types de plans de travail :

    1. Point de terminaison

    2. Message de demande de transaction

    3. Données.

Point de terminaison

Le plan de travail du point de terminaison se compose d’un flux de travail final unique. L’association est mappée directement à une méthode d’un objet COM qui doit être appelé pour le traitement des demandes des clients. Le workflow du point de terminaison effectue les opérations suivantes :

  1. Reçoit les données clientes

  2. Décompresse les données et remplit les paramètres de la méthode

  3. Crée l’objet et appelle la méthode

  4. Packs des paramètres retournés dans les données clientes

  5. Envoie des données clientes

  6. Ferme la connexion.

Message de demande de transaction

Le plan de travail TRM (Transaction Request Message) se compose de deux workflows : TRM et Flux de travail final. Le flux de travail TRM gère la partie initiale de la conversation lorsque le client envoie le TRM et les réponses du flux de travail avec la réponse TRM. Selon le type de TRM, le workflow TRM peut utiliser l’un des trois gestionnaires TRM : Microsoft Concurrent Server, Microsoft Link, IBM Concurrent Server. Le workflow TRM effectue les opérations suivantes :

  1. Reçoit et décompresse le TRM à l’aide du format d’entrée attribué

  2. Transmet le TRM au gestionnaire affecté

  3. Le gestionnaire retourne les informations de résolution et la réponse TRM positive

  4. Les informations de résolution, qui sont censées être des données de caractères, sont converties en Unicode à l’aide de la page de code associée à l’environnement hôte

  5. Le flux de travail interroge la base de données s’il existe un mappage à une méthode d’un objet défini pour les informations de résolution

  6. Si la correspondance est introuvable, le gestionnaire est appelé pour obtenir la réponse TRM négative

  7. La réponse TRM est emballée au format de sortie attribué et envoyée. Dans le cas négatif, la connexion est abandonnée

  8. Flux de travail passe le contrôle au flux de travail final avec l’identité de méthode trouvée

Données

Le plan de travail Déterminant des données se compose de deux flux de travail : Déterminant des données et Workflow final. Le flux de travail déterminant des données prétraite les données clientes en essayant de trouver une correspondance à l’un des déterminants définis pour l’association. Le déterminant inclut une chaîne de caractères et la position de la chaîne dans les données clientes. Chaque déterminant est mappé à une méthode d’un objet. Au démarrage, les déterminants sont pré-convertis en toutes les pages de code des hôtes associés aux déterminants. Les règles sont appliquées selon que les déterminants d’un point de terminaison : l’association d’hôte ne sont pas dupliquées ou un déterminant ne fait pas partie de l’autre. Le flux de travail suit les étapes suivantes :

  1. La liste des déterminants de la combinaison Point de terminaison - Hôte donnée est obtenue et triée par la somme de la longueur et de la position dans l’ordre croissant

  2. Le premier déterminant est extrait de la liste

  3. Une partie des données clientes est reçue

  4. Les données sont vérifiées si elles correspondent au déterminant

  5. En cas d’absence de correspondance, le déterminant suivant est extrait de la liste, plus de données client reçues si nécessaire, données par rapport à déterminant

  6. Lorsqu’aucun déterminant disponible ne correspond aux données, la connexion est abandonnée

  7. Si un déterminant est trouvé, le contrôle est passé au flux de travail final avec l’identité de méthode et les données clientes déjà lues. Il peut arriver que les données déterminantes se trouvent à l’intérieur ou même après que les données clientes soient mappées aux paramètres des méthodes.

Notes

Un client HIP MVS doit effectuer un arrêt de socket immédiatement après l’envoi d’un socket et avant la réception d’un socket. Si vous n’effectuez pas un arrêt immédiat du socket, le runtime TI refuse les données, interrompt la connexion et consigne un message d’événement 808 (une application HIP d’intégrateur de transactions a reçu plus de données que prévu) dans le journal des événements de l’application serveur. En outre, le paquet contenant les données envoyées à la station de travail peut sembler trompeur : le Moniteur réseau Microsoft montre que les données contenues dans le paquet et la longueur des données n’est pas excessive.

Voir aussi

WIP (Windows-Initiated Processing)
Modèles de programmation