Traitement des événements

Lors du traitement des événements, le connecteur se sert des programmes d'écoute de protocole et du ou des gestionnaires de données configurés pour convertir les messages de demande des clients du service HTTP en objets métier pouvant être manipulés par des collaborations. Les programmes d'écoute de protocole jouent un rôle crucial dans le traitement des événements.

Programmes d'écoute de protocole

Les demandes HTTP peuvent être acheminées par HTTP ou HTTPS. Le programme d'écoute surveille l'arrivée de telles demandes sur son canal de transport. On compte deux programmes d'écoute de protocole et les canaux correspondants :

Chacun d'eux consiste en une unité d'exécution qui écoute le trafic sur le protocole de transport. Quand il reçoit un message de demande émanant d'un client, le programme d'écoute enregistre l'événement auprès de la structure d'écoute de protocole.

La structure de programme d'écoute de protocole gère les programmes d'écoute de protocole, planifiant les demandes à mesure que des ressources sont disponibles. Vous configurez les programmes d'écoute et les aspects de la structure de programme d'écoute de protocole lors de la définition de valeurs des propriétés spécifiques de connecteur. Parmi les propriétés de structure de programme d'écoute de protocole, vous pouvez configurer les propriétés suivantes :

Ces deux propriétés spécifiques au connecteur contrôlent l'allocation de mémoire de sorte qu'elles empêchent les programmes d'écoute de protocole de celui-ci de boucler sur des événements infinis. L'algorithme d'allocation se présente ainsi : à tout moment, le connecteur peut recevoir un nombre total d'événements égal à WorkerThreadCount + RequestPoolSize. Il peut traiter le nombre WorkerThreadCount de demandes en parallèle.

Vous pouvez brancher des programmes d'écoute de protocole supplémentaires dans la structure de programme d'écoute de protocole. Pour plus d'informations, voir Création programmes d'écoute multiples et Propriétés de configuration spécifiques au connecteur.

Pingability

Les programmes d'écoute peuvent être configurés pour répondre aux demandes ping avec des codes réponse indiqués par l'utilisateur. En général, les demandes ping surviennent avant des demandes complètes et permettent de valider la réactivité de l'URL du programme d'écoute. La propriété hiérarchique Pingability permet de capturer les paramètres de configuration. Si ce service est activé dans le programme d'écoute, le programme d'écoute vérifie que la méthode de la demande correspond à l'une des propriétés enfants de Pingability et répond avec un code état et une raison définis par l'utilisateur.

Remarque :
Attribuer le caractère "pingable" à une méthode HTTP empêche le programme d'écoute de générer des demandes qui la contiennent. Par conséquent, les méthodes POST et GET ne doivent pas être définies avec la propriété Pingable pour permettre leur traitement.

HTTP et HTTPS traitement du programme d'écoute de protocole

Le programme d'écoute de protocole HTTP(S) consiste en une unité d'exécution qui écoute de façon continue les demandes HTTP(S) émanant de clients. L'unité d'exécution du programme d'écoute lie l'hôte et le port indiqués par les propriétés de configuration Host et Port spécifiques au connecteur. Une autre propriété de configuration --RequestWaitTimeout-- définit l'intervalle durant lequel le programme d'écoute attend une demande avant de vérifier si le connecteur s'est arrêté.

La figure 14 illustre le traitement du programme d'écoute de protocole HTTP dans le cadre d'une opération synchrone.

Figure 14. Programme d'écoute de protocole HTTP : traitement des événements synchrones

La figure 15 illustre le traitement du programme d'écoute de protocole HTTP dans le cadre d'une opération asynchrone.

Figure 15. Programme d'écoute de protocole HTTP : traitement des événements asynchrones

En lançant une demande HTTP ou HTTPS, un client envoie un message de demande au programme d'écoute HTTP ou HTTPS. Le client doit utiliser la méthode HTTP POST ou GET pour appeler l'URL du programme d'écoute de protocole.

Lorsqu'il reçoit une demande HTTP(S), le programme d'écoute l'enregistre auprès de la structure de programme d'écoute de protocole, qui planifie le traitement de l'événement à mesure que des ressources se libèrent. Le programme d'écoute extrait alors de la demande les entêtes de protocole et la charge.

