Problem bei Aktualisierung von Datenquellen in Remote-Projekten
Author: benjaminfrenz
Publication Date: 4/28/2015 7:28
Hallo zusammen,
wir mussten in letzter Zeit immer wieder feststellen, dass Datensätze, die im Master-Projekt verändert und freigegeben werden, in den Remote-Projekten nicht sofort und auch nicht bei einer Generierung aktualisiert werden. D.h. es wird der alte Stand generiert oder sie sind nicht vorhanden (neue Datensätze). Ein konkretes Beispiel sind Pressemitteilungen. Man muss im Remote-Projekt dann die Datenquelle auswählen und sie dann manuell aktualisieren (bspw. F5), selbst wenn das Remote-Projekt gerade erst neu geöffnet wurde. Wieso ist das so?
Vor jeder Generierung wird übrigens auch per Script eine neue Revision getaggt. Hier noch einmal der Ablauf:
1. Im Master-Projekt wird ein neuer Datensatz in einer Datenquelle angelegt oder ein bestehender bearbeitet.
2. Dieser Datensatz wird im Master-Projekt freigegeben.
3. Eine Generierung wird in einem Länderprojekt angestoßen, welches die Datenquellen per Corporate Content bekommen hat.
4. Beim Ergebnis der Generierung ist der Datensatz nicht vorhanden oder nicht aktuell.
5. Das Länderprojekt wird geöffnet, die Datenquelle ausgewählt. Die entsprechenden Datensätzen sind nicht aktuell oder nicht freigegeben.
6. Nach Aktualisierung bspw. mit F5 sind die Datenquellen wieder auf dem Stand des Master-Projekts.
7. Nach einer weiteren Generierung ist auch das Ergebnis aktuell.
Ist es wirklich gewollt, dass man bei Änderungen im Master in jedem angebundenen Projekt noch einmal die Datenquellen aktualisieren muss?
Muss mann die Aktualisierung bei der Freigabe oder bei der Generierung noch einmal explizit anstoßen?
Viele Grüße
Benjamin
Server-Version: 5.1.311.65223, frisch aufgesetzt, keine Altlasten, neue Projekte
Tags: database, datenbank, datenquelle, deployment, fs5.0, fs5.1, generation, generierung, preview, script
-
Author: der_sk - 4/28/2015 10:07
Wir haben gerade in einem Projekt ein ähnliches Problem, das habe ich aber nur am Rande verfolgt.
Eine Hoffnung ist, das die Version 5.1.415 Abhilfe schafft.
0 -
Author: benjaminfrenz - 4/28/2015 10:15
Wenn es wirklich ein FS Problem ist und kein konfiguratives Problem, dann wäre ein Workaround-Skript, Modul o.ä. schön, bis es in einer späteren Version behoben wird. Nach Angabe unseres Kunden soll es wohl schon in der 5.0 so gewesen sein.
0 -
Author: witt - 4/28/2015 14:17
Hallo Benjamin,
was du oben geschildert hast entspricht dem aktuellen Stand.
Ich versuche das mal kurz zu erläutern:
Generell wird bei einer Generierung immer ein gewisser Zeitstempel (Revision) verwendet gegen den die Elemente des Projektes ermittelt werden. Im Master hast du mit der Erzeugung eines neuen Datensatzes neben dem Inhalt nun auch noch eine neue Revision im Projekt erzeugt (T1 - 28.04.2015 15:00). In deinem Zielprojekt wurde die letzten Stunden, Tage nicht gearbeitet und keine inhaltliche Veränderung vorgenommen, also ist die Revision hier z.B. (T2 - 26.04.2015 17:00). Bei der Generierung holt der Prozess die höchste Revision des Projektes, also z.B. T2. Im Falle der Datenbank werden nun alle Elemente ermittelt die <T2 sind. Du siehst also, hierdurch wird T1 ausgeschlossen. Das ist erstmal soweit ok, denn es gib einen ganz einfachen Workaround für dieses Design.
Du kannst vor deiner Generierung ein Skript mit folgenden Inhalt einfügen und dann sollte es auch schon funktionieren:
context.getProject().createTaggedRevision(Generation,needed for external database content);
context.setStartTime(new Date());Hier wird eine neue Revsion erzeugt mit dem aktuellen Datum und auch auch gleichzeitig dafür gesorgt, dass der Generierungsprozeß den aktuellen Zeitstempel erhält.Das ist schon alles!
Ähnliche Beiträge findest du auch hier in der Community https://community.e-spirit.com/message/10636#10636, https://community.e-spirit.com/community/developer/blog/2011/09/13/creating-time-dependent-content)
Innerhalb des Clients wird durch ein F5 automatisch der Cache aktualisiert, so dass ähnlich wie im Skript oben die Revision wieder aktuell ist.
0 -
Author: benjaminfrenz - 4/28/2015 14:42
Daniel Witt schrieb:
Innerhalb des Clients wird durch ein F5 automatisch der Cache aktualisiert, so dass ähnlich wie im Skript oben die Revision wieder aktuell ist.
Genau das ist das Verhalten, was ich selbst beobachten konnte. Unser Kunde schilderte aber auch, dass bei der Generierung nicht die aktuellen Daten gezogen werden.
Dabei wird bereits vor jedem Deployment wird dieses Skript ausgeführt:
project = context.getProject();
project.createTaggedRevision("Generation","needed for generation of automatic changed content");
context.setStartTime(new Date());
Da meine Ansprechpartner vor Ort nun erstmal im Urlaub sind, kann ich das Verhalten selbst wohl erst Mitte Mai prüfen. Vielleicht war es auch nur eine Fehleinschätzung aufgrund des Cache im Client.
0 -
Author: marza - 5/22/2015 13:36
Hallo Benjamin,
benötigst Du noch weitere Hilfe oder haben Dir die Antworten von Daniel bereits geholfen?
In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.
Viele Grüße
Marian
0 -
Author: der_sk - 5/22/2015 17:35
Ich kann für die Version 5.1.410 bestätigen, dass das beschriebene Vorgehen funktioniert - also vielleicht war es zwischendurch ein Bug. Wenn es bei euren Tests nicht funktioniert, dann könnte ein Update also allem Anschein nach helfen.
0 -
Author: rlucas - 10/24/2016 13:57
Die API hat sich in 5.2 geändert, dass Skript muss nun wie folgt aussehen:
project = context.getProject();
project.createTag("Generation","needed for generation of automatic changed content",null);
context.setStartTime(new Date());
0 -
Author: danielbaer - 7/20/2017 10:36
Hallo zusammen,
wir setzen das Skript für die neue Revision ebenfalls ein (Kommentar von Reinhard Lucas) und nutzen im gleichen Auftrag auch noch ein Skript zur Deaktivierung der Freigabe:
context.getProject().setUseRelease(false);
Scheinbar mögen sich die Skripte aber nicht. Denn sind die beiden Skripte im Auftrag hinterlegt, funktioniert die Deaktivierung der Freigabe nicht. Wir hatten die Reihenfolge der beiden Skripts bereits geändert, das brachte aber nur bis zum nächsten FirstSpirit-Update etwas.
Habt ihr das Problem auch beobachtet? Gibt es Tricks oder Empfehlungen um das Problem zu lösen?
0 -
Author: hbarthel - 10/28/2017 3:50
Hallo,
ich habe genau dasselbe Problem beobachtet. Zwei Bad Hacks auf einmal in einem Auftrag... das geht nun wirklich nicht :-D
Wir haben aktuell 5.2R12 drauf und ich möchte sagen, dass die Kombination der beiden früher funktioniert hat und erst seit irgend einer neueren FS-Version nicht mehr.
Gruß Heiko
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
9 commentaires