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 :
- programme d'écoute de protocole HTTP
- programme d'écoute de protocole HTTPS
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 :
- WorkerThreadCount Nombre total d'unités d'exécution disponibles pour la structure de programme d'écoute de protocole, correspondant au nombre de demandes qu'il peut traiter en parallèle.
- RequestPoolSize Nombre maximal de demandes pouvant être enregistrées avec la structure de programme d'écoute de protocole. Si elle reçoit un nombre excessif de demandes, elle ne peut plus les traiter.
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 :
- Le programme d'écoute de protocole détermine le Charset du message entrant selon les règles suivantes :
- Le programme d'écoute tente d'extraire la valeur Charset du paramètre de même de la valeur d'entête Content-Type du message HTTP.
- Si aucune valeur Charset n'est obtenue depuis l'en-tête Content-Type, le programme d'écoute de protocole tente de lire la valeur de la propriété URLsConfiguration pour ce programme d'écoute.
- Si la valeur Charset n'est pas obtenue à l'aide des méthodes décrites aux étapes précédentes et si le type ContentType du message est text avec un sous-type (par exemple, text/xml, text/plain, etc.), le programme d'écoute utilise ISO-8859-1 comme valeur de Charset par défaut. Autrement, la valeur de Charset ne sera pas utilisée.
- Le programme d'écoute détermine le MimeType du message de demande selon ces règles :
- Si vous avez configuré TransformationRules pour l'URL utilisée par le message de demande entrant et si le ContentType de la demande correspond au ContentType d'une TransformationRule, le programme d'écoute utilise la TransformationRule pour extraire le MimeType en vue de la conversion du message de demande en un objet métier de demande. Le programme d'écoute tente de trouver l'occurrence TransformationRule exacte en fonction de la valeur ContentType (text/xml, par exemple) dans la propriété URLsConfiguration de l'URL demandée.
- En cas d'échec, le programme d'écoute tente de trouver une TransformationRule s'appliquant à plusieurs ContentType sous l'URL de la demande URL (*/*, par exemple).
- Si les étapes précédentes ne parviennent pas à identifier le MimeType, la valeur de ContentType sera utilisée comme MimeType pour appeler le gestionnaire de données et convertir le message de demande en objet métier de demande.
- Le programme d'écoute détermine le ContentType en extrayant le type/sous-type de l'entête Content-Type du message HTTP entrant.
- Le programme d'écoute détermine l'en-tête Content-Type à partir de celui du message HTTP entrant.
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 détermine le Charset du message de réponse selon ces règles :
- Si Charset est indiqué dans le Protocol Config MO de l'objet métier de réponse, sa valeur est utilisée.
- Si aucune valeur Charset n'est indiquée dans l'entête Protocol Config MO de l'objet métier de réponse, le programme d'écoute vérifie si Charset est indiqué dans le TLO.
- Si aucun Charset n'est indiqué dans le TLO et que la réponse possède le même ContentType que la demande, le Charset de la demande sera employé pour la réponse.
- Si les opérations précédentes n'ont pu déterminer la valeur Charset de la réponse et si la partie type du ContentType du message est text avec n'importe quel sous-type (par exemple,text/xml, text/plain, etc.), le programme d'écoute utilise ISO-8859-1 comme valeur de Charset par défaut. Autrement, la valeur de Charset ne sera pas utilisée.
- Le programme d'écoute détermine le MimeType du message de réponse selon ces règles :
- Attribut MimeType du TLO
- Si l'attribut MimeType de TLO et si le ContentType de la demande et de la réponse coïncide, le programme d'écoute utilise le MimeType de la demande pour le message de réponse.
- Dans le cas contraire, le programme d'écoute utilise la valeur de ContentType comme MimeType.
- Le programme d'écoute détermine le ContentType du message de réponse selon ces règles :
- Si l'entête Content-Type est indiqué dans le Protocol Config MO de l'objet métier de réponse, la partie type/sous-type de cet entête sera employé comme ContentType.
- Si l'entête Content-Type n'est pas indiqué dans le Protocol Config MO de l'objet métier de réponse, le programme d'écoute construit un en-tête Content-Type à l'aide des ContentType et Charset déterminés (si le Charset a été déterminé pour le message de réponse).
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 :
- 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).
- 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.
- 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.
- 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 :
- Mise en cache : Le programme d'écoute de protocole n'implémente pas de fonctions de mise en cache comme défini dans les spécifications HTTP (RFC2616)
- Proxy : Le programme d'écoute de protocole n'implémente pas de fonctions proxy comme défini dans les spécifications HTTP (RFC2616)
- Connexions persistantes : Le programme d'écoute de protocole ne prend pas en charge de connexions persistantes comme défini dans les spécifications HTTP (RFC2616). Le programme d'écoute de protocole suppose que la portée de chaque connexion HTTP est une demande de client simple et referme la connexion quand la demande de service est traitée. Le programme d'écoute de protocole ne tente pas de réutiliser la connexion d'un appel de service à un autre.
- Redirections : Le programme d'écoute de protocole ne prend pas en charge les redirections.
- Transfert de fichiers volumineux : Le programme d'écoute de protocole ne peut être utilisé pour les transferts de fichiers volumineux. Vous pouvez envisager de transmettre les fichiers volumineux par référence.
- Gestion d'état : Le programme d'écoute de protocole ne prend pas en charge le mécanisme de gestion d'état HTTP décrit par RFC2965.
- Cookies : Le programme d'écoute de protocole ne prend pas en charge les cookies.
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 :
- Programme d'écoute de protocole HTTP aucune persistance et, par conséquent, aucune livraison garantie
- Programme d'écoute de protocole HTTPS aucune persistance et, par conséquent, aucune livraison garantie
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.
- Programme d'écoute de protocole HTTP L'écoute s'effectue au niveau des demandes de connexions ServerSocket for HTTP
- Programme d'écoute de protocole HTTPS L'écoute s'effectue sur une couche ServerSocket sécurisées pour des demandes de connexion HTTPS
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.
- Programme d'écoute de protocole HTTP Par nature, HTTP est synchrone et non persistant. De même, l'état d'événement n'est pas conservé.
- Programme d'écoute de protocole HTTPS Par nature, HTTP est synchrone et non persistant. De même, l'état d'événement n'est pas conservé.
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.
- Programme d'écoute de protocole HTTP Les événements sont récupérés en extrayant des demandes HTTP de la connexion.
- Programme d'écoute de protocole HTTPS Les événements sont récupérés en extrayant des demandes HTTP de la connexion.
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.
- Programme d'écoute de protocole HTTP En raison de la nature synchrone non persistante du transport, l'archivage n'a pas lieu.
- Programme d'écoute de protocole HTTPS En raison de la nature synchrone non persistante du transport, l'archivage n'a pas lieu.
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.
- Programme d'écoute de protocole HTTP En raison de la nature non persistante du transport, la récupération d'événements n'a pas lieu.
- Programme d'écoute de protocole HTTPS En raison de la nature non persistante du transport, la récupération d'événements n'a pas lieu.
