Sdílení vede k výkonu

Automaticky přeloženo z Deepl

V návaznosti na tento blogový příspěvek o novém konceptu výběru sdílených entit a následné diskuse na fóru si nyní dovolíme vysvětlit, jak ORDA zapadá do budoucnosti.

Před několika měsíci jsme hrdě představili systém ORDA a všechny jeho nové koncepty.

Dozvěděli jste se, že v systému ORDA je VŠECHNO objektem:

Kromě toho jsou pryč doby, kdy jste byli odkázáni na jeden aktuální výběr pro každou tabulku. Můžete spravovat libovolný počet výběrů entit. A protože vše je objekt, jste připraveni na kód, který se snadněji zpracovává, obecné kódování a serializaci pro komunikaci s jiným softwarem.

Věděli jste, že to vše je součástí balení 4D? Nemusíte řešit žádný technologický stack a nemusíte si lámat hlavu se složitým frameworkem.

4D v17 také obsahovalo další velmi důležitou možnost: sdílení dat mezi procesy pomocí sdílených objektů a kolekcí. Nyní je velmi snadné sdílet různá data mezi preemptivními procesy.

4D vás sebevědomě vede do světa vícevláknových aplikací, které hodně využívají možností procesoru ke zvýšení výkonu vašich aplikací.

Nejlepší výkon a nejjednodušší kódování se opírá o tuto rovnici: objekty + sdílení.

A pak přichází na řadu koncept výběrů sdílených entit

prostudujme si první případ použití

Možná jste již objevili všechny výhody WORKERu pro spouštění úloh v preemptivním režimu. Zatím mu bylo možné předávat pouze sdílené objekty a sdílené kolekce jako odkaz.

Představte si, jaké výhody byste mohli získat, kdybyste výběry entit předávali také jako odkaz… stejně jako jakýkoli jiný sdílený objekt.

Zde je vhodný případ použití:

1- Identifikace zaplacených a nezaplacených faktur

2- Odesílání potvrzovacích e-mailů zákazníkům za jejich zaplacené faktury a e-mailů s upomínkami za jejich nezaplacené faktury. Protože je tato úloha potenciálně časově náročná, chceme ji delegovat na PRACOVNÍK v asynchronním režimu.

Kód by mohl vypadat takto:

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)

Metoda sendMails bude přistupovat k předaným výběrům entit jako k referencím. Kompletní kód byl uveden v tomto příspěvku na blogu.

Všimli jste si něčeho? Výběry entit jsou pracovníkovi předávány „tak, jak jsou“. Jsou připraveny ke sdílení.

Další krok: nové webové relace

Dalším krokem je rozšíření webových aplikací o výkonnou správu relací navrženou pro škálovatelnost.

V některé z budoucích verzí budou webové relace 4D schopny zpracovávat několik procesů( tj. požadavků) od stejného uživatelského agenta, a to současně. Nejenže se tím zvýší výkon, ale také to poskytne velkou výhodu sdílení informací mezi procesy.

A to není všechno! Budete moci spravovat vlastní ověřování přiřazením informací k webové relaci.

Probereme si případ použití

Představte si globální společnost(Acme Corp.), která prodává počítače po celém světě různým zákazníkům (firmám, lidem, školám atd.) prostřednictvím aplikace CRM.

Každý prodejce spravuje své vlastní portfolio klientů. Celý den jsou připojeni k aplikaci, aby uzavírali a registrovali obchody ve svém klientském portfoliu.

Můžeme předpokládat, že databáze obsahuje alespoň 2 propojené datové třídy: Customers a SalesPersons (prodejce má několik zákazníků).

Na obrázku níže to vidíme:

  • 10 nejvýznamnějších zákazníkůspolečnosti Acme Corp. je uloženo ve Storage, a je tedy sdíleno mezi všemi procesy běžícími v aplikaci
  • Každý prodejce má svou vlastní relaci, v níž je uloženo jeho 10 nejlepších zákazníků
  • Prodejci mohou procházet každou stránku aplikace a mají zobrazeno svých 10 nejlepších zákazníků a také 10 nejlepších zákazníků společnosti Acme Corp.

Těchto „10 nejlepších“ jsou výběry entit zákazníků sdílené buď v úložišti, nebo v relaci uživatele.

Pak je velmi snadné vyvinout způsoby, jak:

  • testovat, zda je prodejce dobrý (tj. zda se jeho 10 nejlepších zákazníků protíná s 10 nejlepšími zákazníky společnosti Acme Corp.).
  • osvěžit 10 nejlepších zákazníků prodejce
  • atd.

blank

konkrétněji v kódu 4D

10 nejvýznamnějších zákazníkůspolečnosti Acme Corp . jsou výběry entit Customers vložené do Storage, alespoň při spuštění databáze:

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

Webová relace není nic jiného než … objekt: objekt Session. Tento objekt obsahuje sdílený objekt (storage atribut), takže všechny požadavky zpracovávané relací mohou sdílet data.

Když se prodejce ověří, je velmi snadné uložit jeho 10 nejlepších zákazníků pomocí kódu, jako např:

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

Poznámka: Výše uvedený příklad kódu je náhledem budoucí verze 4D.

Pak mohou všechny procesy( tj. požadavky) přicházející z uživatelského agenta přistupovat k těmto 10 nejlepším zákazníkům.

Všimněte si, že výběry entit vkládáte „tak, jak jsou“ do Storage a do relace. Není třeba je kopírovat jako sdílené!

Je to možné, protože výběry entit jsou ve výchozím nastavení sdílené.

na závěr

Rozhodli jsme se poskytnout výhodu všem budoucím případům použití souvisejícím se škálovatelností a výkonem, což by měly být hlavní problémy vašich budoucích aplikací. Spokojený koncový uživatel je ten, který dostane správný výsledek v co nejkratším čase.

Uvědomte si, že účelem výběru sdílených entit je, aby se s nimi pracovalo jako s referencemi. Je lehčí v paměti.

Navíc při použití sdílených výběrů entit za vás 4D provádí některé transparentní optimalizace: při kopírování výběrů entit, pokud požádáte o sdílený výsledek, kdykoli je to použitelné, 4D nevytváří kopii výběru entit, ale vrací stejný odkaz.

Díky tomu všemu se vyhnete kopírování výběrů entit jako sdílených pokaždé, když je chcete sdílet. Myslíme si, že tyto časy budou příliš hojné, protože díky neustálému pokroku vícejádrových procesorů se stále více přechází na kód běžící v preemptivním režimu.

Avatar
• Product Owner • Marie-Sophie Landrieu-Yvert se připojila k programovému týmu 4D jako Product Owner v roce 2017. Jako Product Owner má na starosti psaní uživatelských příběhů a jejich převod do funkčních specifikací. Její úlohou je také zajistit, aby implementovaná funkce odpovídala potřebám zákazníka. Marie-Sophie vystudovala inženýrskou školu ESIGELEC a svou kariéru zahájila jako inženýrka v IBM v roce 1995. Podílela se na různých projektech (projekty údržby nebo výstavby) a pracovala jako vývojářka Cobol. Poté pracovala jako UML designer a Java developer. V poslední době byly jejími hlavními rolí analyzovat a psát funkčních požadavky a koordinovat obchodní a vývojové týmy.