Skip to main content

Scripting: ScheduleContext und Properties

Comments

4 comments

  • Zendesk API User
    Author: bIT_sosswald - 1/14/2016 13:36

    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
  • Zendesk API User
    Author: mikula - 1/21/2016 9:06

    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
  • Zendesk API User
    Author: gerhajns - 1/21/2016 14:59

    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
  • Zendesk API User
    Author: mbergmann - 1/24/2016 12:40

    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

Please sign in to leave a comment.