Questions & Answers

SOLVED
daniel_philippi
Occasional Collector

Im Auftrag per Script Wert aus vorherigem Task ermitteln

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
mbergmann
Crownpeak employee

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

View solution in original post

0 Kudos
3 Replies
mbergmann
Crownpeak employee

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

0 Kudos
mikula
Crownpeak employee

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

0 Kudos

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

0 Kudos

Type a product name