rmx
Returning Observer

Delta Generation - generate nach dataset Änderungen?

Hallo, 

wir planen gerade die Delta Generierung nach den Tutorials in diesem Forum einzusetzen. 

Wir haben jetzt schon einige Tests durchgeführt. Was müssten wir tun, damit wir auch die Seiten generieren, bei denen sich ein Datensatz aus den Datenquellen geändert hat, der NICHT per Contenprojektion eingebunden ist, sonder per Query?

Gibt es dazu eine Lösung?

Für sachdienliche Hinweise sind wir sehr dankbar,

Roman für das Team 

0 Kudos
5 Replies
mbergmann
Crownpeak employee

Hallo Roman,

geht es hier um ein ContentSelect? 

Michael 

0 Kudos
rmx
Returning Observer

Hi Michael,

so könnte man es professionell ausdrücken, ja 😎!

Ich freue mich schon wie Bolle auf Deine Antwort... 

Gruß Roman

0 Kudos
mbergmann
Crownpeak employee

Hi Roman,

ok, wollte nur sichergehen dass es nicht um ein Skript o.ä. geht.

Bzgl. ContentSelect gibt es da leider keinen Automatismus - was auch irgendwie logisch ist, da das ja erst zur "Aufrufzeit" ausgewertet wird. Und dabei geht es ja noch nichtmal nur um geänderte Informationen (wie eine geänderter Text) sondern auch darum, ob durch eine Änderung der Datensatz überhaupt erst vom ContentSelect (neu) erfasst wird oder insbesondere andersherum nicht mehr ausgegeben wird (dann müsste man ja sogar sowas wie eine Historie haben)... 

Ein paar Ideen für einen Lösungsansatz:

Die "Deltagenerierung" ist ja technisch gesehen eigentlich nur ein Mechanismus, der anhand von geänderten Objekten im Projekt über den Referenzgraphs versucht, "schlau" herauszufinden, welche Seitenreferenzen durch die Änderungen (potenziell) "betroffen" sind. Diese werden dann als Startknoten in einen (ansonsten ganz "normalen") Teilgenerierungstask geworfen.

Wenn hier die Automatismen der "Deltagenerierung" nicht reichen, kann man selbst noch eigene Knoten hinzufügen. Wie man das genau macht, hängt stark vom Einzelfall ab.

Ich bin jetzt nicht 100% sicher, aber ich meine dass der Deltagenerierungs-Mechanismus keine Knoten aus dem Task entfernt sondern nur "seine" hinzufügt. Eine einfache Variante wäre also, entsprechende Seitenreferenzen manuell in den Task zu legen. Müsste man natürlich immer nachziehen. 

Man kann das natürlich auch skriptgesteuert (bzw. besser über ein Executable das man als Skript-Task einhängt) tun, z.B. indem man über eingehende Referenzen auf das Template mit dem ContentSelect "rückwärts" bis zu den Seitenreferenzen läuft. Auch da gäbe es wieder die "einfache" Variante, das einfach immer zu tun oder abhängig davon, ob sich überhaupt ein Datensatz geändert hat.

Noch allgemeiner (aber wohl auch aufwändiger) wäre es, z.B. über den QueryAgent alle ContentSelects in Templates zu suchen und dann wie oben über den Referenzgraph zu gehen. 

Eine Zwischenlösung könnte eine pflegbare Liste von Seitenreferenzen (oder auch Templates) z.B. in den Projekteinstellungen sein, die dann von diesem Skript genutzt wird.

Wenn man den Ansatz über den QueryAgent bzw. letztlich die Templates geht, muss man die entsprechende Logik zum "rückwärts über den Referenzgraph zu den Seitenreferenzen zu laufen" selbst bauen.

Viele Grüße

Michael

0 Kudos
rmx
Returning Observer

Hallo Michael,

danke für Deine ausführlichen Zeilen.

Auf den ersten Blick würde ich sagen in unserem Kontext ist die Delta Generierung leider nicht brauchbar. Wir müssten tatsächlich über den QueryAgent gehen. Ich sehe da gerade keine Ressource, die dazu in endlicher Zeit in der Lage wäre, das zu erledigen.

Somit ein großes Danke an Dich mit einem traurigen Schade, 

Roman

0 Kudos

Hallo Roman,

Ich will hier nicht mit "Kanonen auf Spatzen" schießen, aber habt ihr mal über den Einsatz von CaaS nachgedacht? 
Delta-Generierung wird ja häufig eingesetzt, wenn ein Projekt über die Zeit so groß geworden ist, das eine Vollgenerierung zu lange dauert oder zu viel Last erzeugt. Ein Problem, was durch CaaS und den dort verwendeten Eventing-basierten Ansatz nicht existiert.

Peter
0 Kudos