Im Auftrag per Script Wert aus vorherigem Task ermitteln

[daniel_philippi]

Hallo zusammen.

In einem Auftrag spiele ich ein Feature ZIP ein (1. Task). Danach als 2. Task möchte ich in einem Script Task ermitteln ob es einen Fehler oder ein Warning gab.

- Bei Warnings möchte ich nichts machen, da es dann keine Änderung am Feature ZIP gab und somit auch nichts eingespielt wurde.

- Bei einem Fehler oder bei erfolgreichem Ausführen soll eine Mail verschickt werden.

Wie kann ich aus dem Script Task (2. Task) auf die Ausgaben des vorherigen Tasks (1. Task) zugreifen? Mit der .test() Funktion auf dem vorigen Task erhalte ich immer 0 Fehler und 0 Warnings. Das scheint mir aber nicht der korrekte Weg zu sein.

Gruß,

Daniel

[mbergmann · Accepted solution]

Hallo Daniel,

die Infos dazu findest Du letztlich im TaskResult, nicht im ScheduleTask (der ist quasi nur das „Modellobjekt“). Der Weg dahin ist allerdings etwas weiter. Wenn man beim ScheduleContex anfängt, sieht das dann so aus:

List<TaskResult> results = context.getTask().getScheduleEntry().getRunningEntries().get(0).getState().getTaskResults();

Dann musst Du nur noch das „richtige“ Ergebnis zum gesuchten Task in der Liste finden. Letztlich entspricht die Reihenfolge der Ergebnisse der Reihenfolge der Tasks im Auftrag. Wenn Du weißt, dass der fragliche Task der erste ist kannst Du Dir direkt mit .get(0) das entsprechende Ergebnisobjekt holen und auswerten, fände ich persönlich aber etwas „fragil“ (wenn man da irgendwann einen Task vorher einfügt, geht es kaputt). Besser wäre, sich den „richtigen“ task unabhängig von der genauen Position zu holen oder ggf. noch mit .get(context.getTaskIndex()-1) immer den vorherigen. Oder bis zum aktuellen Task-1 zu iterieren und nach dem passenden Typ suchen. Halt so eindeutig wie möglich.

Auf dem TaskResult hast Du dann die Möglichkeit, die Anzahl der Fehler, Warnings usw. zu holen.

Mit der Mail würde ich es dann so machen, dass der Auftrag dann einen entsprechenden Mail-Task enthält der aber deaktiviert ist. Das Skript würde den dann einfach passend aktivieren (dass der Task aktiviert ist wird nicht gespeichert, sondern gilt nur temporär für die laufende Instanz des Auftrags).

An die Liste der Tasks des aktellen Auftrags (zum (de)aktivieren) kommt man einfach mit context.getTasks() - da gilt es dann letztlich wie oben, den passenden Task sinnvoll zu finden.

Hinweis: Da Du um an das TaskResult zu kommen, ein ScheduleEntryControl brauchst und dazu über die runningEntries gehen musst, funktioniert das Ganze so nur, wenn der Auftrag nicht parallel ausgeführt werden kann - sonst erwischst Du ggf. den falschen mit .get(0).

Falls die parallele oder gequeuete (was für ein Wort... :-)) Ausführung erlaubt ist, müsstest Du das richtige Control auch noch „finden“, das sollte aber über einen Vergleich der jew. Startzeit mit context.getStartTime() gehen. Das natürlich wiederum nur wenn Du die im aktuellen Auftrag nicht über context.setStartTime geändert hast 😉

Viele Grüße

Michael

[mikula]

Hallo Daniel,

Ich glaube besser hätte Michael es nicht beantworten können. Benötigst Du noch weitere Hilfe oder hat Dir die Michaels Antwort 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

Martin

[daniel_philippi]

Martin du hast vollkommen recht. Perfekte Hilfe, vielen Dank!