mscholz3
I'm new here

ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo zusammen,

wir nutzen die Deltagenerierung für die Freigabe von Elementen.

Wenn wir eine Entity anpassen, die per ContentSelect genutzt wird, aktualisiert sich die Seite mit dem ContentSelect leider nicht.

Mit der täglich laufenden Vollgenerierung wird die Seite "richtig" generiert. Ist aber in unserem Fall zu spät, da die Änderung relativ zügig live gehen muss.

Welche Möglichkeiten gibt es nun, die Seiten ebenfalls bei der Freigabe zu aktualisieren, die Inhaltliche-Änderungen per ContentSelect bekommen?

Folgende DependencyRules nutzen wir

DependencyRule.PROPAGATE_CONTENT_PRODUCER_MOVE,
DependencyRule.PROPAGATE_GCA_CHANGES,
DependencyRule.PROPAGATE_MEDIA_CHANGES_TO_PAGESTORE,
DependencyRule.PROPAGATE_MEDIA_CHANGES_TO_SITESTORE,
DependencyRule.PROPAGATE_PAGE_CHANGES,
DependencyRule.PROPAGATE_PAGE_CHANGES_CASCADING,
DependencyRule.PROPAGATE_SECTION_CHANGES

Liebe Grüße

Marcel

1 Solution

Accepted Solutions
mbergmann
Crownpeak employee
Crownpeak employee

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo Marcel,

hier gibt es leider keine einfache Möglichkeit, das müsstet ihr „manuell“ machen, d.h. implementieren.

Also alle geänderten Entities (über die Revisionshistorie zu ermitteln) aufsammeln und dann „passend“ die Seiten mit den ContentSelects dazu. Ein ContentSelect erzeugt keine Referenz, d.h. hier müsstet ihr die Logik z.B. in Form einer Art Liste „Entities aus welchem Schema werden in welchem ContentSelect (d.h. letztlich „von welchem Template“) benutzt“.

Das Ganze ist letztlich eine Art Henne/Ei-Problem: Um herauszufinden ob eine Seite von einer Änderung betroffen ist, müsste man sie generieren, da ja erst dann das Contentselect „läuft”. Eine Änderung an einer Entity kann ja auch bewirken, dass sie auf einmal gar nicht mehr oder auch jetzt erst überhaupt vom ContentSelect „erwischt” wird, oder auch nur an einer anderen Position kommt...

Je nach Struktur der ContentSelects bzw. der Ausgabe kann das natürlich beliebig komplex werden, speziell wenn von der eigentlichen Tabelle auf der das Contentselect basiert dann in der Ausgabe noch über Relationen gelaufen wird - auch Änderungen an diesen Entities müssten dann berücksichtigt werden usw...

Wenn ihr letztlich nur eine überschaubare Anzahl Seiten mit Contentselects habt, wäre es ggf. eine Option, die einfach immer alle mitzugenerieren.

Ein ganz anderer Ansatz wär, das alles liveseitig zu lösen indem man die Datensätze z.B. in einen CaaS publiziert und dann liveseitig „abholt“ anstatt sie statisch mit in die Seite(n) zu rendern.

Viele Grüße

Michael

View solution in original post

0 Kudos
5 Replies
mbergmann
Crownpeak employee
Crownpeak employee

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo Marcel,

hier gibt es leider keine einfache Möglichkeit, das müsstet ihr „manuell“ machen, d.h. implementieren.

Also alle geänderten Entities (über die Revisionshistorie zu ermitteln) aufsammeln und dann „passend“ die Seiten mit den ContentSelects dazu. Ein ContentSelect erzeugt keine Referenz, d.h. hier müsstet ihr die Logik z.B. in Form einer Art Liste „Entities aus welchem Schema werden in welchem ContentSelect (d.h. letztlich „von welchem Template“) benutzt“.

Das Ganze ist letztlich eine Art Henne/Ei-Problem: Um herauszufinden ob eine Seite von einer Änderung betroffen ist, müsste man sie generieren, da ja erst dann das Contentselect „läuft”. Eine Änderung an einer Entity kann ja auch bewirken, dass sie auf einmal gar nicht mehr oder auch jetzt erst überhaupt vom ContentSelect „erwischt” wird, oder auch nur an einer anderen Position kommt...

Je nach Struktur der ContentSelects bzw. der Ausgabe kann das natürlich beliebig komplex werden, speziell wenn von der eigentlichen Tabelle auf der das Contentselect basiert dann in der Ausgabe noch über Relationen gelaufen wird - auch Änderungen an diesen Entities müssten dann berücksichtigt werden usw...

