Remote Debugging einer Executable Klasse in einem Auftrag

[boei006]

Hallo zusammen,

ich bin noch sehr neu im FS Bereich und versuche gerade eine Executable Klasse zu debuggen, welche innerhalb eines Auftragen als Aktion aufgerufen wird. Für die Entwicklung nutze ich IntelliJ.

Der Beitrag Remote-Debugging ItelliJ Idea​ hat mir schon sehr weiter geholfen, sodass ich andere Teile mit dem Debug-SA debuggen kann, allerdings greift der Debugger nicht innerhalb der zu debuggenden Executable Klasse.

Ich würde gerne wissen, wie genau ich vorgehen muss und wieso genau das Ganze außerhalb des Debug-SA stattfindet. Ich befürchte, dass es etwas mit dem Verlauf der einzelnen Aufrufe zu tun hat ehe die Aktion selbst ausgeführt wird. Aktuell findet folgende Kettenreaktion statt:

1. Arbeitsablauf wird im SA gestartet

2. Skript wird aufgerufen, dass eine Executable Klasse aufruft

3. Die Executable Klasse stößt den Auftrag an

4. Der Auftrag führt verschiedene Aktionen aus bis

5. Die Executable Klasse aufgerufen wird, die bedebuggt werden soll

[bIT_sosswald]

Hallo Björn,

Executables werden meines Wissens nach "da ausgeführt, wo sie aufgerufen werden". D.h. wenn du im SiteArchitect ein Executable ausführst, läuft es im SIteArchitect. Daher kommst du mit dem Debugging des Servers nicht weiter, sondern du musst den Client debuggen.

Schau mal in diesem Thread: Re: Remote Debug Client mit IntelliJ

Beste Grüße
Sandro

[boei006]

Hallo Sandro,

vielen Dank erstmal für deine wirklich schnelle Antwort.

Ich habe mich in den Artikel den du verlinkt hast mal eingelesen und in der Hinsicht weiter herumprobiert. Ich glaube, dass ich etwas dazu gelernt habe und vorher etwas falsch verstanden habe:

1. Starte ich mein Projekt mit den Debug Parameter (-Dhost, -Dmode, etc.), dann öffnet sich der SA und so würde ich den Server debuggen.

2. Da die Vermutung ist, dass die Executables nicht auf dem Server sondern im SA ausgeführt werden, muss ich den SA debuggen. Also einen Debug-Prozess an den SA attachen (Run-Config vom Typ Remote).

Verstehe ich die beiden Punkte richtig?

Ich habe mir dazu noch den Beitrag Remote Debugging über FS_Button... angeschaut, um den SA mit den Debug Optionen zu starten. Das ist das Gleiche, als wenn ich die Einträge in der "fs-wrapper.include.conf" hinzufügen würde, oder?

Per Console konnte ich einen SA mit Debug Optionen starten und dann in IntelliJ einen Debugger attachen. Allerdings werden weiterhin nur die Breakpoints aus der ersten Executable getroffen und nicht die der Klasse, die das eigentliche Ziel ist.

Verstehe ich etwas falsch bzw. gibt es weitere Ideen woran es liegen kann?

Edit:

Ich habe es anscheinend genau falsch herum verstanden, was im Nachhinein auch viel mehr Sinn ergibt.

Um den Server zu debuggen muss ich in der "fs-wrapper.include.conf" die Debug Parameter eintragen und dann kann ich per "Remote" Run-Config in IntelliJ mich an den Serverprozess anhängen.

Um den Client zu debuggen muss ich eine "Application" Run-Config anlegen, in der ich die Parameter aus diesem Beitrag Remote-Debugging ItelliJ Idea​ eintrage.

In meinem Fall wird vom SA aus die Aufträge auf Serverseite angestoßen, sodass auch meine Executables serverseitig laufen. Demnach muss ich den Server im Debugmodus starten und kann dann mit dem Debug-Prozess in IntelliJ debuggen.

Dadurch bin ich auch gezwungen für jede Änderung an meinem Modul dieses neu auf dem Server zu installieren, sehe ich das richtig?

[mbergmann · Accepted solution]

Hallo Björn,

ja, das stimmt. Da Aufträge immer auf dem Server laufen, musst Du dafür immer das Modul installieren. Dafür gibt es allerdings auch entsprechende API oder auch das fs-cli.

Falls es eine komplexere Executable ist, wo das zum testen oft nötig ist wäre noch eine Alternative sie entweder direkt aus der IDE zu starten (mit einem Verbindungsaufbau per ConnectionManager drum herum) oder doch im SA. Das funktioniert aber natürlich nur wenn sie von der Funktionalität nicht grundsätzlich davon abhängig ist innerhalb eines Auftrages zu laufen, insbesondere keine ScheduleContext-spezifischen Methoden braucht.

Viele Grüße

Michael