Questions & Answers

SOLVED
gerhajns
New Creator

Scripting: ScheduleContext und Properties

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
bIT_sosswald
Returning Responder

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

View solution in original post

0 Kudos
4 Replies
bIT_sosswald
Returning Responder

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

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

Type a product name