arnbae
I'm new here

Deployment-Mail: Fehlerhafte Generierung testen versagt.

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?

7 Replies
Peter_Jodeleit
Crownpeak employee

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

Peter
0 Kudos
arnbae
I'm new here

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. Smiley Wink 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

0 Kudos

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$

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 Smiley Wink

HTTP ERROR: 404

NOT_FOUND

RequestURI=/help/odfs/dev/de/espirit/firstspirit/access/schedule.ScheduleEntryState.html

Powered by Jetty://

Grüße,

Arndt

aVogt
Returning Creator

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

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 Smiley Happy.

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

Grüße,

Arndt

0 Kudos
aVogt
Returning Creator

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

0 Kudos