Le tableau 26 récapitule la priorité des règles qu'utilise le programme pour déterminer l'en-tête Charset, MimeType, ContentType et Content-Type des messages entrants en cas de présence de charge.

Remarque :
En cas d'absence de charge avec les messages entrants, consultez le tableau 27, qui récapitule l'ordre de priorité des règles qu'utilise le programme d'écoute pour identifier l'en-tête Charset, MimeType, ContentType et Content-Type.

Tableau 26. Règles de traitement des messages entrants en présence de charge
Priorité Charset MimeType ContentType Entête Content-Type
1 Entête Content-Type du message HTTP entrant Valeur de propriété URLsConfiguration pour ce programme d'écoute Entête Content-Type du message HTTP entrant Entête Content-Type du message HTTP entrant
2 Valeur de propriété URLsConfiguration pour ce programme d'écoute Valeur par défaut : ContentType
3 Si le type ContentType du message de demande est text avec un sous-type (par exemple, text/xml, text/plain, etc.), la valeur par défaut est ISO-8859-1. Autrement, charset ne sera pas utilisé.

Tableau 27. Règles de traitement des messages entrants en l'absence de charge
Priorité Charset MimeType ContentType Entête Content-Type
1 Lecture à partir de la propriété du programme d'écoute EmptyRequestRule Lecture à partir de la propriété du programme d'écoute EmptyRequestRule Listener Le gestionnaire de données appelé peut renvoyer ContentType comme partie de l'en-tête Content-Type Le gestionnaire de données appelé peut renvoyer l'en-tête Content-Type
2 Charset ne sera pas utilisé. Echec de la demande
3

Comme le montre le tableau 26 :

En cas d'appel asynchrone de la collaboration, le programme d'écoute livre l'objet métier de demande au courtier d'intégration et répond au client avec le code état HTTP 202 Accepted. Cela termine le traitement du programme d'écoute.

En cas d'appel synchrone, le programme d'écoute appelle la collaboration de façon synchrone. La collaboration répond avec un objet métier de réponse.

Le tableau 28 récapitule la priorité des règles qu'utilise le programme pour déterminer l'en-tête Charset, MimeType, ContentType et Content-Type des messages de réponse en cas de présence de charge.

Remarque :
En cas d'absence de charge avec les messages de réponse, consultez le tableau 29, qui récapitule l'ordre de priorité des règles qu'utilise le programme d'écoute pour identifier l'en-tête Charset, MimeType, ContentType et Content-Type.

