Deutsch

Hintergrund Sagede.Shared.ReportViewerControl.ReportViewerViewModel

Korrekte Verwendung der "PrintReport"-Methode - Parameter "isInitial"

Wann sollte "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" überhaupt eingesetzt werden?

Alternative: Serverseitiger Druck

Idealer Weg

Deutsch

Hintergrund

Beim Auslösen von Ausdrucken von AppDesigner-Berichten (Basis StimulSoft-Reports) aus eigenem .net-Code sollte man sich genau bewusst machen , in welchem Kontext dies stattfindet.

Je nach Kontext ist eine unterschiedliche Herangehensweise sinnvoll.

Sagede.Shared.ReportViewerControl.ReportViewerViewModel

Sehr häufig findet man in der Praxis Quellcode von Kunden oder Techpartnern bzw. Fachhändlern , die mit der Sage Klasse "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" arbeiten.

Diese Klasse hat "es in sich" und birgt viele "Stolperfallen" und es können teilweise zur Laufzeit "merkwürdige" Fehlermeldungen ausgelöst werden.

Häufige Probleme dieser Klasse werden im nachfolgenden Artikel näher erläutert.

Korrekte Verwendung der "PrintReport"-Methode - Parameter "isInitial"

Sage hat im Zusammenhang mit der Klasse "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" in Developer Vorträgen mehrfach darauf hingewiesen , dass diese Methode einen wichtigen Parameter namens "isInitial" bietet , der auf "true" gestellt sein muss.

⚠️Problematisch ist in diesem Zusammenhang , dass der besagte bool Parameter "isInitial" von Sage als "Nullable" deklariert wurde und auch keinen Default im internen Sage Quellcode gesetzt hat.⚠️

Wann sollte "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" überhaupt eingesetzt werden?

Dieses Control ist aus unserer Sicht ausschließlich relevant , wenn ein Druck z.B. aus einer separat laufenden , eigenen Stand-Alone-Anwendung heraus durchgeführt wird.

Innerhalb eines Dienstes sollte man diese Klasse nicht verwenden!

Wir würden inzwischen empfehlen , mit den neueren Sage 100 Versionen , grundsätzlich auf die Verwendung der o.g. Klasse zu verzichten und stattdessen über SDATA REST z.B. einen Code im Applikationsserver auszulösen , der dann mit serverseitigen Sage Methoden den Druck auslöst.

Alternative: Serverseitiger Druck

Sobald man Quellcode hat , der auf der Serverseite innerhalb eines Sage Applikationsserver ISO-Prozesses ausgeführt wird , empfiehlt sich für den Druck ein anderer Ansatz.

Nachfolgend ein Beispiel , welches den wesentlichen Code zeigt.

Dieser Code verwendet stattdessen die Klasse "Sagede.Shared.ReportingEngine.ReportEngine" und die dortige Methode "ExecuteReport".

Idealer Weg

Man kann auch aus z.B. eigenen EXE-Dateien , die mit dem Sage Mandantenobjekt arbeiten oder auf andere Weise eine Datenbankverbindung zur Sage 100-Datenbank herstellen , mittels .net über das SDATA REST-Protokoll relativ einfach Code im Sage Applikationsserver auslösen.

Sage bietet Funktionen , um dann die auf dem Server generierte Berichtsdatei , z.B. PDF , mittels Sage Blob-Storage Server im eigenen Code dann herunterzuladen.

Dieser Ansatz würde der 3-Tier-Architektur der Sage 100 folgen und vermeidet unnötigen Overhead und unnötige Belastungen für den Sage Applikationsserver, da die o.g. Klasse "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" einen starken Overhead beinhaltet , der bei sehr vielen Ausdrucken hintereinander den Sage Applikationsserver massiv belastet‼️

Dies sollte man daher bei der Anwendungsentwicklung entsprechend berücksichtigen!