- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Scripting: ScheduleContext und Properties
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
- Labels:
-
Developers
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

