mfinsterbusch
New Responder

im ContentCreator "Auftrag starten"

Hallo Community,

wir lassen unsere Deployments über Aufträge laufen...

Kann man (wie?) die schedules direkt im ContentCreator aktivieren, so dass diese dort gestartet werden können?

Danke & Grüße,

Maik

9 Replies
mfinsterbusch
New Responder

Hallo,

habe nun gefunden, dass offenbar ein skript eine Möglichkeit ist.

Daraus resultierend müssen dann auch 'reports' 'manuell' zusammenprogrammiert werden.

https://community.e-spirit.com/thread/6779

Gibt es hier eine einfachere Lösung?

Was ist best-practice?

Danke,

Maik

0 Kudos

In der Regel gibt der Redakteur über einen Arbeitsablauf frei, der dann dafür sorgt, dass ein passender Deploymentauftrag angestoßen wird.

0 Kudos

Hi Christoph,

vielen Dank für Deine Antwort.

Dann treffen wir leider nicht die Regeln, sondern publishen mittels schedule ohne Zusammenhang zum release-workflow.

Daher nochmal die Frage: kann man aus dem site-architect (einfach und wenn ja, wie?) die 'execute schedule' Funktion im content creator einbinden (ohne den Folgeproblemen // indivudueller Programmierung aus https://community.e-spirit.com/message/25084)?

Danke,

Maik

0 Kudos

Hallo Maik,

so ganz verstehe ich deine Anforderung wohl noch nicht.

Das Starten von Aufträgen geht entweder per Workflow oder Skript. Das ist in wenigen Zeilen Code erledigt.

Geht es dir um die Funktion die Logfiles eines Auftrags lesen zu können, wenn der fertig abgeschlossen wurde? Das gibt es im ContentCreator nicht. Unserer Meinung nach kennt ein Redakteur dort das Konzept von Aufträgen nicht. Er möchte auch keine Logfiles lesen, er könnte sowieso nichts damit anfangen.

Er geht einfach davon aus, dass die Änderungen kurz nach erfolgter Freigabe/Deployment online gehen.

Sollte ein Problem auftreten, muss sowieso ein "Techniker" informiert werden. Zusätzlich kann man dem Redakteur auch eine Mail schicken, um ihn über das Problem zu infomieren. Das kann man einfach über entsprechende Mail-Tasks im Auftrag bauen.

Viele Grüße

Christoph

0 Kudos

Hallo Christoph,

"[..] Er möchte auch keine Logfiles lesen, er könnte sowieso nichts damit anfangen. [..]"

Das ist bei uns nicht so. Bei uns (muss) ein Editor mitdenken (z.B. bei einer Fehlerausgabe einer nicht gefüllter, mandatory Komponente...)

Im Grunde nutzen wir die Funktionialität aus dem SiteArchitect "Project > Execute schedule entry".

Warum? Generation + File transfer erfolgt in einem Schedule, nicht in einem (release-) workflow.

Nun stellen wir auf den ContentCreator um und möchten auch ein "Project > Execute schedule entry" out-of-the-box haben (mit selbigen Verhalten / Features, u.A. die logfiles). Das gibt es aber offenbar nicht?

Also bleibt nur noch selbst coden- skript (wenige Zeilen?) + das "ausgeben" des logfiles?

In Summe also doch wieder mehr Aufwand... richtig?

Grüße,

Maik

0 Kudos

Hallo Maik,

unsere Empfehlung an der Stelle ist natürlich den Fehler schon viel früher zu Erkennen. Über Regeln kann man zum Beispiel das Speichern oder die Freigabe verhindern. Da wird dem Redakteur auch visualisiert wo das Problem liegt und er kann es direkt beheben. Das geht auch ohne Programmieren, sondern einfach über die Regeldefinitionen in den Vorlagen.

Viele Grüße

Christoph

0 Kudos

Hi Christoph,

"unsere Empfehlung an der Stelle ist natürlich den Fehler schon viel früher zu Erkennen. Über Regeln kann man zum Beispiel das Speichern oder die Freigabe verhindern."

Das verstehe ich, finde ich gut und machen wir auch.

Ich möchte dennoch wetten, dass >80% aller FirstSpirit produktiv-Projekten zumindest Generierungswarnungen vorhanden sind 😉

Die Fehler können ja vielseitig entstehen und auch vielseitig sein, nichtzuletzt z.B. durch eine geschlossene WAN-Session oder dem beliebten rsync oder CRC-Servlet ausgelöst werden... Auch dann möchte ein Editor (QAler, DEVler, ... ) natürlich gern Feedback (ohne noch wild in den logs in servermonitor kramen zu müssen.

Zumindest bei uns ist es ein NOGO dieses Feedback aufgrund fehlender Funktionalität zu 'ignorieren', nur weil man diese hätte verhindern können.

Zum dritten Mal die Frage: Geht es oder nicht, s.o.?

Danke im Voraus,

Maik

0 Kudos

Hallo Maik,

erst mal vorweg: Ja, musst du selber programmieren, wie unter https://community.e-spirit.com/message/21020#21020 bereits gesagt wurde.

Jetzt noch mal zu unseren Empfehlungen:

Es gibt sicher Projekte, wo bei jeder Generierung Warnungen, wenn nicht sogar Fehler auftreten. Die werden ignoriert, weil es gar keine "echten" Warnungen oder Fehler sind und gar nichts kaputt ist. Das ist sicherliche eine schlechte Praxis. Wie unterscheidet man dann "echte" und "unechte" Fehler?

Ein ordentlich umgesetztes Projekt hat keine unechten Fehler und Warnungen bei der Generierung. Hier sollte man wirklich etwas Zeit in die Überarbeitung der Vorlagen investieren. Mit den Regeln kriegt man ohne Probleme Vorlagen hin, die nur bei echten Fehlern auch Fehler protokollieren.

Bleiben noch die nachfolgenden Schritte wie Scripte, Deploymenttasks etc. die ggf. fehlschlagen können. Auch hier bin ich mir nicht sicher, ob der Redakteur darüber informiert werden muss. Die von dir genannten Beispiele klingen alle nach Problemen, um die sich die IT kümmern müsste. Nun kenne ich eure Rollenverteilung nicht. Wenn ihr IT, Entwickler und Redakteur in Personalunion seid, mag eine Information in FirstSpirit sinnvoll sein. Bei getrennten Rollen würde ich bei Problemen beim Deployment eher die IT benachrichtigen wollen. Klar kann man den Redakteur in "CC" setzen, wenn das häufiger mal auftritt.

Aus IT-Sicht will ich bei einem Problem mit dem Deployment oder WAN eher eine Mail kriegen oder in meiner Monitoring-Anwendung sollte eine Lampe angehen. Die Logfiles will ich auch nicht in FS anschauen. Weder im ContentCreator, noch im ServerMonitor. Die will ich in meiner zentralen Logsoftware anschauen. Je nach eingesetzer Software würde auch diese Alarm schlagen können, wenn in den FirstSpirit-Logs Fehlermeldungen auftauchen oder einen Schwellwert überschreiten.

Ich hoffe das hilft etwas weiter.

Viele Grüße

Christoph

mfinsterbusch
New Responder

Hi Christoph,

wir haben eine 0/0 policy, daher nur echte Fehler, aber auch diese will man sehen 😉

Danke, jetzt weiß ich woran wir sind. Vielleicht ist das ja sogar ein Feature-Request wert... schauen wir mal!

Danke & Grüße,

Maik