Questions & Answers

[gerhajns]

Hallo Community,

ich habe ein kleines Spezialproblem im Verständnis des Beanshell Members "context" bei der Nutzung in Script-Task eines Auftrages.

Ich habe einen Auftrag mit zwei aufeinanderfolgenden Scripttasks:

Script Task 1:

//!Beanshell

context.setProperty("myKey","myValue");

Script Task 2:

variable = context.getProperty("myKey","myValue");

Welchen Gültigkeitsbereich hat der Member "context"? Ich vermute ich bin hier im SchedulerContext, ist der serverweit oder nur für den gerade laufenden Auftrag gültig? Hintergrund: Ich habe ca. 70 Projekte auf einem Server, welche den Konstrukt nutzen sollen.

Danke.

Viele Grüße

Jens Gerhard

[bIT_sosswald · Accepted solution]

Hallo Herr Gerhard,

der Context innerhalb eines Schedule-Entry, ist meines Wissens nach auch nur während der Ausführung gültig und müsste vom Typ "ScheduleContext" sein, zu dem die JavaDoc folgendes sagt:

A context with access to schedule entry execution-related objects.

D.h. die verschiedenen Projekte auf Ihrem Server sollten sich die Property mit dem Key "myKey" nicht gegenseitig überschreiben.

Ein kurzer Test hat zumindest gezeigt, dass eine in Skript1 gesetzte Variable bei erneuter Ausführung des gesamten Schedule-Entry nicht mehr gesetzt war. D.h. sie lebte nur solange der Schedule-Entry ausgeführt wurde.

Beste Grüße

Sandro Osswald

[mikula]

Hallo Jens,

benötigst Du noch weitere Hilfe oder haben Dir die Antworten von Sandro 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

[gerhajns]

Hallo Martin,

danke der Nachfrage, die Antwort habe ich als richtig markiert. Der betreffende Member bezieht sich in dem Moment nur auf den Auftrag und somit überschreiben sich die Aufträge die Variablen nicht.

Viele Grüße

Jens

[mbergmann]

Hallo Jens,

der Vollständigkeit halber: Falls man doch einmal persistente Werte braucht, geht das mit

context.setVariable(...);

Der entsprechende Wert wird dann im Auftrag gespeichert und steht bei weiteren Aufrufen per getVariable(...) zur Verfügung - so merkt sich z.B. die Delta-Generierung den Zeitpunkt (genauer: die Revision) ihrer letzten Ausführung. Hier sollten allerdings nur einfache Typen und keine Objekte eigener Klassen benutzt werden, weil das nach einem Modul-Update ggf. zu Deserialisierungs-Problemen führen kann.

Viele Grüße

Michael