Mettre en œuvre tous types de requêtes lors du filtrage des résultats à l’aide de PreOperation RetrieveMultiple

Catégorie : Conception, performances, sécurité, capacité de prise en charge

Potentiel d’impact : Moyen

Symptômes

Les appels RetrieveMultiple à partir d’applications différentes, affichent des résultats différents.

• Par exemple : les mêmes vues dans les applications héritées donnent des résultats différents dans de nouvelles applications.

Recommandation

Notes

Les messages Retrieve et RetrieveMultiple sont généralement ceux les plus couramment utilisés. Les plug-ins pour ces messages peuvent affecter de manière importante les performances du système. En général, vous devez éviter d’utiliser des plug-ins pour ces messages si les conditions peuvent être satisfaites avec une autre méthode. Pour plus d’informations, voir : Restreindre l’inscription de plug-ins pour les messages Retrieve et RetrieveMultiple

Les plug-ins enregistrés dans le message RetrieveMultiple sont généralement destinés à filtrer les résultats renvoyés par des requêtes pour une entité. Il existe deux stratégies pour cela : avec un plug-in enregistré lors de la phase PostOperation ou PreOperation.

Filtrage PostOperation

Dans la phase PostOperation, évaluez les enregistrements renvoyés dans la propriété OutputParameters BusinessEntityCollection Entities et supprimez les entités qui ne doivent pas être renvoyées.

Cette approche peut modifier le nombre prévu d’enregistrements renvoyés dans chaque page de résultats et peut entraîner des expériences incohérentes lorsque les données sont affichées dans une application.

Filtrage PreOperation

Dans la phase PreOperation, évaluez la propriété InputParametersQuery et modifiez la requête pour filtrer les éléments renvoyés avant son exécution.

Lorsque vous utilisez cette approche, vous devez mettre en œuvre la filtrage approprié pour les différents types de requêtes possibles, avant tout : FetchExpression et QueryExpression. Si vous implémentez seulement l’un de ces éléments, les différentes applications qui utilisent l’autre type de requête n’appliquent pas vos modifications.

Même si les messages QueryExpressionToFetchXml et FetchXmlToQueryExpression offrent la possibilité de convertir un type de requête en une autre, en raison de l’impact sur les performances de l’inclusion d’autres appels dans RetrieveMultiple, nous vous recommandons de ne pas utiliser ces messages dans ce contexte. Vous devez en revanche, mettre en œuvre le filtrage en utilisant la logique équivalente dans les deux.

Il existe un troisième type de requête qui peut aussi être utilisé avec RetrieveMultiple : QueryByAttribute. Ce type de requête ne fournit pas de filtrage complexe et il n’est pas possible d’inclure une logique de filtrage plus complexe dans un plug-in. Heureusement, ce type de requête n’est pas fréquemment utilisé. Selon la sensibilité du filtrage que vous ajoutez, vous pouvez choisir de rejeter des requêtes de ce type en levant une exception InvalidPluginExecutionException.

Exemple

Voir Exemple : Modifiez la requête dans la phase PreOperation pour obtenir un exemple de la stratégie que nous vous conseillons.

Schémas problématiques

Lorsqu’une personne écrit un plug-in pour modifier les enregistrements renvoyés dans une application qui utilise un seul type de requête utilisé par cette application, FetchExpression ou QueryExpression, les résultats peuvent ne pas être cohérents dans d’autres applications ou si l’application change le type de requête utilisé. Écrivez des plug-ins qui fournissent le même résultat indépendamment de l’application.

Informations supplémentaires

Lorsque l’API Web est utilisée, les requêtes GET sur une collection sont converties en QueryExpression à moins que la requête utilise FetchXml comme décrit dans Extraire et exécuter des requêtes prédéfinies. Dans ce cas, les requêtes utilisent FetchExpression.

Unified Interface a remplacé le client Web hérité pour les applications pilotées par modèle. Unified Interface utilise le FetchXml défini dans les propriétés SavedQuery.FetchXml ou UserQuery.FetchXml. Pour des performances optimisées, Unified Interface ne convertit pas les données FetchXml en QueryExpression avant d’exécuter ces requêtes, comme le faisait le client Web hérité. Par conséquent, les requêtes qui ont été modifiées dans le code du plug-in pour le client Web hérité qui utilisait QueryExpression, n’appliquent pas les mêmes modifications maintenant que la requête pour prendre en charge les vues est transmise à l’aide de FetchExpression, sauf si le code du plug-in est écrit pour appliquer la même logique aux requêtes FetchExpression.

Voir aussi

Exemple : Modifier la requête dans la phase PreOperation
Interroger les données à l’aide du SDK pour .NET
Interroger des données à l’aide de FetchXml
Générer des requêtes avec QueryExpression
Restreindre l’inscription de plug-ins pour les messages Retrieve et RetrieveMultiple
Unified Interface Community

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).