Questions & Answers

[mheiden]

Hallo!

Habe ich eine Möglichkeit aus dem Client per Script Daten an einen selbstgeschriebenen ScheduleTaskExecutor zu übergeben?

Beim ScriptTask geht das über die Parameter, der normale ScheduleTask bringt das aber nicht mit. Gibt es da einen Workaround?

Einfache getter/setter scheitern an der physischen Distanz zwischen Client und Server sowie fehlendem Zugriff auf die DTOs.

Vielen Dank für Ideen!

  Martin

[pavone]

Hallo Martin,

du möchtest also die Konfiguration deines speziellen Auftrages verändern, richtig?

Ich glaube der zweite Punkte in diesem Feature-Wunsch trifft genau deine Anforderung: Extend API for custom Schedule Tasks to create a custom Schedule Task via API

Bisher wurde das nicht umgesetzt, aber du kannst gerne dafür stimmen!

Dieser Beitrag hängt ebenfalls mit dem Feature-Wunsch zusammen: Re: Custom ScheduleTaskApplication im Auftrag per API anlegen

Falls der Punkt deine Anforderung nicht trifft, könntest du vielleicht ein paar Code-Schnipsel posten, um deinen Use-Case etwas deutlicher zu machen.

Viele Grüße

Tim

[mheiden · Accepted solution]

Hallo Tim,

das trifft es nicht ganz. Ich möchte lediglich meiner ScheduleTaskApplication bzw. dem dazugehörigen Executor aus dem Client heraus Parameter übergeben. Das ist etwas anderes als dynamisch Tasks anzulegen.

Bei unserer Generierung werden verschiedene Artefakte erzeugt, die später auf unterschiedliche Server deployed werden müssen. Ich möchte dem User gerne die Auswahl geben, welche Artefakte übertragen werden sollen. Mein Problem ist jetzt, dass ich diese Informationen aus dem Workflow-Script an meinen Custom ScheduleTask  übergeben muss. Es ist also eine andere Quelle als das ScheduleTaskData-Objekt für die Konfiguration des Tasks.

Beim ScriptTask kann ich das über die Methode setParameter(String, String) machen. Das klappt aber bei meinem Custom ScheduleTask nicht.

Ich habe aber gerade einen Workaround gefunden. Ich binde als ersten Step einen ScriptTask ein, dem die Daten übergeben werden können. Dieser wandelt den String in die gewünschte Datenstruktur um und legt die Daten im context ab (context.setVariable(String, Object)) über einen SettingsAgent kann ich dann in meinem custom ScheduleTask auf die Parameter zugreifen.

Das ist nicht schön, funktioniert aber erstmal.

Viele Grüße

  Martin

[mbergmann]

Hallo Martin,

etwas in der Richtung hätte ich auch vorgeschlagen.

Kleiner Hinweis: Wenn man hier Variablen nutzt (so wie du es mit setVariable machst) wird das im Auftrag persistiert. D.h. bei einem weiteren Lauf desselben Auftrages sind die Werte wieder verfügbar (wenn man sie nicht überschreibt / löscht). Für Deinen Anwendungsfall würde glaube ich besser setProperty passen. Je nachdem was Du da reinlegst (z.B. Objekte von eigenen Klassen) kann das nämlich auch zu Deserialisierungsproblemen bei einem Projektimport führen wenn inzwischen die Klasse (bzw. das Modul) upgedatet wurde und darum nicht mehr zur serialisierten Version passt.

Viele Grüße

Michael

[mheiden]

Hallo Michael!

Das hat gut geklappt, auch wenn ich etwas gesucht habe, bis ich rausgefunden hatte, dass man auf die Property über getVariable(name) des JobAgent zugreift. Die Namensgebung ist ein wenig verwirrend...

Hast Du auch einen Tipp für den Rückweg? Sprich das Ergebnis des ScheduleTask wieder an den Client zurück liefern? Ich würde dem User im Fehlerfall gerne das Log direkt im Client zur Ansicht bringen, um ihm den Umweg über den Monitor zu ersparen.

Viele Grüße

  Martin

[mbergmann]

Hallo Martin,

da Du ja Parameter übergibst startest Du den Auftrag ja per Script bzw. Executable. Du kannst hier auf das Ende des Auftrages warten lassen (awaitTermination). Wenn Du das nicht machst, läuft das Script im Client nach dem Start des Auftrages sofort weiter. Wenn Du also wartest, kannst Du Dir hinterher die Ergebnisse holen.

Ganz grob ungefähr so:

ScheduleEntry scheduleEntry = ...;
try {
    ScheduleEntryControl control = scheduleEntry.execute();
    control.awaitTermination();
    List<TaskResult> taskResults = control.getState().getTaskResults();
    for (TaskResult taskResult : taskResults) {
        //just to show the mechanism - simply read into a string
        InputStream logfile = taskResult.getLogfile();
        String log = Streams.toString(logfile, "UTF-8");//Not sure if it's really UTF-8 here.
    }
} catch (IOException | ScheduleEntryRunningException e) {
    e.printStackTrace();
} 

Das Ergebnis kannst Du dann mit den "üblichen Mitteln" anzeigen.

Viele Grüße

Michael

[mheiden]

Vielen Dank!

Ich war eine Stufe zu hoch und hatte daher die Details nicht mitbekommen.

Den try/catch-Block habe ich lieber in die Schleife gezogen, wel sonst die Ausgabe abbricht, wenn ein Task nicht ausgeführt wurde. (Dann gibt es auch kein Logfile und es fliegt eine FileNotFoundException.) Dann kann man die Log-Schnipsel prima per StringWriter zusammen ketten.

Viele Grüße

  Martin

[mbergmann]

Hallo Martin,

ja - das macht natürlich Sinn. Mir ging es hier nur um die "Aufrufkette" - darum die "Holzhammer-Methode" bzgl. des Exception-Handlings 😉

Viele Grüße

Michael