Le partage mène à la performance

Suite à ce billet de blog sur le nouveau concept de sélections d’entités partageables et aux discussions qui ont suivi sur le forum, nous allons maintenant prendre le temps d’expliquer comment ORDA s’inscrit dans le futur.

Il y a plusieurs mois, nous avons fièrement présenté ORDA et tous ses nouveaux concepts.

Vous avez appris que dans ORDA, TOUT est un objet:

• la base de données elle-même est un objet (l’objet datastore)
• chaque table est un objet dataclass
• chaque enregistrement peut être un objet entité
• une sélection courante peut être un objet de sélection d’entité

Au-delà, l’époque où vous étiez bloqué avec une seule sélection courante par table est révolue. Vous pouvez gérer autant de sélections d’entités que vous le souhaitez. Et puisque tout est un objet, vous êtes prêt pour un code plus facile à manipuler, un codage générique et une sérialisation pour communiquer avec d’autres logiciels.

Saviez-vous que tout cela est prêt à l’emploi avec 4D? Il n’y a pas de pile technologique à gérer et pas de maux de tête liés à un cadre complexe.

4D v17 comprend également une autre option très importante : le partage des données entre les processus avec des objets et des collections partagés. Il est désormais très facile de partager diverses données entre des processus préemptifs.

4D vous conduit avec confiance vers un monde de multithreading, en tirant un grand avantage des capacités des processeurs pour améliorer les performances de vos applications.

Les meilleures performances et le codage le plus facile reposent sur cette équation : objets + partage.

Et c’est alors qu’apparaît le concept de sélections d’entités partageables

étudions un premier cas d’utilisation

Vous avez peut-être déjà découvert tous les avantages du WORKER pour exécuter des tâches en mode préemptif. Jusqu’à présent, seuls les objets partagés et les collections partagées pouvaient lui être transmis en tant que référence.

Imaginez les avantages que vous pourriez tirer en passant les sélections d’entités en tant que référence, également … comme tout autre élément partagé.

Voici un cas d’utilisation approprié :

1- Identifier les factures payées et les factures impayées.

2- Envoyer des e-mails d’accusé de réception aux clients pour leurs factures payées et des e-mails de rappel pour leurs factures impayées. Parce que cette tâche peut prendre beaucoup de temps, nous voulons la déléguer à un TRAVAILLEUR en mode asynchrone.

Le code pourrait ressembler à ceci :

var $paid; $unpaid: cs.InvoicesSelection
//Get entity selections for paid and unpaid invoices
$paid :=ds.Invoices.query("status=:1" ; "Paid")
$unpaid :=ds.Invoices.query("status=:1" ; "Unpaid")

//Pass entity selections as references to the WORKER
CALL WORKER ("mailing" ; "sendMails" ; $paid; $unpaid)

La méthode sendMails accède aux sélections d’entités transmises en tant que références. Le code complet a été fourni dans cet article de blog.

Avez-vous remarqué quelque chose ? Les sélections d’entités sont transmises « telles quelles » au travailleur. Elles sont prêtes à être partagées.

L’étape suivante : de nouvelles sessions Web

L’étape suivante consiste à améliorer vos applications Web grâce à une gestion puissante des sessions, conçue pour être évolutive.

Dans une prochaine version, les sessions Web 4D seront capables de gérer plusieurs processus(c’est-à-dire des demandes) provenant du même agent utilisateur, en même temps. Non seulement cela améliorera les performances, mais cela offrira le grand avantage de partager des informations entre les processus.

Et ce n’est pas tout ! Vous pourrez gérer une authentification personnalisée en assignant des informations à votre session web.

discutons d’un cas d’utilisation

Imaginez une entreprise mondiale(Acme Corp.) qui vend des ordinateurs dans le monde entier à divers clients (entreprises, personnes, écoles, etc.) par le biais d’une application CRM.

Chaque vendeur gère son propre portefeuille de clients. Ils sont connectés à l’application toute la journée pour conclure et enregistrer des affaires dans leur portefeuille de clients.

Nous pouvons supposer que la base de données contient au moins 2 classes de données liées : Customers et SalesPersons ( un vendeur a plusieurs clients).

Dans l’image ci-dessous, nous pouvons voir que :

• Les 10 premiers clientsd’Acme Corp. sont stockés dans Stockage, il est donc partagé entre tous les processus s’exécutant dans l’application.
• Chaque vendeur a sa propre session avec ses 10 meilleurs clients stockés dedans.
• Les vendeurs peuvent naviguer sur chaque page de l’application et voir s’afficher leurs 10 premiers clients, ainsi que ceux d’Acme Corp.

Ces « 10 premiers » sont des sélections d’entités Client partagées soit dans le stockage, soit dans la session de l’utilisateur.

Il devient alors très facile de développer des moyens de :

• vérifier si un vendeur est performant( par exemple, y a-t-il une intersection entre ses 10 meilleurs clients et les 10 meilleurs clients d’Acme Corp.)
• rafraîchir le top 10 des clients du vendeur
• etc.

plus concrètement dans le code 4D

Les 10 premiers clientsd’Acme Corp. sont des sélections d’entités Clients mises en mémoire, au moins au démarrage de la base de données :

Use (Storage)
Storage .acmeCorpTop10:=ds.Customers.all().orderBy("totalPurchase desc").slice(0 ; 10)
End use


La session web n’est rien d’autre que … un objet: l’objet Session. Cet objet contient un objet partagé ( attributstorage ) afin que toutes les requêtes traitées par la session puissent partager des données.

Lorsque le vendeur s’authentifie, il est très facile de stocker ses 10 premiers clients avec un code du type :

// $salesID is the salesperson's ID
// Get the salesperson's top 10 customers
$top10:=ds.Customers.query("salesPerson.salesID = :1" ; $salesID).orderBy("totalPurchase desc").slice(0 ; 10)
// Put $top10 in the session
Use (Session.storage)
Session .storage.myTop10:=$userTop10
End use


Remarque: L’exemple de code ci-dessus est un aperçu d’une future version de 4D.

Ensuite, tous les processus(c’est-à-dire les demandes) provenant de l’agent utilisateur peuvent accéder à ces 10 premiers clients.

Notez que vous placez les sélections d’entités « telles quelles« dans Storage et dans la session. Il n’est pas nécessaire de les copier comme partageables !

Cela est possible car les sélections d’entités sont partageables par défaut.

en conclusion

Nous avons choisi de donner un avantage à tous les cas d’utilisation futurs liés à l’évolutivité et à la performance qui devraient être les principaux problèmes de vos applications futures. Un utilisateur final heureux est celui qui obtient le bon résultat dans le temps le plus court.

Sachez que le but d’une sélection d’entités partageables est d’être manipulée comme une référence. C’est plus léger en mémoire.

De plus, certaines optimisations transparentes sont gérées par 4D pour vous lorsque vous utilisez des sélections d’entités partageables : lorsque vous copiez des sélections d’entités, si vous demandez un résultat partageable, le cas échéant, 4D ne fait pas de copie des sélections d’entités mais renvoie la même référence.

Grâce à tout cela, vous évitez de copier vos sélections d’entités comme partagées chaque fois que vous voulez les partager. Nous pensons que ces temps seront trop abondants car nous allons de plus en plus vers du code fonctionnant en mode préemptif grâce aux progrès continus des processeurs multi-cœurs.