Questions & Answers

[arnbae]

Hallo,

hat jemand mit so etwas schon Erfahrungen oder kann sich/mir das Verhalten erklären? Am Abschluss eines Deployment-Auftrags wird eine Mail mit folgendem Text (FS-Template) verschickt:

$CMS_SET(set_tasks,#context.tasks)$
$CMS_FOR(task,set_tasks)$
     $CMS_IF(task.name.contains("Generierung"))$
          $CMS_SET(set_result,task.test())$
========================================================
Erfolgreich: $CMS_IF(set_result.wasSuccessful())$Ja$CMS_ELSE$NEIN$CMS_END_IF$
Warnungen: $CMS_VALUE(set_result.getWarningCount())$
Fehler: $CMS_VALUE(set_result.getErrorCount())$
Schwere Fehler: $CMS_VALUE(set_result.getFatalCount())$
========================================================
Meldungen im Logfile:
$CMS_VALUE(set_result.getMessages().replaceAll("INFO  ","\nINFO ").replaceAll("WARN  ","\nWARN ").replaceAll("ERROR  ","\nERROR "))$
========================================================
     $CMS_END_IF$
$CMS_END_FOR$

Sprich: Es wird der Generierungs-Task gesucht, und versucht, die Fehler, den Status und ein paar Meldungen auszugeben. Es kommt aber immer unweigerlich folgendes Ergebnis in der Mail an, auch wenn die Generierung Fehler geworfen hatte:

========================================================
Erfolgreich: Ja
Warnungen: 0
Fehler: 0
Schwere Fehler: 0
========================================================
Meldungen im Logfile:
INFO 11.07.2012 12:24:35.670 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): dummy session created (ID=2624406399010441636, user=ScheduleManager)
INFO 11.07.2012 12:24:35.670 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): close dummy session (ID=2624406399010441636, user=ScheduleManager)
INFO 11.07.2012 12:24:35.670 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): Invalid session id 2624406399010441636
INFO 11.07.2012 12:24:35.670 (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): finished test schedule task 'Generierung' - 0 fatal error(s), 0 error(s), 0 warning(s)

Was machen wir falsch?

[Peter_Jodeleit]

Das sieht doch gut aus. Wie ist denn der Mail-Text, wenn die Generierung Fehler hatte?

[arnbae]

Arndt Bär schrieb:

...

Sprich: Es wird der Generierungs-Task gesucht, und versucht, die Fehler, den Status und ein paar Meldungen auszugeben. Es kommt aber immer unweigerlich folgendes Ergebnis in der Mail an, auch wenn die Generierung Fehler geworfen hatte:

Ähm, das hätte ich wohl noch deutlicher hervorheben müssen: Das ist der Mailtext, wenn die Generierung Fehler hatte. Und auch der, wenn sie keine hatte. Das ist immer der Mailtext. Wenn ich mir die Messages so anschaue, kommt bei mir die Vermutung auf, dass .test() nochmals (irgendwas) auf dem task neu testet, und dann nicht das ursprüngliche Ergebnis, sondern das Ergebnis eines Dummy-Tests zurückgibt.

Grüße,

Arndt

[feddersen]

Ja, task.test() sieht verkehrt aus.

Hier mal ein Beispiel aus einem Projekt.

Es wird davon ausgegangen, dass die Generierung der 2. Task im Auftrag ist.

