bIT_sosswald
Returning Responder

Aktuelle Instanz des ScheduleEntry ermitteln aus dem ein Modul aufgerufen wurde

Jump to solution

Hallo Community,

ich habe ein Modul, welches aus einem ScheduleEntry mitteld eines Executables aufgerufen wird. Vor und nach dem Aufruf des Moduls sind noch weitere Tasks in dem besagten ScheduleEntry vorhanden. Nun möchte ich in bestimmten (Fehler-)Fällen die aktuell ausgeführte Instanz des  ScheduleEntrys programmatisch aus dem Modul heraus abbrechen, so dass die Tasks, die nach dem Modulaufruf definiert sind, nicht mehr ausgeführt werden.

Natürlich möchte ich, sollte der Schedule mehrfach parallel ausgeführt worden sein, immer nur die Instanz davon abbrechen, in der auch wirklich der Fehler auftrat.

Da der ScheduleEntry nicht programmatisch, sondern entweder manuell oder zeitgesteuert gestartet wird, habe ich nicht von Anfang an den passenden ScheduleEntryControl.

Meine erste Idee war so etwas zu machen:

for (ScheduleEntryControl control : context.getTask().getScheduleEntry().getRunningEntries()) {

    if (control.getScheduleEntry().equals(context.getTask().getScheduleEntry())) {

        control.stopExecution();

    }

}

Leider liefert mir die .equals Abfrage false, auch wenn gerade nur eine Instanz des ScheduleEntrys läuft, die beiden Rückgabewerte also "equals" sein müssen.

Habt ihr einen Tipp, wie ich aus einem laufenden Modul heraus ermitteln kann welche Instanz ich gefahrlos abbrechen kann, ohne ausversehen evtl. andere laufende Instanzen zu beenden?

Das ganze möchte ich mit FS5.1 und FS5.0 machen.

Grüße

Sandro

0 Kudos
1 Solution

Accepted Solutions

Hallo Sandro,

Du könntest im Modul eine Property des ScheduleContext setzen - context.setProperty(...). Ein nachgelagertes Skript im Auftrag liest dann diese Property aus und bricht abhängig vom Wert dann nicht den kompletten Auftrag ab, sondern deaktiviert die nachfolgenden Tasks (entfernt quasi den vorderen Haken). Das Ergebnis sollte aber dasselbe sein. Ich bin mir jetzt nicht 100%ig sicher ob sich das Deaktivieren wirklich nur auf die aktuelle Instanz auswirkt, ich meine aber schon.

Viele Grüße

Michael

View solution in original post

0 Kudos
5 Replies
pavone
I'm new here

Hallo Sandro,

eine Alternative wäre bei allen Tasks, die nach deiner Excecutable ausgeführt werden, einfach den Haken bei "Auch im Fehlerfall ausführen" zu entfernen. Ist natürlich nicht ganz so komfortabel wie das Abbrechen aus dem Modul heraus...

Gruß

Tim

0 Kudos

Hallo Tim,

diese Idee hatte ich auch schon, aber leider geht das nicht. Nach meinen Erfahrungen werden Tasks, bei denen der Haken "Auch im Fehlerfall ausführen" entfernt ist nicht ausgeführt, egal in welchem Vorgelagerten Task ein Fehler aufgetreten ist.

Vor dem Task der mein Modul aufruft, sind noch ein Generate-Task und evtl. andere Tasks. Diese können trotz Fehler korrekt ausgeführt worden sein.

Wenn ich den Haken "Auch im Fehlerfall ausführen" bei den Tasks die nach meinem Modul kommen entferne, werden diese nicht ausgeführt, wenn z.B. der Generate-Task Fehler enthielt, aber mein Modul keinen Fehler geworfen hat.

Die Nachgelagerten Tasks sollen nur dann nicht ausgeführt werden, wenn mein Modul einen Fehler wirft.

Gibt es noch eine andere Möglichkeit bei einer eventuellen parallelen Ausführung die richtige Instanz des Schedules zu identifizieren?

Grüße

Sandro

0 Kudos

Hallo Sandro,

Du könntest im Modul eine Property des ScheduleContext setzen - context.setProperty(...). Ein nachgelagertes Skript im Auftrag liest dann diese Property aus und bricht abhängig vom Wert dann nicht den kompletten Auftrag ab, sondern deaktiviert die nachfolgenden Tasks (entfernt quasi den vorderen Haken). Das Ergebnis sollte aber dasselbe sein. Ich bin mir jetzt nicht 100%ig sicher ob sich das Deaktivieren wirklich nur auf die aktuelle Instanz auswirkt, ich meine aber schon.

Viele Grüße

Michael

0 Kudos

Hallo Michael,

vielen Dank für die Antwort. So hat es funktioniert!

Man muss allerdings nicht einmal über eine Propertie im Context gehen, sondern kann direkt alles im Code des Moduls machen.

Hier meine Lösung:

private void stopScheduleEntry() {

        ScheduleTask actualRunningTask = serviceConfiguration.getContext().getTask();

        List<ScheduleEntryControl> runningEntries = actualRunningTask.getScheduleEntry().getRunningEntries();

        if (runningEntries.size() == 1) {

            ScheduleEntryControl scheduleEntryControl = runningEntries.get(0);

            scheduleEntryControl.stopExecution();

            Logging.logError(String.format("Execution '%d' of ScheduleEntry '%d' was cancelled.",

                    scheduleEntryControl.getId(), scheduleEntryControl.getScheduleEntry().getId()), LOGGER);

        } else {

            for (ScheduleTask scheduleTask : serviceConfiguration.getContext().getTasks()) {

                scheduleTask.setActive(false);

            }

            Logging.logError(

                    String.format(

                            "There was more than one parallel execution instance of ScheduleEntry '%d'. All tasks of the current instance were set inactive so the wont be executed.",

                            actualRunningTask.getScheduleEntry().getId()), LOGGER);

        }

    }

Danke und Grüße

Sandro

0 Kudos

Hallo Sandro,

klar kannst Du das auch direkt aus dem Modul machen. Damit hättest Du aber eine Abhängigkeit drin. Vom Design her schöner wäre meiner Meinung nach, wenn das Modul nur seinen Status "weitergibt" und die Entscheidung, welche Tasks dadurch dann deaktiviert werden im Auftrag selber getroffen wird. Falls Du ggf. doch mal einen Task (z.B. Mail schicken usw...) auführen willst, müsstest Du dann das Modul nicht anpassen.

Viele Grüße

Michael

0 Kudos