Teilen führt zu Leistung

Nach diesem Blogbeitrag über das neue Konzept der gemeinsam nutzbaren Entitätsauswahlen und den anschließenden Diskussionen im Forum nehmen wir uns nun die Zeit, um zu erklären, wie ORDA in die Zukunft passt.

Vor einigen Monaten haben wir stolz ORDA und alle seine neuen Konzepte vorgestellt.

Sie haben gelernt, dass in ORDA ALLES ein Objekt ist:

• die Datenbank selbst ist ein Objekt (das Datastore-Objekt)
• jede Tabelle ist ein Datenklassenobjekt
• jeder Datensatz kann ein Entity-Objekt sein
• eine aktuelle Auswahl kann ein Entitätsauswahlobjekt sein

Darüber hinaus sind die Zeiten vorbei, in denen man mit einer einzigen aktuellen Auswahl pro Tabelle auskommen musste. Sie können so viele Entitätsselektionen verwalten, wie Sie wollen. Und da alles ein Objekt ist, sind Sie bereit für leichter zu handhabenden Code, generische Kodierung und Serialisierung zur Kommunikation mit anderer Software.

Wussten Sie schon, dass 4D all diese Funktionen sofort zur Verfügung stellt? Sie müssen sich nicht um einen Technologie-Stack kümmern und haben keine Probleme mit einem komplexen Framework.

4D v17 enthält außerdem eine weitere wichtige Option: die gemeinsame Nutzung von Daten zwischen Prozessen mit gemeinsamen Objekten und Sammlungen. Es ist jetzt sehr einfach, verschiedene Daten zwischen präemptiven Prozessen zu teilen.

4D führt Sie selbstbewusst in eine Welt des Multi-Threading und nutzt die Möglichkeiten des Prozessors, um die Leistung Ihrer Anwendungen zu verbessern.

Die beste Leistung und die einfachste Kodierung basieren auf dieser Gleichung: Objekte + gemeinsame Nutzung.

Und dann kommt das Konzept der gemeinsam nutzbaren Objektauswahlen

Lassen Sie uns einen ersten Anwendungsfall untersuchen

Vielleicht haben Sie bereits alle Vorteile des WORKER entdeckt, um Aufgaben im präemptiven Modus auszuführen. Bislang konnten ihm nur gemeinsam genutzte Objekte und Sammlungen als Referenz übergeben werden.

Stellen Sie sich die Vorteile vor, die Sie erzielen könnten, wenn Sie auch Entitätsselektionen als Referenz übergeben würden … genau wie jedes andere gemeinsam genutzte Objekt.

Hier ist ein geeigneter Anwendungsfall:

1- Bezahlte Rechnungen und unbezahlte Rechnungen identifizieren

2- Senden Sie Bestätigungs-E-Mails an Kunden für ihre bezahlten Rechnungen und Erinnerungs-E-Mails für ihre unbezahlten Rechnungen. Da diese Aufgabe potenziell zeitaufwändig ist, wollen wir sie an einen WORKER im asynchronen Modus delegieren.

Der Code könnte wie folgt aussehen:

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)

Die Methode sendMails greift auf die übergebenen Entitätsselektionen als Referenzen zu. Der vollständige Code wurde in diesem Blogbeitrag bereitgestellt.

Ist Ihnen etwas aufgefallen? Die Entitätsauswahlen werden „so wie sie sind“ an den Worker übergeben. Sie sind bereit für die gemeinsame Nutzung.

Der nächste Schritt: neue Websitzungen

Der nächste Schritt ist die Erweiterung Ihrer Webanwendungen um ein leistungsfähiges und skalierbares Session Management.

In einer zukünftigen Version werden 4D Web Sessions in der Lage sein, mehrere Prozesse( d.h. Anfragen) desselben User Agents gleichzeitig zu verarbeiten. Dies wird nicht nur die Leistung verbessern, sondern auch den großen Vorteil bieten, Informationen zwischen den Prozessen auszutauschen.

Und das ist noch nicht alles! Sie werden in der Lage sein, benutzerdefinierte Authentifizierung zu verwalten, indem Sie Ihrer Websitzung Informationen zuweisen.

Lassen Sie uns einen Anwendungsfall diskutieren