FIRSTspirit mail for project $CMS_VALUE(#context.getProject().getName())$
$CMS_SET(set_scheduleEntryControl, #context.getTask().getScheduleEntry().getRunningEntries().get(0))$
$CMS_SET(set_generateTaskResult, set_scheduleEntryControl.getState().getTaskResults().get(1))$
Total number of pages: $CMS_VALUE(set_generateTaskResult.getTaskInfoBean().getPageIndex())$
FATAL errors: $CMS_VALUE(set_generateTaskResult.getFatalErrorCount())$
Errors:       $CMS_VALUE(set_generateTaskResult.getErrorCount() )$
Warnings:     $CMS_VALUE(set_generateTaskResult.getWarningCount() )$
$CMS_IF(set_generateTaskResult.getState().toString().equals("SUCCESS"))$
Generation successful!
$CMS_END_IF$ 

[arnbae]

Hallo,

vielen Dank, das ist in vielerlei Hinsicht ein Augenöffner. Gehe ich da recht in der Annahme, dass sich der "normale" ScheduleEntry auf die statischen Aufträge auf dem Server bezieht, ich aber über die "RunningEntries" gehen muss, um den Status von aktuell laufenden Entries / Tasks zu gekommen? Das macht Sinn. Das hatte ich nämlich schon verwendet, um herauszufinden, welcher User ein interaktives Deployment denn nun wirklich angestoßen hatte.

Einige andere Dinge stören mich dabei aber massiv:

• get(0) geht ja davon aus, dass ich mich gerade in der ersten / einzigen laufenden Instanz dieses Scheduler-Eintrags befindet. Wie realisiert man das aber sauber, wenn man die parallele Ausführung dieses Auftrags zugelassen hat?
• get(1) und die Annahme, dass die Generierung der zweite Eintrag (oder irgendein anderer, fixer Task) ist, schreien geradezu nach zukünftigen Fehlern, wenn man beispielsweise neue Tasks einfügt oder den Mail-Task als Vorlage (Referenz) verwenden will. Kann man den Generierungstask nicht anhand des Namens oder des Typs feststellen?
• Ich hatte ja ursprünglich auch einige Meldungen aus dem Logfile mit getMessages() bekommen - gibt es so etwas bei generateTaskResult?
• Ergänzung zum Beispielscript: "SUCCESS" muss wohl in Anführungszeichen stehen, oder?
• Was Generelles: Gibt es einen Weg, Scripte und Mailvorlagen in Deployment-Aufträgen zu testen (vom Redaktions-Client aus, weil es ja ein interaktives Deployment ist!), ohne jedesmal das Projekt neu starten zu müssen? Änderungen werden erst erkannt, wenn ich das Projekt neu lade.

Die ersten paar Punkte würde ich ja selbst anhand der API-Doku klären, aber die Dokumentation des ScheduleEntryState lautet

HTTP ERROR: 404
NOT_FOUND
RequestURI=/help/odfs/dev/de/espirit/firstspirit/access/schedule.ScheduleEntryState.html
Powered by Jetty://

Grüße,

Arndt

[aVogt]

Hallo Arndt,

vieleicht hilft folgendes weiter: https://community.e-spirit.com/docs/DOC-1122 oder Anhang (daruf beziehe ich mich in den untenstehenden Hinweisen)

Mit

$CMS_VALUE(TR.getTask().getName())

kommst Du an den Namen den Du Aktionsnamen ran, wenn der immer gleich bennent sollte man darüber den Generieirungstask herausbekommen.

Mit

$CMS_VALUE(TR.getTask())$

bekommst Du

de.espirit.firstspirit.admin.GenerateTaskImpl

dagegen könnte man sicher auch prüfen.

Grüße Andreas

[arnbae]

Hallo,

ja, das hilft natürlich enorm weiter. Darauf, dass der Index der Tasks im Scheduler-Eintrag mit den TaskResults aus getTaskResults korrelliert, hätte ich mir ja denken können .

Jetzt fehlt mir zu meinem Glück nur noch die API-Doku von ScheduleEntryState ...

Grüße,

Arndt

[aVogt]

FS sagt immer: "Wenn die Klasse nicht in der Doku steht, ist diese nicht öffentlich. Sie kann verwendet werden, könnte sich aber bei einer neuen version ändern ..." (oder so ähnlich).

Eclipse hat folgende Methoden in der Klasse als Vorschlag (siehe Anhang)

Noch ein Hinweis:

Gegen die "impl-Klasse" sollte man auch nicht testen, die kann sich auch ändern

aber es gibt: de.espirit.firstspirit.access.schedule.GenerateTask, ob dass passt kann ich nicht sagen.

Grüße

Andreas