Paramétrage solution GRC
Publié le : 23/03/2016 dans IT Par : Jean-Sébastien Alet Tags :

Intégration et performance: quelques conseils pratiques

Ce dernier billet vient clore la série de posts techniques consacrés aux performances (en particulier, dans tout ce qui se rapporte à l’accès aux données), initiée ici et poursuivie .

Nous allons rappeler quelques points, indiquer quelques bonnes pratiques à garder à l’esprit lors de projets d’intégration d’E-DEAL CRM, et en profiter pour mettre en lumière quelques outils parfois méconnus.

De la même manière que les précédents, ces billets sont à forte coloration technique et s’adressent donc à un public, sinon averti, du moins concerné par ces aspects d’un projet d’intégration d’E-DEAL CRM.

Que se passe-t-il lors du chargement d’un écran ?

Lorsque le navigateur charge un écran « classique » (une fiche en lecture d’un objet par exemple ), un certain nombre de requêtes en base de données vont être lancées:

  • 1 + n requêtes pour le chargement de l’objet (n étant le nombre de champs multivalués de l’objet)
  • 1 requête pour chaque champ fob affiché (évaluation du toString spécifié dans le dictionnaire de données)
  • x requêtes pour l’affichage du 1er onglet suivant sa nature (le wall par exemple, nécessite 2 requêtes pour s’afficher)

Ces requêtes sont trés rapides prises unitairement (elles se basent sur la clef primaire des enregistrements), mais en évaluer le nombre permet d’orienter les choix d’implémentation : retrouver des informations complémentaires de manière synchrone ou asynchrone (le chargement du wall est par exemple asynchrone)…

Pendant les traitements…

Lors de la mise au point de tout traitement, une règle d’or est à respecter. Elle est toute simple et certainement évidente pour beaucoup d’entre vous, mais je vais la rappeler tout de même :

Ne pas charger d’objet « complet » si cela est inutile.

Ce que j’entends par le chargement d’objet « complet » consiste en l’instanciation d’un bean par son ID, et ce que j’entends par inutile est le fait de n’utiliser qu’un nombre réduit d’informations provenant de cet objet. Quelques pistes pour cela…

Récupérer une seule information d’un objet

Afin de récupérer une information particulière d’un objet, privilégier la méthode lookup au chargement d’un bean : cela nécessitera une seule requête (de volume réduit) plutôt que (1+n) requêtes.

OpportunityBean.lookup(session, "OppStoID", id_opportunity);

Plutôt que

OpportunityBean opp=new OpportunityBean(session,id_opportunity);
opp.getStoID();

Récupérer des informations sur un ensemble d’objets

Pour la même raison, et si nous travaillons sur un ensemble d’objets, il est conseillé d’utiliser la méthode listSummary, plutôt que de charger et d’itérer sur tous les objets concernés : cela réduira à une seule le nombre de requêtes nécessaire, à comparer aux (1 + x(1+n)) requêtes du second cas.

Traitement d’ensemble

Ne pas oublier, dans certains cas précis, qu’il est parfois préférable de directement passer par des requêtes SQL plutôt que par les bean. Par exemple un « Delete from table where… »  sera bien sûr plus performant (et rapide à écrire) que la construction d’une liste de bean effectuée dans le seul but d’appeler la méthode delete sur chacun d’eux.

Bonus: quelques fonctions méconnues

et qui ne gagnent pas à le rester

Retrouver un objet ?

Pour retrouver facilement un objet par un autre champ (unique) que son identifiant technique, ne pas oublier la méthode lookupIDFromField

String dmdID=BasicHelper.lookupIDFromField(session,context,"DmdToken","AXC2015-075")

Effectuer une mise à jour en base ?

Une mise à jour à faire rapidement, sans instancier le bean ? runSQLQueryUpdate vous facilitera la vie

EmailsentHelper.runSQLQueryUpdate(context, "Update EmailSent set EmsStatus=1 Where ....")

Attention: Ne pas oublier que les droits ne seront alors pas pris en compte, et qu’aucun traitement ne sera lancé : pas de pre/postSave, mais aussi aucune historisation ou déclenchement de SLA. Cela est donc à réserver à certains types de traitements.

Retrouver un nombre d’enregistrements présents en base ?

La méthode runSQLCount peut vous aider à privilégier à l’utilisation d’un listSummary, suivie de la vérification de la taille du vecteur résultant

nbModel = BasicHelper.runSQLCount(context, "SELECT COUNT(*) AS counter FROM ReturnedMailModel WHERE RmmActive = 1", "counter"); 

Rendre un traitement plus robuste ?

Vous devez mettre à jour un objet, avec des informations ne provenant pas de l’interface (mais d’un web service, d’un e-mail, une duplication d’objet) ? La longueur des chaines de caractères est alors à prendre en compte, afin de ne pas provoquer d’erreur lors de l’enregistrement en base lorsqu’une d’elle est trop grande.

La méthode setPropertyWithSizeConstraint tient compte de cette contrainte, en comparant la taille du champ déclarée dans le dictionnaire à celle de la chaine à stocker, et au besoin va la raccourcir à la bonne taille.

opportunityHelper.setPropertyWithSizeConstraint("OppTitle","un titre vraiment très long.................")

Cette méthode, pour l’instant, ne tient pas compte du cas particulier d’Oracle, pour qui un caractère accentué (unicode en fait) compte double…

Pour conclure

Nous avons vu quelques conseils de bon sens afin d’optimiser les traitements classiquement mis en œuvre dans les projets d’intégration de E-DEAL CRM. Si vous souhaitez voir aborder d’autres thématiques dans cette rubrique à caractère technique, n’hésitez pas à laisser un commentaire…

Partager cet article
Lire également
Leave a comment