Stellen Sie sich ein globales Unternehmen(Acme Corp.) vor, das über eine CRM-Anwendung weltweit Computer an verschiedene Kunden (Unternehmen, Personen, Schulen usw.) verkauft.

Jeder Vertriebsmitarbeiter verwaltet sein eigenes Kundenportfolio. Sie sind den ganzen Tag über mit der Anwendung verbunden, um Geschäfte in ihrem Kundenportfolio abzuschließen und zu registrieren.

Wir können davon ausgehen, dass die Datenbank mindestens 2 verknüpfte Datenklassen enthält: Customers und SalesPersons (ein Vertriebsmitarbeiter hat mehrere Kunden).

In der folgenden Abbildung ist das zu sehen:

• Die 10 wichtigsten Kundender Acme Corp. sind in Storage gespeichert und werden somit von allen Prozessen der Anwendung gemeinsam genutzt.
• Jeder Vertriebsmitarbeiter hat seine eigene Sitzung, in der seine 10 wichtigsten Kunden gespeichert sind.
• Die Vertriebsmitarbeiter können durch jede Seite der Anwendung navigieren und ihre Top-10-Kunden sowie die Top-10-Kunden der Acme Corp. anzeigen lassen.

Bei diesen „Top 10“ handelt es sich um die Auswahl von Kundenentitäten , die entweder im Speicher oder in der Sitzung des Benutzers freigegeben sind.

Es wird dann sehr einfach, Wege zu entwickeln, um:

• zu testen, ob ein Verkäufer ein guter Performer ist(d. h. gibt es eine Überschneidung zwischen seinen Top-10-Kunden und den Top-10-Kunden von Acme Corp. )
• Auffrischung der Top-10-Kunden des Verkäufers
• usw.

Konkreter im 4D-Code

Die 10 wichtigsten Kundender Acme Corp. sind Kunden-Entitätsselektionen, die in Storage angelegt werden, zumindest beim Start der Datenbank:

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


Die Web-Sitzung ist nichts anderes als … ein Objekt: das Session-Objekt. Dieses Objekt enthält ein gemeinsames Objekt (Attributstorage ), so dass alle von der Sitzung bearbeiteten Anfragen Daten gemeinsam nutzen können.

Wenn der Verkäufer sich authentifiziert, ist es sehr einfach, seine 10 wichtigsten Kunden mit einem Code wie diesem zu speichern:

// $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


Hinweis: Das obige Codebeispiel ist eine Vorschau auf eine zukünftige Version von 4D.

Dann können alle Prozesse(d. h. Anfragen), die vom User Agent kommen, auf diese Top-10-Kunden zugreifen.

Beachten Sie, dass Sie die Entitätsauswahlen „so wie sie sind“ in Storage und in der Sitzung ablegen. Es besteht keine Notwendigkeit, sie als „shareable“ zu kopieren!

Dies ist möglich, weil Entitätsselektionen standardmäßig freigegeben werden können.

Zusammenfassung

Wir haben uns dafür entschieden, allen zukünftigen Anwendungsfällen, die mit Skalierbarkeit und Leistung zu tun haben, einen Vorteil zu verschaffen, da dies die Hauptprobleme Ihrer zukünftigen Anwendungen sein sollten. Ein zufriedener Endbenutzer ist derjenige, der das richtige Ergebnis in kürzester Zeit erhält.

Seien Sie sich bewusst, dass der Zweck einer Shareable Entity Selection darin besteht, als Referenz gehandhabt zu werden. Sie ist leichter im Speicher.

Darüber hinaus werden einige transparente Optimierungen von 4D für Sie durchgeführt, wenn Sie gemeinsam nutzbare Objektauswahlen verwenden: Wenn Sie beim Kopieren von Objektauswahlen nach einem gemeinsam nutzbaren Ergebnis fragen, erstellt 4D keine Kopie der Objektauswahlen, sondern gibt dieselbe Referenz zurück.

Dadurch vermeiden Sie, dass Sie Ihre Entitätsauswahlen jedes Mal als gemeinsam genutzt kopieren, wenn Sie sie gemeinsam nutzen wollen. Wir denken, dass diese Zeiten zu häufig vorkommen werden, da wir dank der kontinuierlichen Entwicklung von Mehrkernprozessoren immer mehr zu Code übergehen, der im präemptiven Modus läuft.