Aller au contenu principal
Version: 20 R6 BETA

Optimisation client/serveur

4D optimise automatiquement les requêtes ORDA qui utilisent des entity selections ou chargent des entités dans l'architecture client/serveur. Ces optimisations accélèrent l'exécution de votre application 4D en réduisant drastiquement le volume d'informations transmises sur le réseau. Elles incluent :

  • le contexte d'optimisation
  • le Cache ORDA

Architectures prises en charge​

Les architectures client/serveur de l'ORDA qui prennent en charge l'optimisation sont :

Contexte d'optimisation​

Le contexte d'optimisation est fondé sur ce qui suit :

Note de compatibilité

Les contextes gérés dans les connexions établies via Open datastore peuvent uniquement être utilisés entre des versions principales similaires de 4D. Par exemple, une application distante 4D 20.x ne peut utiliser que les contextes d'un datastore 4D Server 20.x.

Exemple​

Considérons le code suivant :

 $sel:=$ds.Employee.query("firstname = ab@")
 For each($e;$sel)
    $s:=$e.firstname+" "+$e.lastname+" works for "+$e.employer.name // $e.employer renvoie à la table Company 
 End for each

Grâce à l'optimisation, cette requête récupérera uniquement les données des attributs utilisés (firstname, lastname, employer, employer.name) dans $sel à partir de la deuxième itération de la boucle.

Réutilisation de la propriété context​

Vous pouvez augmenter les avantages de l'optimisation en utilisant la propriété context. Cette propriété référence un contexte d'optimisation "appris" pour une entity selection. Elle peut être passée comme paramètre aux fonctions ORDA qui retournent de nouvelles entity selections, afin que les entity selections demandent directement au serveur les attributs utilisés, sans passer par la phase d'apprentissage.

Vous pouvez également créer des contextes en utilisant la fonction .setRemoteContextInfo().

Une même propriété de contexte d'optimisation peut être passée à un nombre illimité d"entity selections de la même dataclass. Toutes les fonctions ORDA qui gèrent les entity selections prennent en charge la propriété context (par exemple dataClass.query() ou dataClass.all()). Il est toutefois important de garder à l'esprit qu'un contexte est automatiquement mis à jour lorsque de nouveaux attributs sont utilisés dans d'autres parties du code. Si le même contexte est réutilisé dans différents codes, il risque d'être surchargé et de perdre en efficacité.

Un mécanisme similaire est implémenté pour les entités qui sont chargées, de sorte que seuls les attributs utilisés sont demandés (voir la fonction dataClass.get()).

Exemple avec dataClass.query():

 var $sel1; $sel2; $sel3; $sel4; $querysettings; $querysettings2 : Object
 var $data : Collection
 $querysettings:=New object("context";"shortList")
 $querysettings2:=New object("context";"longList")
 
 $sel1:=ds.Employee.query("lastname = S@";$querysettings)
 $data:=extractData($sel1) // dans la méthode extractData un contexte d'optimisation    
 // est généré et associé au contexte "shortList"
 
 $sel2:=ds.Employee.query("lastname = Sm@";$querysettings)
 $data:=extractData($sel2) // dans la méthode extractData le contexte d'optimisation   
 // associé au contexte "shortList" est appliqué
 
 $sel3:=ds.Employee.query("lastname = Smith";$querysettings2)
 $data:=extractDetailedData($sel3) // dans la méthode extractDetailedData un contexte d'optimisation  
 // est généré et associé au contexte "longList"
 
 $sel4:=ds.Employee.query("lastname = Brown";$querysettings2)
 $data:=extractDetailedData($sel4) // dans extractDetailedData  le contexte d'optimisation  
 // associé au contexte "longList" est appliqué

List box de type entity selection​

L'optimisation d'entity selection s'applique automatiquement aux listbox basées sur une entity selection dans les applications desktop client/serveur, au moment d'afficher et de dérouler le contenu d'une listbox : seuls les attributs affichés dans la listbox sont demandés au serveur.

Un contexte spécifique nommé "page mode" est également fourni lorsque l'entité courante de la sélection est chargée à l'aide de l'expression de la propriété Elément courant de la list box (voir List box de type collection ou entity selection). Cette fonctionnalité vous permet de ne pas surcharger le contexte initial de la listbox dans ce cas précis, notamment si la "page" requiert des attributs supplémentaires. A noter que seule l'utilisation de l'expression Elément courant permettra de créer/utiliser le contexte de la page (l'accès via entitySelection[index] modifiera le contexte de l'entity selection).

Les requêtes ultérieures adressées au serveur par les fonctions de navigation parmi les entités prendront également en charge cette optimisation. Les fonctions suivantes associent automatiquement le contexte d'optimisation de l'entité source à l'entité retournée :

Par exemple, le code suivant charge l'entité sélectionnée et permet de naviguer dans l'entity selection. Les entités sont chargées dans un contexte séparé et le contexte initial de la listbox demeure inchangé :

 $myEntity:=Form.currentElement //expression de l'élément courant 
  //... faire quelque chose
 $myEntity:=$myEntity.next() //charge l'entité suivante à l'aide du même contexte

Préconfiguration des contextes​

Un contexte d'optimisation doit être défini pour chaque fonctionnalité ou algorithme de votre application, afin d'obtenir les meilleures performances. Par exemple, un contexte peut être utilisé pour les requêtes sur les clients, un autre contexte pour les requêtes sur les produits, etc.

Si vous souhaitez livrer des applications finales avec le plus haut niveau d'optimisation, vous pouvez préconfigurer vos contextes et ainsi économiser des phases d'apprentissage en suivant ces étapes :

  1. Concevez vos algorithmes.
  2. Exécutez votre application et laissez le mécanisme d'apprentissage automatique remplir les contextes d'optimisation.
  3. Appelez la fonction dataStore.getRemoteContextInfo() ou dataStore.getAllRemoteContexts() pour collecter les contextes. Vous pouvez utiliser les fonctions entitySelection.getRemoteContextAttributes() et entity.getRemoteContextAttributes() pour analyser comment vos algorithmes utilisent les attributs.
  4. Dans la dernière étape, appelez la fonction dataStore.setRemoteContextInfo() pour construire des contextes au démarrage de l'application et utilisez-les dans vos algorithmes.

Cache ORDA​

Pour des raisons d'optimisation, les données demandées au serveur via ORDA sont chargées dans le cache distant ORDA (qui est différent du cache 4D). Le cache ORDA est organisé par dataclass et expire au bout de 30 secondes.

Les données contenues dans le cache sont considérées comme expirées lorsque le délai d'attente est atteint. Tout accès à des données périmées provoquera l'envoi d'une requête au serveur. Les données périmées restent dans le cache jusqu'à ce que l'on ait besoin d'espace.

Par défaut, le cache ORDA est géré de manière transparente par 4D. Cependant, vous pouvez contrôler son contenu en utilisant les fonctions ORDA suivantes :