Comment rendre votre CRM rapide ?
Publié le : 13/01/2016 dans IT, Logiciel CRM Par : Jean-Sébastien Alet Tags :

Comment améliorer vos performances de recherche dans votre CRM

Nous allons continuer la série consacrée aux performances, initiée avec ce premier billet parlant des index. Je vais rappeler que ce sont des billets à forte coloration technique qui s’adressent donc à un public sinon averti, du moins présentant un tel profil.

Nous avons vu dans le post précédent qu’afin d’obtenir des performances satisfaisantes sur des tables de données volumineuses (au-delà de 100.000 lignes), il s’avère indispensable de créer des index. Cela suppose de connaitre les champs (ou ensemble de champs) qui seront à indexer, et donc de connaitre les recherches qui vont être effectuées sur les tables : quels seront les critères, les résultats affichés…

Les listes de recherche E-DEAL CRM laissent une vaste latitude à l’utilisateur en termes de recherche (tant sur le choix des critères que des résultats) mais nous allons voir comment mettre en place une politique de recherche qui soit satisfaisante tant en termes métier qu’en temps de réponse, dans un contexte d’importants volumes de données (plusieurs centaines de milliers, ou millions d’enregistrements).

Définir un cadre

Dans un contexte de base de données avec un volume important de données, on sait que les performances sont un enjeu important. Lorsqu’un projet démarre, il est alors nécessaire de prendre en compte cet aspect dès la phase de cadrage, car il peut influer sur

  • la définition des recherches,
  • la possibilité à l’utilisateur final de les personnaliser et
  • la politique de gestion de droits.

Il s’avère donc judicieux de poser un cadre qui, tout en laissant une certaine liberté à l’utilisateur, posera certaines contraintes nécessaires pour obtenir des temps de réponse satisfaisants. Ce cadre permettra de définir la politique d’indexation adéquate : concrètement, savoir quels champs ou groupes de champs indexer (index composés), et comment les indexer (index avec fonction).

Les listes de recherches

Prévoir les index à créer

Le meilleur moyen de définir un tel cadre avec les listes de recherche E-DEAL CRM est de définir des groupes de critères obligatoires qui vont obliger l’utilisateur à saisir un ensemble minimal de critères afin de pouvoir effectuer sa recherche. Cela permettra de connaitre la typologie de requêtes exécutées sur la base de données, et donc de la préparer en conséquence.

Un exemple sera plus parlant… Une recherche de personnes pourra se concevoir comme étant de trois typologies différentes:

  • Au moins le N° de client
  • OU au moins le Nom ET le Code Postal
  • OU au moins le Nom ET le n° de téléphone

Cela se définira dans une liste XML de la manière suivante:

<mandatory-group id="gp1" nb-of-criteria="1"/>
<mandatory-group id="gp2" nb-of-criteria="2"/>
<mandatory-group id="gp3" nb-of-criteria="2"/>
<line>
<field value="PerName" mandatory-groups="gp2;gp3"></field>
<field value="PerNumClient" mandatory-groups="gp1"/>
</line>
<line>
<field value="PerPhone" mandatory-groups="gp3"></field>
<field value="PerCity"/>
<field value="PerZip" mandatory-groups="gp2"/>

Une fois ce cadre défini, il en découle naturellement la nature des index à créer:

  • Index sur Upper(PerNumClient)
  • Index sur Upper(PerName),Upper(PerZip)
  • Index sur Upper(PerName),Upper(PerPhone)

Les tris

Des tris par défaut sont souvent spécifiés dans les listes de recherche (Nom et Prénom sur une liste de recherche d’individus est le premier exemple auquel on pense). Ne pas oublier qu’un tri sur des millions d’enregistrements n’est pas une action anodine, et qu’il conviendra de restreindre les résultats en rendant des critères de recherche obligatoire.

La gestion des droits

Lorsqu’un partitionnement, ou une gestion des droits de type « propriétaire » est mis en œuvre, cela se traduit dans la plupart des cas par une modification de la requête permettant de filtrer les résultats à la source. Dans certains cas par contre, cela peut se traduire par un fonctionnement en deux étapes : d’abord la recherche des résultats en base, puis parcours des résultats pour filtrer les enregistrements visibles par l’utilisateur

Dans ce cas de figure, il est nécessaire de rendre obligatoire des critères de recherche afin de réduire les résultats initiaux. Une autre piste de solution est l’ajout de filtres « dynamiques », qui reproduiront la gestion des droits, afin de réduire au préalable les résultats à traiter.

Les jointures

Toujours dans le cas de forts volumes (comme c’est souvent le cas dans un CRM pour une activité BtoC), la multiplication des jointures entraine souvent une dégradation des performances. Il est donc sage de les limiter autant que faire se peut.

Par exemple, dans le cas où un filtre sur une table référence est mis en place au niveau d’une liste de recherche, il est préférable de l’exprimer de façon à utiliser l’identifiant (et l’index qui a été automatiquement créé) retourné par une fonction dynamique

<filter>"PerCivID = "+getRefIDByCode("PerCivID","MR")</filter>

plutôt que d’utiliser la syntaxe suivante qui va forcer une jointure avec la table RefValues

<filter>"PerCivID:RefVal='MR'"</filter>

 

La personnalisation des listes

Dans ses dernières moutures, E-DEAL CRM offre la possibilités aux utilisateurs finaux de personnaliser les listes des recherche : ajout de critères, de colonnes de résultats. Il est évident que cela peut jouer fortement sur les performances (on sort du cadre pré-défini plus haut), et il pourra donc s’avérer nécessaire de désactiver cette possibilité (via la gestion des droits sur les listes).

Pièges classiques

Certaines possibilités offertes par les listes de recherche ont une incidence sur les performances dès lors qu’on est amené à travailler dans un contexte de volumes importants de données. Il faut avoir conscience des choses suivantes:

  • l’utilisation de l’attribut substringsearch= »true » dans un critère de recherche va entrainer une clause de type champ like « %xxx », ce qui va empêchera l’utilisation d’index
  • l’utilisation de l’attribut otherSearchFields (la recherche sera faite sur l’ensemble des champs précisés) entrainera requête du type champ1=’val’ or champ2=’val’. Il conviendra de prendre en compte ces autres champs dans la mise en place des index.
  • Les filtres : ils seront rajoutés systématiquement dans la requête. Attention à ne pas oublier de les prendre en compte lors de la création des index.

Pour conclure

Nous avons vu quelques conseils visant à améliorer les performances dans le cadre des listes de recherche. Nous continuerons dans un prochain post, toujours consacré à la question des performances, à lister un ensemble de bonnes pratiques lors de la définitions d’écrans et de traitements.

Partager cet article
Lire également
Leave a comment