Nachdem sich der Skript-Entwickler per Chrome DevTools (CDT) mit dem Debugging Host verbunden hat, gibt es zwei Möglichkeiten, um das Skript im Debugger anzuhalten:
Das Skript SOFORT anhalten: In diesem Modus wird der Scriptcode vor der Ausführung der ersten Programmzeile angehalten.
Das Skript erst BEI BEDARF anhalten: Der Bedarf wird aus dem Skriptcode heraus per Breakpoint oder speziellem JS Kommando oder Befehlsaufruf aus der enaio®-seitigen Scripting-API signalisiert.
Der Schalter BreakOnStart legt fest, ob automatisch eine Verbindung zum Inspector hergestellt wird und automatisch ein Brechpunkt in der ersten Codezeile des Skripts gesetzt wird.
Speziell beim Serverjob krn.RunScript kann dies vom Aufrufer des Jobs per optionalem Jobparameter gesteuert werden.
InspectorBreakOnStart (Integer). Mögliche Werte sind hier:
0 (false) – Der Debugger hält das Skript nicht an der ersten Zeile des Skripts an. Die Verbindung zum CDT wird "On Demand" gestellt. Das Anhalten kann nun aus dem Skript heraus über Breakpoints sowie das Schlüsselwort debugger angehalten werden.
1 (true) – Der Debugger hält das Skript an der ersten Zeile an (sofort).
-1 (unknown) – Ob der Debugger das Skript am Start anhält, wird erst im späteren Verlauf entschieden.
Falls der Aufrufer das nicht entscheidet (unknown) – Dieser Modus gilt für alle Situationen außer krn.RunScript – dann wird die Konfiguration des entsprechenden Skripts in der oxv8.metadata.cfg ausgewertet. (Sektion = Skript-Name)
Auswertung des Parameters InspectorBreakOnStart = 0 (false) / 1 (true) / -1 (unknown)
Gilt bis hierher die Entscheidung unknown so wird der Wert aus oxv8.cfg\inspector\BreakOnStart genommen:
Auswertung des Parameters BreakOnStart = 0 (false) / 1 (true). Defaultwert ist false
In diesem Modus wird die Skriptausführung sofort nach Verbinden mit dem CDT an der ersten Zeile des Skripts angehalten.
Ob die Verbindung vom Inspector sofort bei der Skriptausführung aufgebaut werden, kann durch den Parameter ConnectOnStart mit dem Wert true an verschiedenen Stellen gesteuert werden. Dabei wird die Skriptausführung nicht ohne weiteres angehalten.
Speziell beim Serverjob krn.RunScript kann dies vom Aufrufer des Jobs per optionalem Jobparameter gesteuert werden.
InspectorConnectOnStart (integer).
Mögliche Werte sind hier:
0 (false) – Der Debugger hält das Skript nicht an der ersten Zeile des Skripts an. Die Verbindung zum CDT wird "On Demand" gestellt. Das Anhalten kann nun aus dem Skripte heraus über Breakpoints sowie das Schlüsselwort debugger angehalten werden.
1 (true) – Der Debugger hält das Skript an der ersten Zeile an (sofort).
-1 (unknown) – Ob der Debugger das Skript am Start anhält, wird erst im späteren Verlauf entschieden.
Falls der Aufrufer das nicht entscheidet (unknown) – Dieser Modus gilt für alle Situationen außer krn.RunScript – dann wird die Konfiguration des entsprechenden Skripts in der oxv8.metadata.cfg ausgewertet. (Sektion = Skript-Name)
Auswertung des Parameters InspectorConnectOnStart = 0 (false) / 1 (true) / -1 (unknown)
Gilt bis hierher die Entscheidung unknown so wird der Wert aus oxv8.cfg\inspector\ConnectOnStart genommen:
Auswertung des Parameters ConnectOnStart = 0 (false) / 1 (true). Defaultwert ist false.
In diesem Modus kann – direkt aus dem Skriptcode – ein Breakpoint über das JS-Schlüsselwort debugger oder den Befehl rc.inspector.breakPointHere(false) an einer beliebigen Stelle im Skript gesetzt werden und damit die Skriptausführung gezielt an dieser Stelle angehalten werden. Wird aus dem Skript heraus kein Breakpoint gesetzt, wird das Skript ohne Anzuhalten ausgeführt.
Falls weder die Parameter BreakOnStart noch ConnectOnStart gesetzt sind, kann trotzdem aus dem Skript heraus ein Breakpoint gesetzt und die Skriptausführung zum Anhalten gezwungen werden. Nötig ist in dieser Situation, dass der Inspector für diesen Event aktiviert wurde (entweder in oxv8.cfg oder in oxv8.metadata.cfg). Das wird über den Parameter Enabled (oder InspectorEnabled ) = 1 in einer der beiden Konfigurationsdateien erreicht. Im Skript können dann mit folgenden beiden API-Aufrufen das Anhalten des Skripts oder das Verbinden des Inspektors gesteuert werden:
Funktionsaufruf im Skript: rc.inspector.breakPointHere(true). Der Parameter besagt, ob die Verbindung zum CDT aufgebaut werden soll (falls dies vorher noch nicht geschehen ist). Damit kann der Skript-Entwickler im Code entscheiden, ob und wann der Inspector gestartet wird (z. B. im IndexDataChanged-Skript nur bei bestimmten Objekttyp etc.) und die Skriptausführung dediziert aus dem Code heraus zum Anhalten zwingen.
Falls der Inspector für das gegebene Skript ausgeschaltet ist, wird dieser Aufruf keine Auswirkungen haben.
Falls die Verbindung bereits aufgebaut und geschlossen wurde, oder falls der Versuch bereits mit Timeout erfolglos war, wird dieser Aufruf auch keine Auswirkungen haben. Der Aufruf gilt als "breakpoint", bei dem also die Ausführung des Skripts angehalten wird und CDT die Steuerung bekommt.
Funktionsaufruf im Skript: rc.inspector.connect(). Damit kann der Skript-Entwickler im Code entscheiden, ob und wann der Inspector gestartet wird (z. B. im IndexDataChanged-Skript nur bei bestimmten Objekttyp etc.).
Falls der Inspector für das gegebene Skript ausgeschaltet ist, wird dieser Aufruf keine Auswirkungen haben.
Falls die Verbindung bereits aufgebaut und geschlossen wurde, oder falls der Versuch bereits mit Timeout erfolglos war, wird dieser Aufruf ebenso keine Auswirkungen haben. In Gegensatz zum vorherigen API-Aufruf wird dabei kein "breakpoint" gesetzt. Brechpunkt zum Anhalten des Skripts können dann nachfolgend bspw. durch das JS-Schlüsselwort debugger erfolgen.
In diesem Modus erfolgt die Steuerung des Debuggings vollständig aus dem Skriptcode heraus, sofern der Inspektor für den entsprechenden Event angeschaltet ist.
debuggerJS hat das Schlüsselwort debugger. Über dieses Schlüsselwort kann der Skriptcode an einer beliebigen Stelle angehalten werden, wenn eine Verbindung zum Inspector hergestellt ist. Dieser JS-Befehl hat die gleiche Wirkung wie rc.inspector.breakPointHere(false).
Code
'use strict';
rc.console.log("script entry");
debugger;
rc.console.log("inspector enabled: " + rc.inspector.isEnabled());
rc.console.log("inspector connected: " + rc.inspector.isConnected()); |
Damit kann der Skript-Entwickler einen Brechpunkt programmatisch setzen. Allerdings hat dieses Schlüsselwort keine Auswirkung, wenn die Verbindung zu CDT nicht besteht. Möglichkeiten wie die Verbindung zum CDT programmatisch oder konfigurativ hergestellt werden können, sind in den obigen Ausführungen beschrieben.
Es kann manchmal notwendig sein, benachrichtigt zu werden, wenn ein Skript auf CDT wartet. Auf diese Weise kann der Skript-Entwickler innerhalb des Timeouts reagieren und eine entsprechende situationsbedingte Entscheidung zum Abbruch eines möglichen Debugggings direkt im Skript treffen.
Ist dies gewünscht, können folgende Schalter in der oxv8.cfg gesetzt werden:
CDTNotification – besagt, ob Notifications versendet werden (1) oder nicht (0)
CDTNotificationURL – URL um eine Notification zu versenden. Beispiel: 127.0.0.1:9193/v8/inspector. An dieser URL wird ein POST-Request mit JSON-Inhalt gesendet, der notwendige Daten enthält:
{"text":"oxv8 inspector: waiting for CDT","scriptName":"name des Skripts"} |
CDTNotificationFile – Name der bat-Datei, die bei einer entsprechenden Notification aufgerufen wird (Der Batchdatei wird dabei der Name des Skripts als Input-Parameter übergeben). In welcher Form die bat-Datei die Notification dann weiterverarbeitet und ggf. weiter sendet (net sen, Ton, E-Mail, Teams etc.) ist dem Skript-Entwickler überlassen. Beispiel der bat-Datei:
msg USER-NAME Waiting for CDT: %1 |