La présente annexe décrit comment utiliser la syntaxe de règle de contenu (modèle) pour le composant CBR et la méthode d'acheminement CBR de Dispatcher. Elle contient en outre des scénarios et des exemples de syntaxe.
Ne s'applique que si vous avez sélectionné le type de règle Contenu.
Entrez la syntaxe voulue en tenant compte des restrictions suivantes :
Les mots clés réservés sont toujours suivis d'un signe égal «=».
Un navigateur demandant la page http://www.entreprise.com/path/webpage.htm peut obtenir des résultats du type suivant :
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
Par exemple, la commande suivante n'est valide qu'à partir de l'invite cbrcontrol>> ou d'un fichier de configuration :
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Pour que cette commande fonctionne dans l'invite du système d'exploitation lorsque vous utilisez des caractères spéciaux, vous devez placez des guillemets de part et d'autre de la commande :
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Si vous omettez les guillemets, le motif peut être tronqué lors de la sauvegarde de la règle dans CBR.
Ci-dessous, se trouve un ensemble de scénarios et des exemples d'utilisation des syntaxes de modèle
Scénario 1 :
La configuration d'un cluster implique un ensemble de serveurs Web pour le contenu HTML standard, un autre ensemble de serveurs Web avec WebSphere Application Server pour les demandes de servlet, un autre ensemble de serveurs Lotus Notes pour les fichiers NSF, etc. Pour effectuer la différence entre les pages demandées, l'accès aux données du client est requis. Il est également nécessaire de les envoyer aux serveurs appropriés. Les règles de correspondance de modèle de contenu permettent d'effectuer une séparation, nécessaire à l'accomplissement de ces tâches. Plusieurs règles sont configurées afin que la séparation des demandes nécessaire se produise automatiquement. Par exemple, les commandes suivantes provoquent les trois divisions indiquées :
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
Si une demande de fichier NSF est reçue par Load Balancer, la règle servlets est vérifiée mais ne correspond pas. La demande est ensuite vérifiée par la règle notes qui trouve une correspondance. L'équilibrage de charge du client est effectué entre le serveur 3 et le serveur 4.
Scénario 2
Le contrôle par le site Web principal de plusieurs groupes internes constitue un autre scénario classique. Par exemple, l'ensemble de serveurs et le contenu de www.company.com/software sont différents de ceux de www.company.com/hardware. Etant donné que les demandes dépendent toutes du cluster www.company.com racine, les règles de contenu sont requises pour trouver les différences d'URI et pour effectuer l'équilibrage de charge. La règle du scénario peut être du type suivant :
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
Scénario 3
Pour certaines associations, l'ordre de recherche des règles est important. Par exemple, dans le scénario 2, les clients ont été séparés en fonction d'un répertoire dans leur chemin de demande. Cependant, le répertoire cible peut apparaître à plusieurs niveaux du chemin et la signification est différente en fonction de l'emplacement. Par exemple, la cible de www.company.com/pcs/fixes/software est différente de celle de www.company.com/mainframe/fixes/software. Les règles doivent être définies pour prendre en compte cette possibilité et ne doivent pas inclure trop de scénarios en même temps. Par exemple, la recherche générique du test «uri=*/software/* » est trop large. D'autres règles peuvent être structurées de la manière suivante :
Vous pouvez associer plusieurs recherches afin de restreindre la recherche :
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
Dans le cas où il n'est pas possible d'utiliser des combinaisons, l'ordre est important :
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
La deuxième règle permet de détecter l'apparition de «pcs» dans des répertoires ultérieurs du chemin et non le premier.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
Dans la plupart des cas, vous pouvez compléter les règles par une règle par défaut toujours vrai afin de détecter tous les éléments non pris en compte par les autres règles. Un serveur peut également renvoyer un message du type «Ce site est actuellement indisponible, faites une nouvelle tentative ultérieurement» dans les scénarios pour lesquels aucun autre serveur ne peut renvoyer de réponse pour ce client.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5