Tableau 28. Règles de traitement des messages de réponse synchrones sortants en présence de charge
Priorité Charset MimeType ContentType Entête Content-Type
1 Entête Content-Type ConfigMO du protocole Propriété MimeType dans le TLO Entête Content-Type ConfigMO du protocole Entête Content-Type ConfigMO du protocole
2 Valeur de la propriété Charset dans le TLO Mimetype du message de demande, uniquement si les propriétés ContentType de la demande et de la réponse sont identiques. ContentType du message de demande En-tête Content-Type Construct utilisant ContentType et Charset
3 Mimetype du message de demande, uniquement si les propriétés ContentType de la demande et de la réponse sont identiques. Valeur par défaut : ContentType
4 Si le ContentType est text/*, la valeur par défaut est ISO-8859-1. Autrement, charset ne sera pas utilisé.

Tableau 29. Règles de traitement des messages de réponse synchrones sortants en présence de charge de demandes
Priorité Charset MimeType ContentType Entête Content-Type
1 Entête Content-Type ConfigMO du protocole Propriété MimeType dans le TLO Entête Content-Type ConfigMO du protocole Entête Content-Type ConfigMO du protocole
2 Valeur de la propriété Charset dans le TLO Mimetype du message de demande, uniquement si les propriétés ContentType de la demande et de la réponse sont identiques. ContentType du message de demande En-tête Content-Type Construct utilisant ContentType et Charset
3 Mimetype du message de demande, uniquement si les propriétés ContentType de la demande et de la réponse sont identiques. Valeur par défaut : ContentType
4 Si le ContentType est text/*, la valeur par défaut est ISO-8859-1. Autrement, charset ne sera pas utilisé. Echec de la réponse

Comme le montre le tableau 28,

Le programme d'écoute traite HTTP Protocol Config MO. La collaboration doit vérifier que les valeurs d'entête transmises à HTTP Protocol Config MO sont correctes dans le contexte de l'événement demande-réponse. Le programme d'écoute complète les entêtes standard et les propriétés personnalisées selon les règles suivantes :

  1. Le programme d'écoute inspecte chaque élément de HTTP Protocol Config MO afin de ne pas tenir compte d'attributs spéciaux (tels qu'ObjectEventId).
  2. Chaque entête non vide est copié dans le message sortant et tout traitement supplémentaire (de l'entête Content-Type, par exemple) peut avoir lieu.
  3. Notez qu'avec cette approche, il se peut que le programme d'écoute définisse des entêtes non standard dans le message et ne vérifie pas la structure logique ou sémantique de celui-ci.
  4. Si l'attribut UserDefinedProperties de HTTP Protocol Config MO contient une ou plusieurs propriétés personnalisées, le programme d'écoute les ajoute à la section Entity Headers (dernière section d'entêtes du message). Pour plus d'informations sur les propriétés personnalisées, voir Propriétés définies par l'utilisateur pour le traitement des événements.

Remarque :
La présence de l'un des entêtes suivants : Connection, Trailer, Transfer-Encoding, Content-Encoding, Content-Length, Content-MD5, Content-Range, dans HTTP Protocol Config MO compromet généralement la validité ou le traitement du message.

Le programme d'écoute appelle le gestionnaire de données pour convertir en message de réponse l'objet métier de réponse retourné par la collaboration.

Le programme d'écoute livre le message de réponse au client et inclut un code état HTTP 200 OK. Si la collaboration renvoie un objet métier d'erreur, celui-ci est converti en message d'erreur. Ce message d'erreur est envoyé au client avec un code erreur 500 Internal Server Error HTTP.

Le programme d'écoute ferme alors la connexion, ce qui libère l'unité d'exécution qui a traité l'événement.

Fonctions de traitement non prises en charge par le programme d'écoute de protocole HTTP

Le programme d'écoute de protocole HTTP ne prend pas en charge ce qui suit :

Traitement du protocole d'écoute HTTPS à l'aide de sockets sécurisées

Le traitement du programme d'écoute de protocole HTTPS est similaire à celui du programme d'écoute de protocole HTTPS hormis que HTTPS utilise des sockets sécurisées. Pour plus d'informations, voir SSL.

Persistance et livraison d'événements

La persistance d'événements dépend du protocole :

Séquençage d'événements

Le connecteur peut livrer des événements dans n'importe quel ordre.

Déclenchement d'événement

Le mécanisme de déclenchement d'événements dépend de la configuration du programme d'écoute de protocole.

Remarque :
Le connecteur ne fait pas la différence entre les opérations Create, Update, Retrieve et Delete. Il en va de même pour de tels événements.

Détection d'événements

La détection d'événements est effectuée par chaque programme d'écoute de protocole. Le mécanisme de détection d'événements dépend essentiellement du transport et de la façon dont vous configurez les propriétés spécifiques de connecteur pour chaque programme d'écoute. Pour plus d'informations sur ces propriétés, voir Propriétés de configuration spécifiques au connecteur.

Etat d'événement

L'état d'événement est géré par le programme d'écoute de protocole et dépend du transport mais aussi de la façon dont vous configurez le programme d'écoute.

Récupération d'événement

La récupération d'événement est gérée par le programme d'écoute de protocole et dépend du transport mais aussi de la façon dont vous configurez le programme d'écoute.

Archivage d'événement

L'archivage d'événement est géré par le programme d'écoute de protocole et dépend du transport mais aussi de la façon dont vous configurez le programme d'écoute.

Récupération d'événements

La reprise d'événement est gérée par le programme d'écoute de protocole et dépend du transport mais aussi de la façon dont vous configurez le programme d'écoute.

Copyright IBM Corp. 2003, 2005