Une classe de travail est utilisée pour classifier les demandes afin de leur appliquer une stratégie. Deux types de stratégie peuvent être appliqués aux demandes : les règles de routage et les stratégies de service. Vous pouvez créer des règles de routage pour les demandes HTTP et SOAP. Vous pouvez créer des stratégies de service pour les demandes HTTP, IIOP, SOAP et JMS. De plus, les classes de travail peuvent contenir des règles de classification pour les deux types de stratégie sauf pour le service JMS. Les règles de classification ne sont pas prises en charge pour les classes de travail JMS. Les règles de routage et les stratégies de service des classes de travail ne sont pas prises en charge pour IIOP et JMS pour les applications déployées sous z/OS. WebSphere Application Server z/OS met à disposition une classification pour le service JMS et le protocole IIOP.
Règle de routage | Description |
---|---|
permit:<nom_application> | Dans cette règle de routage, nom_application est le nom de l'application vers laquelle effectuer le routage avec un spécificateur d'édition facultatif. La demande se poursuit ainsi normalement. |
permitsticky:<nom_application> | La règle de routage permitsticky est similaire à la règle de routage permit, mais le routeur ODR gère également l'affinité client vers serveur pour les demandes futures émanant du même client. Dans ce cas, le routeur ODR ajoute un en-tête SET-COOKIE à la réponse avant d'envoyer celle-ci au client. |
reject:<code_erreur_HTTP> | Avec cette règle de routage, le routeur ODR rejette les demandes associées au code d'erreur HTTP indiqué. Par exemple, reject:503 renvoie une erreur 503 de service indisponible. |
redirect:<URL> | Avec cette règle de routage, le routeur ODR redirige la demande vers l'URL spécifiée. Le format de l'URL est protocol:// ;. Exemple d'URL valide : http://w3.ibm.com. |
Les stratégies de service correctes correspondent simplement aux noms de classe de transaction. La classe de transaction fait référence à une classe de service unique.
On compte quatre types de classe de travail :
Classe de travail | Description |
---|---|
Règle de routage d'application | Indique comment déterminer la règle de routage d'une demande adressée à une application installée sur WebSphere Extended Deployment. |
Stratégie de service d'application | Indique comment déterminer la stratégie de service d'une demande adressée à une application installée sur WebSphere Extended Deployment. |
Règle de routage de cluster de serveurs génériques | Indique comment déterminer la règle de routage d'une demande adressée à un cluster de serveurs génériques. |
Stratégie de service de cluster de serveurs génériques | Indique comment déterminer la stratégie de service d'une demande adressée à un cluster de serveurs génériques. |
Le diagramme ci-après illustre le flux d'une demande ciblée pour une application installée sur WebSphere Extended Deployment. La demande est appliquée à une classe de travail de règle de routage d'application pour déterminer la règle de routage. Si la règle de routage obtenue est permit ou permitsticky, la demande est acheminée vers une classe de travail de stratégie de service d'application afin de déterminer le nom de la stratégie de service et de la classe de transaction.
Chaque application contient des classes de règle de routage d'application et de service d'application. Vous pouvez aussi créer des classes de travail supplémentaires qui ne sont pas des classes par défaut. Chaque classe de travail est associée à une action de correspondance par défaut. La règle de routage par défaut d'une application est permit:<nom_application>. La stratégie de service par défaut est Default_TC, c'est-à-dire la classe de transaction par défaut.
Chaque classe de travail contient une liste ordonnée et facultative de règles qui sont évaluées pour une demande particulière afin de déterminer la stratégie de cette dernière. Chaque règle consiste en une expression booléenne et une valeur de stratégie. Si l'expression renvoie true pour une demande particulière, la stratégie associée à cette règle est employée.
La syntaxe et la sémantique d'une expression booléenne d'une règle sont similaires à celles de la clause WHERE d'une expression SQL (Structured Query Language). Plus précisément, la syntaxe d'une expression est définie par la spécification Java Message Service (JMS) 1.1. Pour plus d'informations, voir Classification des demandes basées sur des règles ODR.
Dans la spécification JMS, les identificateurs font référence à différents attributs pouvant être associés à une demande, par exemple, un paramètre de demande, un cookie ou un en-tête HTTP spécifique. Un identificateur JMS peut être considéré comme une variable de demande ou opérande. Ces opérandes peuvent être propres à un protocole. Par exemple, le nom de service SOAP est un opérande qui n'est valide que dans une classe de travail SOAP.
La liste des opérandes est dynamique et les opérandes répertoriés ici sont des opérandes de base. Pour plus d'informations, consultez la documentation du produit contenant la liste complète. Le tableau ci-dessous répertorie les opérandes et les protocoles associés.
Variable de demande | Protocoles valides | Description |
---|---|---|
|
IIOP | Nom de l'application d'entreprise contenant l'EJB. |
clienthost | HTTP SOAP
|
Nom d'hôte complet du client. Il s'agit de la valeur du nom d'hôte de la commande IP. Cet opérande ne prend pas en charge les opérateurs numériques tels que >, >=, <, <=. |
|
IIOP | Nom du port client. |
clientipv4 | HTTP SOAP |
clientipv4 – Adresse IP de l'ordinateur client dans le format Internet Protocol version 4 (IPv4) à quatre éléments séparés par des points n.n.n.n. |
clientipv6 | HTTP SOAP |
Adresse Internet Protocol version 6 (IPv6) 128 bits du type x:x:x:x:x:x:x:x suivant le RFC 1924 de l'ordinateur client. |
cookie$<nom> | HTTP SOAP |
Nom d'un cookie. Par exemple, l'expression cookie$Nom_cookie='Nom_cookie' vérifie si une demande contient le cookie Nom_cookie associé à la valeur Nom_cookie. Pour vérifier la présence ou l'absence d'un cookie particulier, utilisez l'une des expressions suivantes : cookie$MonNomCookie IS NOT NULL cookie$MonNomCookie IS NULL |
|
IIOP | Nom de module d'un EJB. |
|
IIOP | Nom d'un EJB. |
|
IIOP | Nom d'une méthode contenue dans l'EJB. |
gid | HTTP SOAP |
ID groupe de l'émetteur de la demande. |
header $<nom> | HTTP SOAP |
Nom et valeur de l'en-tête. Par exemple, l'expression header$Hote='localhost' vérifie si une demande contient un en-tête hôte HTTP avec la valeur localhost. Pour vérifier la présence ou l'absence de l'en-tête d'hôte, utilisez l'une des expressions suivantes :
header$Hote IS NOT NULL header$Hote IS NULL |
HTTPMethod | HTTP SOAP |
Méthode HTTP de la demande. Les valeurs possibles sont POST, GET, PUT et DELETE. |
MIMEType | HTTP SOAP |
Type MIME de la demande. |
operation | SOAP | Nom d'une opération de service Web. |
port | HTTP SOAP IIOP |
Port d'écoute sur lequel la demande a été reçue. |
protocol | HTTP SOAP |
Protocoles de communication qui transmettent la demande. Les protocoles pris en charge actuellement sont HTTP, HTTPS, SOAP et SOAPS. |
queryparm$<nom> | HTTP SOAP |
Nom et valeur de l'en-tête. Par exemple, l'expression queryparm$Hote='EST' vérifie si la demande contient un paramètre de demande HTTP de fuseau horaire de valeur EST. Pour vérifier la présence ou l'absence d'un paramètre de demande particulier, utilisez l'une des expressions suivantes : queryparm$zone IS NOT NULL queryparm$zone IS NULL |
serverhost | HTTP SOAP
|
Nom d'hôte complet du serveur. Cet opérande ne prend pas en charge les opérateurs numériques tels que >, >=, <, <=. |
serveripv4 | HTTP SOAP |
Adresse IP de l'ordinateur serveur dans le format IPv4 à quatre éléments séparés par des points n.n.n.n. |
serveripv6 | HTTP SOAP |
Adresse IPv6 128 bits du type x:x:x:x:x:x:x:x suivant le RFC 1924 de l'ordinateur serveur. |
service | SOAP |
Nom d'un service Web. |
uid | HTTP SOAP |
ID utilisateur de l'émetteur de la demande. |
clienthost LIKE '%.ibm.com''%.ibm.com' est un littéral utilisé pour comparer le nom d'hôte client pour une demande. Cette expression est vraie pour toutes les demandes qui émanent d'une machine du domaine ibm.com. Placez les littéraux chaîne entre guillemets simples. Ne placez pas les littéraux numériques entre guillemets simples. Utilisées avec les opérateurs AND, OR et NOT, les parenthèses permettent de former des expressions booléennes complexes. La spécification JMS 1.1 propose une description détaillée de ces éléments.
WebSphere Extended Deployment prend en charge les opérateurs ci-après dans les expressions de règles. Ces opérateurs sont également appelés prédicats dans la terminologie SQL car ils figurent dans une clause WHERE ou HAVING. La distinction entre les minuscules et les majuscules n'est pas nécessaire pour les opérateurs.
Opérateur | Description |
---|---|
OR | Opérateur logique OR. |
AND | Opérateur logique AND. |
NOT | Opérateur logique de négation. |
IN | Exprime un opérande avec des valeurs multiples dans une même expression. Sa signification est conforme à la spécification SQL de l'opérateur. Par exemple, si un opérande s'appelle port et qu'un utilisateur souhaite exprimer que port peut avoir pour valeur 9080, 9090 et/ou 9091, le fragment d'expression sera : port IN (9080,9090,9091) Dans SQL, la façon dont les valeurs à l'intérieur des parenthèses sont exprimées dépend du type de données de port. Cela signifie que si port est de type entier, la syntaxe des valeurs figurant hors guillemets simples est correcte. Si port est de type chaîne, l'expression correcte est :
port IN (‘9080’, ‘9090’, ‘9091’) |
LIKE | Exprime une correspondance de motifs pour les valeurs d'opérande chaîne ; il est conforme au langage SQL au niveau de sa signification et de son utilisation. La valeur doit contenir le caractère générique (%) à la position où la correspondance de motif est censée commencer. Par exemple, l'expression
host LIKE %blancapermet de rechercher les occurrences du terme blanca ou tout autre terme se terminant par blanca, alors que l'expression host LIKE blanca%permet de rechercher les occurrences du terme blanca ou tout autre terme commençant par blanca. L'expression host LIKE %blanca%permet de rechercher les occurrences du terme blanca ou tous les termes comportant la chaîne blanca. Du point de vue de l'implémentation du code, la classe java.util.regex.Pattern est utilisée. |
= | Opérateur d'égalité utilisé pour exprimer une correspondance différenciant les minuscules et les majuscules. |
> | Opérateur supérieur à, à utiliser avec des opérandes numériques |
>= | Opérateur supérieur ou égal à, à utiliser avec des opérandes numériques. |
< | Opérateur inférieur à, à utiliser avec des opérandes numériques |
<= | Opérateur inférieur ou égal à, à utiliser avec des opérandes numériques |
< > | Opérateur d'inégalité |
BETWEEN | Cet opérateur est utilisé conjointement avec l'opérateur AND pour sélectionner un intervalle de valeurs comprenant la première valeur (la plus basse) et la dernière valeur (la plus haute). Ensemble, ils agissent sur des nombres et des dates. |
IS NULL | Teste un opérande dont la valeur est NULL. |
IS NOT NULL | Teste un opérande dont la valeur est autre que NULL. |
Related concepts
Classification des demandes basées sur des règles ODR
Related tasks
Définition d'une stratégie de service
Activation d'éditions simultanées
Validation d'une édition