Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour implémenter le routage basé sur le contenu, le service de routage utilise MessageFilter des implémentations qui inspectent des sections spécifiques d’un message, telles que l’adresse, le nom du point de terminaison ou une instruction XPath spécifique. Si aucun des filtres de messages fournis avec .NET Framework 4.6.1 ne répond à vos besoins, vous pouvez créer un filtre personnalisé en créant une nouvelle implémentation de la classe de base MessageFilter .
Lors de la configuration du service de routage, vous devez définir des éléments de filtre (FilterElement objets) qui décrivent le type de MessageFilter et toutes les données de prise en charge requises pour créer le filtre, telles que des valeurs de chaîne spécifiques à rechercher dans le message. Notez que la création des éléments de filtre définit uniquement les filtres de message individuels ; pour utiliser les filtres pour évaluer et router les messages, vous devez également définir une table de filtres (FilterTableEntryCollection).
Chaque entrée de la table de filtre fait référence à un élément de filtre et spécifie le point de terminaison client vers lequel un message sera acheminé si le message correspond au filtre. Les entrées de table de filtre vous permettent également de spécifier une collection de points de terminaison de sauvegarde (BackupEndpointCollection), qui définit une liste de points de terminaison auxquels le message sera transmis en cas d’échec de transmission lors de l’envoi au point de terminaison principal. Ces points de terminaison seront testés dans l’ordre spécifié jusqu'à ce que l'un d'eux réussisse.
Filtres de messages
Les filtres de messages utilisés par le service de routage fournissent des fonctionnalités courantes de sélection de messages, telles que l’évaluation du nom du point de terminaison auquel un message a été envoyé, l’action SOAP ou le préfixe d’adresse auquel le message a été envoyé. Les filtres peuvent également être joints à une AND condition, de sorte que les messages ne seront routés vers un point de terminaison que si le message correspond aux deux filtres. Vous pouvez également créer des filtres personnalisés en créant votre propre implémentation de MessageFilter.
Le tableau suivant répertorie l’utilisation FilterType par le service de routage, la classe qui implémente le filtre de message spécifique et les paramètres requis FilterData .
| Type de filtre | Descriptif | Filtrer la signification des données | Exemple de filtre |
|---|---|---|---|
| Action | Utilise la ActionMessageFilter classe pour faire correspondre les messages contenant une action spécifique. | Action à laquelle appliquer un filtre. | <filter name="action1" filterType="Action" filterData="http://namespace/contract/operation" /> |
| Adresse de point de terminaison | Utilise la EndpointAddressMessageFilter classe, avec IncludeHostNameInComparison == true pour faire correspondre les messages contenant une adresse spécifique. |
Adresse à laquelle appliquer un filtre (dans l'en-tête À). | <filter name="address1" filterType="EndpointAddress" filterData="http://host/vdir/s.svc/b" /> |
| EndpointAddressPrefix | Utilise la PrefixEndpointAddressMessageFilter classe, avec IncludeHostNameInComparison == true pour faire correspondre les messages contenant un préfixe d’adresse spécifique. |
Adresse à laquelle appliquer un filtre utilisant le plus long préfixe correspondant. | <filter name="prefix1" filterType="EndpointAddressPrefix" filterData="http://host/" /> |
| and | Utilise la StrictAndMessageFilter classe qui évalue toujours les deux conditions avant de retourner. | filterData n’est pas utilisé ; Au lieu de cela, filter1 et filter2 ont les noms des filtres de message correspondants (également dans la table), qui doivent être combinés ET. | <filter name="and1" filterType="And" filter1="address1" filter2="action1" /> |
| Coutume | Type défini par l’utilisateur qui étend la MessageFilter classe et a un constructeur prenant une chaîne. | L’attribut customType est le nom de type complet de la classe à créer ; filterData est la chaîne à transmettre au constructeur lors de la création du filtre. | <filter name="custom1" filterType="Custom" customType="CustomAssembly.CustomMsgFilter, CustomAssembly" filterData="Custom Data" /> |
| NomDuPointD'accès | Utilise la EndpointNameMessageFilter classe pour faire correspondre les messages en fonction du nom du point de terminaison de service sur lequel ils sont arrivés. | Nom du point de terminaison de service, par exemple : « serviceEndpoint1 ». Ce doit être l'un des points de terminaison exposés sur le service de routage. | <filter name="stock1" filterType="Endpoint" filterData="SvcEndpoint" /> |
| MatchAll | Utilise la MatchAllMessageFilter classe. Ce filtre correspond à tous les messages arrivants. | filterData n’est pas utilisé. Ce filtre correspond toujours à tous les messages. | <filter name="matchAll1" filterType="MatchAll" /> |
| XPath | Utilise la XPathMessageFilter classe pour faire correspondre des requêtes XPath spécifiques dans le message. | Requête XPath à utiliser lors de la correspondance de messages. | <filter name="XPath1" filterType="XPath" filterData="//ns:element" /> |
L’exemple suivant définit les entrées de filtre qui utilisent les filtres de message XPath, EndpointName et PrefixEndpointAddress. Cet exemple montre également l’utilisation d’un filtre personnalisé pour les entrées RoundRobinFilter1 et RoundRobinFilter2.
<filters>
<filter name="XPathFilter" filterType="XPath"
filterData="/s12:Envelope/s12:Header/custom:RoundingCalculator = 1"/>
<filter name="EndpointNameFilter" filterType="EndpointName"
filterData="calculatorEndpoint"/>
<filter name="PrefixAddressFilter" filterType="PrefixEndpointAddress"
filterData="http://localhost/routingservice/router/rounding/"/>
<filter name="RoundRobinFilter1" filterType="Custom"
customType="RoutingServiceFilters.RoundRobinMessageFilter,
RoutingService" filterData="group1"/>
<filter name="RoundRobinFilter2" filterType="Custom"
customType="RoutingServiceFilters.RoundRobinMessageFilter,
RoutingService" filterData="group1"/>
</filters>
Remarque
La définition d’un filtre n’entraîne pas l’évaluation des messages par rapport au filtre. Le filtre doit être ajouté à une table de filtres, qui est ensuite associée au point de terminaison de service exposé par le service de routage.
Table d'espace de noms
Lorsque vous utilisez un filtre XPath, les données de filtre qui contiennent la requête XPath peuvent devenir extrêmement volumineuses en raison de l’utilisation d’espaces de noms. Pour résoudre ce problème, le service de routage permet de définir vos propres préfixes d’espace de noms à l’aide de la table d’espaces de noms.
La table d’espaces de noms est une collection d'objets qui définit les préfixes pour les espaces de noms NamespaceElement courants pouvant être utilisés dans un XPath. Voici les espaces de noms et les préfixes d’espace de noms par défaut contenus dans la table d’espaces de noms.
| Préfixe | Namespace |
|---|---|
| s11 | http://schemas.xmlsoap.org/soap/envelope |
| s12 | http://www.w3.org/2003/05/soap-envelope |
| wsaAugust2004 | http://schemas.xmlsoap.org/ws/2004/08/addressing |
| wsa10 | http://www.w3.org/2005/08/addressing |
| sm | http://schemas.microsoft.com/serviceModel/2004/05/xpathfunctions |
| tempuri | http://tempuri.org |
| ser | http://schemas.microsoft.com/2003/10/Serialization |
Lorsque vous savez que vous utiliserez un espace de noms spécifique dans vos requêtes XPath, vous pouvez l’ajouter à la table d’espaces de noms avec un préfixe d’espace de noms unique et utiliser le préfixe dans n’importe quelle requête XPath au lieu de l’espace de noms complet. L’exemple suivant définit un préfixe de « custom » pour l’espace de noms "http://my.custom.namespace", qui est ensuite utilisé dans la requête XPath contenue dans filterData.
<namespaceTable>
<add prefix="custom" namespace="http://my.custom.namespace/"/>
</namespaceTable>
<filters>
<filter name="XPathFilter" filterType="XPath" filterData="/s12:Envelope/s12:Header/custom:RoundingCalculator = 1"/>
</filters>
Tables de filtres
Bien que chaque élément de filtre définit une comparaison logique qui peut être appliquée à un message, la table de filtres fournit l’association entre l’élément de filtre et le point de terminaison du client de destination. Une table de filtres est une collection nommée d’objets FilterTableEntryElement qui définissent l’association entre un filtre, un point de terminaison de destination principal et une liste de points de terminaison de sauvegarde alternatifs. Les entrées de table de filtre vous permettent également de spécifier une priorité facultative pour chaque condition de filtre. L’exemple suivant définit deux filtres, puis définit une table de filtres qui associe chaque filtre à un point de terminaison de destination.
<routing>
<filters>
<filter name="AddAction" filterType="Action" filterData="Add" />
<filter name="SubtractAction" filterType="Action" filterData="Subtract" />
</filters>
<filterTables>
<table name="routingTable1">
<filters>
<add filterName="AddAction" endpointName="Addition" />
<add filterName="SubtractAction" endpointName="Subtraction" />
</filters>
</table>
</filterTables>
</routing>
Priorité d’évaluation du filtre
Par défaut, toutes les entrées de la table de filtres sont évaluées simultanément et le message en cours d’évaluation est acheminé vers le ou les points de terminaison associés à chaque entrée de filtre correspondante. Si plusieurs filtres doivent avoir la valeur true, et si le message est en mode monodirectionnel ou duplex, le message est envoyé en mode multidiffusion aux points de terminaison de tous les filtres correspondants. Les messages de demande-réponse ne peuvent pas être multidiffusion, car une seule réponse peut être retournée au client.
Une logique de routage plus complexe peut être implémentée en spécifiant des niveaux de priorité pour chaque filtre ; le service de routage évalue tous les filtres au niveau de priorité le plus élevé en premier. Si un message correspond à un filtre de ce niveau, aucun filtre d’une priorité inférieure n’est traité. Par exemple, un message unidirectionnel entrant est d’abord évalué par rapport à tous les filtres avec une priorité de 2. Le message ne correspond à aucun filtre à ce niveau de priorité. Par conséquent, le message est comparé aux filtres avec une priorité de 1. Deux filtres de priorité 1 correspondent au message, car il s’agit d’un message unidirectionnel routé vers les deux points de terminaison de destination. Étant donné qu’une correspondance a été trouvée parmi les filtres de priorité 1, aucun filtre de priorité 0 n’est évalué.
Remarque
Si aucune priorité n’est spécifiée, la priorité par défaut 0 est utilisée.
L’exemple suivant définit une table de filtres qui spécifie les priorités 2, 1 et 0 pour les filtres référencés dans la table.
<filterTables>
<filterTable name="filterTable1">
<add filterName="XPathFilter" endpointName="roundingCalcEndpoint"
priority="2"/>
<add filterName="EndpointNameFilter" endpointName="regularCalcEndpoint"
priority="1"/>
<add filterName="PrefixAddressFilter" endpointName="roundingCalcEndpoint"
priority="1"/>
<add filterName="MatchAllMessageFilter" endpointName="defaultCalcEndpoint"
priority="0"/>
</filterTable>
</filterTables>
Dans l'exemple précédent, si un message correspond à XPathFilter, il sera acheminé vers roundingCalcEndpoint et aucun autre filtre du tableau ne sera évalué puisque tous les autres filtres sont d'une priorité inférieure. Toutefois, si le message ne correspond pas au XPathFilter, il sera évalué par rapport à tous les filtres de la priorité inférieure suivante, EndpointNameFilter et PrefixAddressFilter.
Remarque
Si possible, utilisez des filtres exclusifs au lieu de spécifier une priorité, car l’évaluation de priorité peut entraîner une dégradation des performances.
Listes de sauvegarde
Chaque filtre de la table de filtres peut éventuellement spécifier une liste de sauvegarde, qui est une collection nommée de points de terminaison (BackupEndpointCollection). Cette collection contient une liste ordonnée de points de terminaison auxquels le message sera transmis en cas de CommunicationException lors de l'envoi au point de terminaison principal spécifié dans EndpointName. L’exemple suivant définit une liste de sauvegarde nommée « backupServiceEndpoints » qui contient deux points de terminaison.
<filterTables>
<filterTable name="filterTable1">
<add filterName="MatchAllFilter1" endpointName="Destination" backupList="backupEndpointList"/>
</filterTable>
</filterTables>
<backupLists>
<backupList name="backupEndpointList">
<add endpointName="backupServiceQueue" />
<add endpointName="alternateServiceQueue" />
</backupList>
</backupLists>
Dans l’exemple précédent, si un envoi au point de terminaison principal « Destination » échoue, le service de routage tente d’envoyer à chaque point de terminaison de la séquence qu’ils sont répertoriés, d’abord d’envoyer à backupServiceQueue et d’envoyer ensuite à alternateServiceQueue si l’envoi à backupServiceQueue échoue. Si tous les points de terminaison de sauvegarde échouent, une erreur est retournée.