Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 :
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.
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
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.
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 :
Point de terminaison
Message de demande de transaction
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 :
Reçoit les données clientes
Décompresse les données et remplit les paramètres de la méthode
Crée l’objet et appelle la méthode
Packs des paramètres retournés dans les données clientes
Envoie des données clientes
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 :
Reçoit et décompresse le TRM à l’aide du format d’entrée attribué
Transmet le TRM au gestionnaire affecté
Le gestionnaire retourne les informations de résolution et la réponse TRM positive
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
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
Si la correspondance est introuvable, le gestionnaire est appelé pour obtenir la réponse TRM négative
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
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 :
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
Le premier déterminant est extrait de la liste
Une partie des données clientes est reçue
Les données sont vérifiées si elles correspondent au déterminant
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
Lorsqu’aucun déterminant disponible ne correspond aux données, la connexion est abandonnée
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.