Dopo il post sul blog dedicato al nuovo concetto di selezione delle entità condivisibili e le successive discussioni sul forum, ci soffermiamo a spiegare come ORDA si inserisce nel futuro.
Alcuni mesi fa abbiamo presentato con orgoglio ORDA e tutti i suoi nuovi concetti.
Avete imparato che in ORDA TUTTO è un oggetto:
- il database stesso è un oggetto (l’oggetto datastore)
- ogni tabella è un oggetto classe di dati
- ogni record può essere un oggetto entità
- una selezione corrente può essere un oggetto di selezione di entità
Oltre a questo, i giorni in cui si era bloccati con una sola selezione corrente per tabella sono finiti. Si possono gestire tutte le selezioni di entità che si vogliono. E poiché tutto è un oggetto, si è pronti per un codice più facile da gestire, per una codifica generica e per la serializzazione per comunicare con altri software.
Sapevate che tutto questo è già pronto con 4D? Non c’è uno stack tecnologico da gestire e non ci sono grattacapi con un framework complesso.
4D v17 ha incluso anche un’altra opzione molto importante: la condivisione dei dati tra i processi con oggetti e collezioni condivise. È ora molto facile condividere vari dati tra processi preemptive.
4D vi conduce con fiducia verso un mondo di multi-threading, sfruttando al massimo le capacità dei processori per migliorare le prestazioni delle vostre applicazioni.
Le prestazioni migliori e la codifica più semplice si basano su questa equazione: oggetti + condivisione.
E poi arriva il concetto di selezioni di entità condivisibili
studiamo un primo caso d’uso
Forse avete già scoperto tutti i vantaggi di WORKER nell’esecuzione di task in modalità preemptive. Finora gli si potevano passare come riferimento solo oggetti e collezioni condivise.
Immaginate i vantaggi che potreste ottenere passando anche le selezioni di entità come riferimento… proprio come qualsiasi oggetto condiviso.
Ecco un caso d’uso appropriato:
1- Identificare le fatture pagate e le fatture non pagate
2- Inviare ai clienti e-mail di conferma per le fatture pagate e e-mail di sollecito per quelle non pagate. Poiché questo compito è potenzialmente dispendioso in termini di tempo, vogliamo delegarlo a un OPERATORE in modalità asincrona.
Il codice potrebbe assomigliare a questo:
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)
Il metodo sendMails accede alle selezioni di entità passate come riferimenti. Il codice completo è stato fornito in questo post.
Avete notato qualcosa? Le selezioni di entità sono passate “così come sono” al worker. Sono pronte per essere condivise.
Il prossimo passo: nuove sessioni web
Il passo successivo è quello di potenziare le applicazioni web con una potente gestione delle sessioni progettata per la scalabilità.
In una versione futura, le sessioni web di 4D saranno in grado di gestire contemporaneamente più processi( cioè richieste) dallo stesso agente utente. Questo non solo migliorerà le prestazioni, ma offrirà il grande vantaggio di condividere le informazioni tra i processi.
E non è tutto! Sarete in grado di gestire l’autenticazione personalizzata assegnando informazioni alla vostra sessione web.
discutiamo un caso d’uso
Immaginate un’azienda globale(Acme Corp.) che vende computer in tutto il mondo a vari clienti (aziende, persone, scuole, ecc.) attraverso un’applicazione CRM.
Ogni venditore gestisce il proprio portafoglio clienti. Sono collegati all’applicazione tutto il giorno per concludere e registrare le transazioni nel loro portafoglio clienti.
Possiamo supporre che il database contenga almeno 2 classi di dati collegate: Customers e SalesPersons (un venditore ha diversi clienti).
Nell’immagine sottostante, possiamo vedere che:
- I 10 principali clientidi Acme Corp. sono memorizzati in Storage, quindi condivisi tra tutti i processi in esecuzione nell’applicazione.
- Ogni venditore ha una propria sessione in cui sono memorizzati i suoi 10 clienti più importanti
- I venditori possono navigare in ogni pagina dell’applicazione e vedere visualizzati i loro 10 migliori clienti e i 10 migliori clienti di Acme Corp.
Questi “top 10” sono selezioni di entità Cliente condivise nello storage o nella sessione dell’utente.
Diventa quindi molto facile sviluppare modi per:
- verificare se un venditore ha un buon rendimento( ad esempio, c’è un’intersezione tra i suoi 10 principali clienti e i 10 principali clienti di Acme Corp.)
- aggiornare i 10 principali clienti del venditore
- ecc.
più concretamente nel codice 4D
I primi 10 clientidi Acme Corp. sono selezioni di entità Clienti messe in Memoria, almeno all’avvio del database:
Use (Storage)
Storage .acmeCorpTop10:=ds.Customers.all().orderBy("totalPurchase desc").slice(0; 10)
End use
La sessione Web non è altro che … un oggetto: l’oggetto Session. Questo oggetto contiene un oggetto condiviso (attributostorage ) in modo che tutte le richieste gestite dalla sessione possano condividere i dati.
Quando l’addetto alle vendite si autentica, è molto semplice memorizzare i suoi 10 migliori clienti con un codice del tipo:
// $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
Nota: l’esempio di codice sopra riportato è un’anteprima di una versione futura di 4D.
Quindi tutti i processi( cioè le richieste) provenienti dall’interprete possono accedere a questi 10 clienti principali.
Si noti che le selezioni delle entità sono state inserite “così come sono” in Storage e nella sessione. Non è necessario copiarle come condivisibili!
Questo è possibile perché le selezioni di entità sono condivisibili per impostazione predefinita.
in conclusione
Abbiamo scelto di dare un vantaggio a tutti i casi d’uso futuri legati alla scalabilità e alle prestazioni, che dovrebbero essere i problemi principali delle vostre applicazioni future. Un utente finale felice è quello che ottiene il risultato giusto nel minor tempo possibile.
Si tenga presente che lo scopo di una selezione di entità condivisibile è quello di essere gestita come un riferimento. È più leggera in memoria.
Inoltre, alcune ottimizzazioni trasparenti sono gestite da 4D per voi quando utilizzate selezioni di entità condivisibili: durante la copia delle selezioni di entità, se chiedete un risultato condivisibile, quando è il caso, 4D non fa una copia delle selezioni di entità ma restituisce lo stesso riferimento.
Grazie a tutto ciò, si evita di copiare le selezioni di entità come condivise ogni volta che si desidera condividerle. Pensiamo che questi tempi saranno troppo abbondanti man mano che andremo sempre più verso il codice eseguito in modalità preemptive grazie ai continui progressi dei processori a più core.