Teil-Generierung: Revision Problem
Author: Dakine
Publication Date: 12/3/2014 13:12
Hallo zusammen,
ich habe in einem Projekt das Problem, eine korrekte Teil-Generierung über ein Skript ausführen zu lassen. Das Skript wird über einen Arbeitsablauf (Freigabe-Workflow) manuell ausgeführt, nachdem ein Redakteur die Seite freigegeben hat und soll die dem Workflow entsprechende Seite generieren und anschließend auf dem Web Server ablegen (also ein ganz gewöhnlicher Partly-Deply Auftrag).
Der Arbeitsablauf sieht folgendermaßen aus und markiert zunächst eine freigegebene aber noch nicht deployte (Inhalts-) Seite:
Durch den Klick auf einen entsprechenden Button im Arbeitsablauf kann über das folgende Skript "deploy" nun ein Deploy Auftrag angestoßen werden:
[...]
/////////////////////////////////////////////////
schedulename = "generate & deploy partly";
scheduleEntry = null;
/////////////////////////////////////////////////
_project = context.getProject();
element = context.getElement();
context.logInfo("Current Revision : " + element.getRevision().getId());
context.logInfo("Release Revision: "+element.getReleaseRevision().getId().toString());
ss = context.getUserService().getStore(de.espirit.firstspirit.access.store.Store.Type.SITESTORE,false);
rev = element.getReleaseRevision();
if (element != null) {
scheduleStorage = context.requireSpecialist(ServicesBroker.TYPE).getService(AdminService.class).getScheduleStorage();
allScheduleEntries = scheduleStorage.getScheduleEntries(_project); // get all ScheduleEntries of the current project
for (entry : allScheduleEntries) {
if (entry.getName().equals(schedulename)) { // search for the ScheduleEntry "generate & deploy partly"
scheduleEntry = entry;
break;
}
}
if(scheduleEntry != null){
gTask;
for(ScheduleTask scheduleTask : scheduleEntry.getTasks()) { // get all tasks of selected schedule entry
if(scheduleTask instanceof GenerateTask) {
gTask = scheduleTask;
break;
}
}
if (gTask != null){
gTask.getStartNodes().clear(); // Clear old start nodes
gTask.getStartNodes().add(element.getInRevision(rev));
}
control = scheduleEntry.execute(); // Executing the deployment
control.awaitTermination(); // the workflow waits untill the schedule-task ended
context.logInfo(control.getState().getState().toString());
}
else {
context.logError("The ScheduleEntry '" + schedulename + "' doesn't exist!");
}
}
context.doTransition("finito"); // change workflow-status
Bei jeder Auftragsausführung erhalte ich aber folgende Fehlermeldung:
ERROR 03.12.2014 13:33:12.830 (de.espirit.firstspirit.server.scheduler.GenerateTaskExecutor): sitestore node id=11757 not found for revision 26775
Das Problem hängt also mit der Revision zusammen. Erstaunlicherweise existiert die gesuchte Revision - hier im Beispiel '26775' - auch gar nicht. Die korrekte Revision lautete zum Zeitpunkt der Skript-Ausführung in diesem Beispiel "26774"! Dies habe ich mit entsprechenden Log-Ausgaben überprüft.
Auch in der Versionhistorie der zugehörigen Inhaltsseite ist die in der Fehlermeldung angegebene Revision überhaupt nicht vorhanden. Dort tauchen lediglich die beiden Revisionen VOR und NACH dem Deploy auf (also "nach Freigabe" mit Bsp. ID "26774" und "nach Deploy" mit Bsp. ID "26776").
Woran kann dieses Problem liegen? Kann ich die Revision noch irgendwie anders manuell beeinflussen? Und vor allem: Wie und wann ist die neue (falsche) überhaupt entstanden und warum wird diese dann auch noch verwendet, wenn ich im Skript doch sogar extra mit angebe, dass die Revision vom Zeitpunkt der Freigabe verwendet werden soll? Hat mein hinzugefügter StartNode überhaupt Auswirkung auf den Auftrag?
Ich bedanke mich im Voraus und hoffe, dass mir jemand helfen kann!
Viele Grüße!
Fredrik
Tags: deploy, generation, generierungsscript, generierungsskript, revisions, teilgenerierung, workflow-script
-
Author: Dakine - 12/3/2014 14:54
Nachtrag:
Im Auftrags-Logfile des "generate partly" Tasks steht unter anderem die folgende Zeile:
INFO 03.12.2014 15:44:40.064 (de.espirit.firstspirit.server.scheduler.GenerateTaskExecutor): setting user service to nearest revision Wed Dec 03 15:44:40 CET 2014
Exakt hier wird offensichtlich die zuvor im Skript festgelegte Revision wieder überschrieben und stattdessen eine neue verwendet! Kann man dies auf irgendeine Art und Weise unterbinden?
0 -
Author: mbergmann - 12/3/2014 22:33
Hallo Fredrik,
eigentlich sollte es reichen, einfach direkt das "element" in die Liste der Startnodes zu legen. Es wird ja dann automatisch die letzte freigegebene Revision generiert. Gibt es denn einen bestimmten Grund warum Du hier versuchst eine bestimmte Revision zu holen?
Falls Du ganz bewusst einen "vergangenen" Stand generieren willst, würde man das über eine Änderung der "startTime" des Auftrags bzw. des ScheduleContextes machen.
Stichwort context.setStartTime(...)
Viele Grüße
Michael
0 -
Author: Dakine - 12/4/2014 9:27
Hallo Michael,
vielen Dank für die Antwort!
Es gibt keinen bestimmten Grund warum ich hier versuche auf eine bestimmte Revision zuzugreifen. Ich möchte eigentlich nur erreichen, dass die aktuell freigegebene Revision generiert wird. Die Zeile ist nach mehrfachen Testen irgendwann entstanden, weil das normale "Element" den selben Fehler verursacht hatte. Ich habe es jetzt wieder rückgängig gemacht und am Fehler hat sich wie erwartet nichts geändert.
element = context.getElement();
[...]
gTask.getStartNodes().add(element);
Es bleibt also beim Problem, dass während der Auftragsdurchführung eine spätere/neuere Revision verwendet wird als das element während der Skript-Ausführung hergibt.
Grundsätzlich ist mir in der API zur ScheduleEntry "execute" -Methode noch folgender Satz aufgefallen:
Start execution on the server - locked entries will be started with the settings which are actually set on client side, all other entries will be started with the settings wich are stored on the server.
Was hat dies zu bedeuten? Könnte mein Problem eventuell mit diesem Satz zusammenhängen? Denn so wie es aussieht werden die Client-seitigen Einstellungen ja überhaupt nicht verwendet bzw. vom Server überschrieben (Stichwort "
setting user service to nearest revision" im Auftragslog)Ich habe daraufhin versucht, den ScheduleEntry zu sperren (lock) und zum Abschluss wieder zu entsperren (unlock):
[...]
if(scheduleEntry != null){
scheduleEntry.lock();
gTask;
for(ScheduleTask scheduleTask : scheduleEntry.getTasks()) {
if(scheduleTask instanceof GenerateTask) {
gTask = scheduleTask;
[...]
[...]
control = scheduleEntry.execute();
control.awaitTermination();
scheduleEntry.unlock();
Der ScheduleEntry wird erfolgreich gelockt, allerdings ohne positive Auswirkung auf die Auftragsausfühung - der Fehler bleibt der Selbe.
Viele Grüße,
Fredrik
0 -
Author: MarsDD - 12/4/2014 9:54
Hallo,
da Du aufgrund eines Workflows mit einer Seite (PageRef) arbeiten möchtest, würde ich wahrscheinlich versuchen das Object via WorkflowScriptContext anzusprechen.
WorkflowContext wc = WorkflowScriptContext.getWorkflowContext();
IDProvider idp = wc.getElement();
Viele Grüße
Marcel
0 -
Author: Dakine - 12/5/2014 8:55
Hallo!
Ich habe jetzt einen anderen Weg gefunden, um die durch das Projekt geforderten Anforderungen schneller zu erfüllen. Das Hauptziel bestand darin, den Redakteuren anhand einer farblichen Markierung sichtbar zu machen, welche Seiten/Inhalte/Medien freigegeben wurden und seitdem noch nicht deployt wurden.
Aufgrund des recht straffen Zeitplans habe ich mich nun dazu entschieden, ein Skript an den normalen Deploy Auftrag dran zu hängen, das einfach allen zu veröffentlichenden und freizugebenen Objekten anhand eines zweiten Workflows die Markierung wieder entfernt.
Deinen vorgeschlagenen Weg, Marcel, das entsprechende Objekt über den WorkflowScriptContext anzusprechen, werde ich dann einmal ausprobieren, wenn die Anforderung selbst erst einmal erfüllt worden ist und ich Zeit hierfür finde. Dementsprechend vorab schon einmal vielen Dank für Deine Hilfe! Ich werde mich dann noch einmal melden.
Viele Grüße,
Fredrik
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
5 commentaires