Wenn ihr letztlich nur eine überschaubare Anzahl Seiten mit Contentselects habt, wäre es ggf. eine Option, die einfach immer alle mitzugenerieren.

Ein ganz anderer Ansatz wär, das alles liveseitig zu lösen indem man die Datensätze z.B. in einen CaaS publiziert und dann liveseitig „abholt“ anstatt sie statisch mit in die Seite(n) zu rendern.

Viele Grüße

Michael

0 Kudos
mscholz3
I'm new here

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo Michael,

super, vielen Dank! Das habe ich mir schon gedacht Smiley Sad

Wo baut man denn sowas im besten in seinem Freigabe-Prozess ein?

Wir nutzen für die Freigabe die basicworkflows (GitHub - e-Spirit/basicworkflows: Basic Workflows for FirstSpirit ).

Für das Generieren nutzen wir die Deltagenerierung im Auftrag.

Wahrscheinlich macht es am meisten Sinn vor dem generate-Unterauftrag als separaten Unterauftrag die Seiten zu identifizieren und hinzuzufügen?

Liebe Grüße

Marcel

0 Kudos
mscholz3
I'm new here

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo Michael,

noch eine Frage dazu:

Gibt es einen Befehl, womit ich andere Seiten im HTML Kanal freigeben kann?

Somit könnte man die Seiten, die Inhalt aus dem ContentSelect bekommen,  im HTML-Kanal der Datenquelle automatisch freigeben, sobald sich da was ändert.

Oder gibt es eine andere, bessere Lösung, wodurch ich eine Referenz auf die Seiten in der Datenquelle bekomme?

Du hattest was mit einer Liste erwähnt:

Ein ContentSelect erzeugt keine Referenz, d.h. hier müsstet ihr die Logik z.B. in Form einer Art Liste „Entities aus welchem Schema werden in welchem ContentSelect (d.h. letztlich „von welchem Template“) benutzt“.

Liebe Grüße

Marcel

0 Kudos
mbergmann
Crownpeak employee
Crownpeak employee

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hallo Marcel,

richtig, wenn überhaupt passiert das am besten nach dem Task der die Deltagenerierung inititialisiert und dem Generierungstask.

Ganz streng technisch genommen gibt es ja keine „Funktion“ zur Deltagenerierung sondern es ist letztlich nur eine „Finde-alle-möglichen-Änderungen-und-füge-dadurch-betroffene-Seitenreferenzen-zum-Generierungstask-hinzu-Funktion“, die letztlich mit „Bordmitteln“ arbeitet, insb. der Revisionshistorie. Die Abkürzung „FamÄufdbSzGhF“ hat es dann aber nicht ins Manual geschafft 😉

Zur Liste die ich erwähnt habe: Das müsstet ihr halt selber bauen bzw. implementieren. Ich meinte damit, dass es wohl eine gute Idee wäre, so eine Zuordnung irgendwie konfigurierbar zu machen und nicht bei jedem neuen Template das ein ContentSelect nutzt ans Modul zu müssen.

Viele Grüße

Michael

mbergmann
Crownpeak employee
Crownpeak employee

Re: ContentSelect: Änderung in DB erkennen (Deltagenerierung)

Jump to solution

Hi Marcel,

mir fiel gerade noch eine Variante ein, mit der man sich eine manuelle Pflege der "Zuordnung" ggf. sparen könnte:

Idee: Nutzung des QueryAgent um damit "geeignet" zu suchen - z.B. nach "contentSelect". Nach ein bisschen weiterer Filterung (nur Templates usw.) hättest Du schonmal die Templates die ein ContentSelect verwenden. An den Code des Ausgabekanals kommt man ja auch per API und kann damit letztlich herausfinden, auf welche Tabelle das ContentSelect "zielt" (dabei beachten, dass in einem Template ggf. auch mehrere ContentSelects sein können). Daraus kann man sich schonmal automatisch eine Zuordnung bauen, welche Templates welche Schematabellen per ContentSelect "referenzieren".

Wenn Du dann über die Revisionshistorie gehst und Dir alle geänderten Datensätze holst, müsstest Du die Datensätze (bzw. den EntityType) mit dieser Liste abgleichen. Es bleibt dann eine Liste mit "relevanten Templates".

Wenn Du dann über die eingehenden Referenzen dieser Templates "rückwärts" zu den entsprechenden Seitenreferenzen läufst und die dann als Startknoten zum Generierungstask hinzufügst, sollte es passen.

Ist allerdings schon etwas aufwändiger und ein bisschen "schräg" 😉

Viele Grüße

Michael