Deutsch

"Falsche" Sage Dienst Konfiguration

Zu wenige Applikationsserver und falsche Konfiguration der Applikationsserver

Richtige Vorgabe der Rolle weiterer Applikationsserver

Inadäquate Konfigurationseinstellungen der Applikationsserver

Noch SOAP in Verwendung?

Deutsch

"Falsche" Sage Dienst Konfiguration

Einige Sage Komponenten sind nicht direkt für die Ausführung innerhalb von Windows Diensten ausgelegt.

Ein gutes Beispiel dafür ist das Reporting-Control von Sage, eine Sammlung von .net-DLL-Dateien, die auf der Basis der Software "StimulSoft", diverse Funktionalitäten für das Rendern und letzten Endes Drucken von Berichten in der Sage 100 bereitstellen, z.B das "Sagede.Shared.ReportViewerControl.ReportViewerViewModel" und Methoden darin wie "PrintReport" von Sage.

Dabei verwendet Sage zahlreichen Code aus dem WinForms-Namespace u.a. , der laut Microsoft nicht für die Ausführung innerhalb von Windows Diensten geeignet ist.

Allgemein sind die Bibliotheken von Sage für das Drucken recht "ressourcenhungrig", was bei der Ausführung innerhalb von Windows Diensten mit dem Konto "Lokales System" bzw. "localsystem" irgendwann zu Speicherproblemen des Desktop Heap Speichers führen kann. Abgesehen davon, dass "local system" auch nicht immer unbedingt alle notwendigen Rechte besitzt.

Typische Fehlermeldungen der Sage 100 in der Oberfläche und auch im Sage TraceLog sind dann Hinweise auf "System.OutOfMemoryException":

Alternativ können auch andere Fehlermeldungen im TraceLog erscheinen. Nachfolgend einige Beispiele für Fehlermeldungen, die auch die Rechteproblematik noch einmal verdeutlichen.

Sage ruft in der Methode "Sagede.Shared.ReportViewerControl.WpfPrintUtils.GetPrintTickets" die .net-Framework-Klasse "PrintTicket" auf, um Druckerinfos zu ermitteln.

Je nach vorhandener Laufzeitumgebung unter Windows gibt es für das "Lokale Systemkonto" (localsystem) im Sage Dienst dann ein Zugriffsproblem beim Abfragen dieser Druckereigenschaften.

Siehe:

Microsoft .net-API-Doku zu "PrintTicket".

Deutlicher Hinweis von Microsoft dazu:

Lösungsansatz 1

Der Schalter "Interaktion mit Desktop zulassen" bzw. "Datenaustausch zwischen Dienst und Desktop" zulassen erhöht den Desktop Heap Speicher etwas, adressiert aber nicht das Berechtigungsproblem.

Lösungsansatz 2

Alle Sage Dienste mit "echten" Benutzern als Dienstkonto konfigurieren. Für jeden Sage Dienst einen eigenen Benutzer verwenden/einrichten!

Dies ist auch der von Sage favorisierte Weg.

Zitat Sage:

Dabei ist es wichtig, dass das Einsetzen als Teil des Betriebssystems und das Anmelden als Dienst berücksichtigt wird.

Zu wenige Applikationsserver und falsche Konfiguration der Applikationsserver

Als sehr häufiges Problem in der Praxis erweisen sich Installationen, bei denen zu viele Dienste und Funktionen auf einer Maschine ausgeführt werden.

Eigentlich sollte klar sein: Für Sage 100 Installationen gilt sehr schnell, dass Anwendungsserver, Applikationsserver und SQL-Server unbedingt getrennt und niemals auf einer Maschine gemeinsam installiert gehören (Ausnahmen bestätigen die Regel!).

Weitere Applikationsserver ab einer bestimmten Benutzeranzahl zwingend notwendig

Was in der Praxis jedoch häufig vernachlässigt wird, ist die Tatsache, dass einer bestimmten Anzahl von Benutzern die Konfiguration der Applikationsserver zwingend angepasst gehört und dass ab einer bestimmten Benutzeranzahl auch ein zweiter (oder weitere) Applikationsserver zwingend notwendig werden!

Zitat Sage:

Unsere eigenen Erfahrungen in größeren Kundeninstallationen bestätigen dies 100%.

Die Installation eines weiteren Applikationsservers ist mit den aktuellen Sage 100 Versionen recht einfach. Nach der Installation ist es allerdings wichtig, die Datei "STS_AS_Config.dat" vom Haupt-Applikationsserver in das Installationsverzeichnis der zusätzlichen Applikationsserver zu kopieren.

Außerdem muss man daran denken, mit Administrator-Rechten die Registrierungsinformationen in den neuen Applikationsserver zu importieren. Dafür kann nachfolgende Befehlszeile verwendet werden.

ASADMIN.EXE /command:stsconfig /action:importregistration /file:STS_AS_Config.dat

Richtige Vorgabe der Rolle weiterer Applikationsserver

Häufig wird vergessen , dass neu hinzugefügte Applikationsserver bezüglich ihrer Rolle deklariert werden sollten.

Die Sage Dokumentation dazu ist eindeutig.

⚠️Das Load Balancing von Sage für die Applikationsserver folgt dabei einem simplen Muster und ist kein(!) echtes Load Balancing im Sinne einer Live-Auswertung der Auslastung aller Applikationsserver und Zuweisung nach Last!

In der Praxis ist dies eine der häufigsten Missverständnisse.

Sage folgt der Strategie , dass einem Benutzer möglichst immer derselbe Isolations Prozess desselben Applikationsservers für denselben Mandanten zugewiesen wird.

Ein Isolationsprozess ist prinzipiell für einen Mandanten zuständig , da das Mandantenobjekt "teuer" ist. Jeder Benutzer hat somit im Grunde für jeden Mandant seinen eigenen reservierten Isolationsprozess und die Freigabe der Prozesse erfolgt gemäß der Sage Parameter für den Applikationsserver.

Die Zuweisung der Rolle des Applikationsservers ist somit wichtig und wird durch das sogenannte "CapabilityFlag" gesteuert (Bit-Array, es können somit mehrere Flags/Bits gesetzt werden).

⚠️Beachten sollte man , dass die Flags/Bits 4 und 8 aktuell (2026) von Sage in keinem automatischen Load Balancing berücksichtigt werden und von Sage für zukünftige Erweiterungen vorgesehen sind.

<applicationEnvironment applicationContextFactory="Sagede.ApplicationServer.OfficeLine.ApplicationDriver, Sagede.ApplicationServer50.OfficeLine.Driver, Version=          , Culture=neutral, PublicKeyToken=null" applicationBinaryPath="C:\Program Files (x86)\Sage\Office Line\xxx\Shared" capability="-1" />

Inadäquate Konfigurationseinstellungen der Applikationsserver

Sehr häufig finden sich in der Praxis falsch installierte i.S.v. "falsch konfigurierte" Applikationsserver, die in keinster Weise den Anforderungen des Kunden gerecht werden.

In der Konfigurationsdatei der Applikationsserver sollten sowohl die synchronen als auch asynchronen Einstellungen kritisch geprüft werden.

Sage liefert eine Basis-Konfigurationsdatei für den Applikationsserver aus, in der alle wesentlichen Einstellungen kommentiert sind.

Wesentliche Eckpunkte sind:

Max. Anzahl von Isolationsräumen

Definiert die maximale Anzahl von Isolationsräumen (Summe aktiver, inaktiver und im Pool befindlicher Isolationsräume).

Timeout Isolationsraum

Schafft es der Applikationsserver nicht innerhalb dieses Zeitfensters einen Isolationsraum zu finden oder zu erzeugen, wird ein Fehler ausgelöst und im Protokoll ausgegeben.

Initiale Größe des Pools

Gibt die Anzahl der Isolationsräume an, die beim Start des Applikationsservers erzeugt und vorgeladen werden.

Mindestgröße des Pools

Wird dieser Wert durch die Entnahme eines Isolationsraums unterschritten, wird der Pool automatisch wieder auf diesen Wert erhöht.

Maximalgröße des Pools

Definiert die Obergrenze an Isolationsräumen.

Ist der Wert überschritten, werden "abgeräumte" Isolationsräume komplett aus dem System entfernt.

Für einen unserer Kunden, bei dem circa 20-25 Benutzer gleichzeitig/parallel in der Sage 100 arbeiten, hat sich nachfolgende Konfiguration bewährt.

Auszüge Synchrone Isolationsräume:

  <lifetimeManager serviceDomainPollTime="00:01:00" />
  <serviceDomain lifeTimeLeaseTime="04:00:00" lifetimeRenewOnCalltime="04:00:00"
   isolationModel="process" poolInitialSize="20" poolMaxSize="40"
   poolMinSize="2" maxElasticCount="0" contextQuotaMax="4" contextSwitchLevel="2" />

Die Domain-Memory-Größen wurden gegenüber dem Standard leicht herabgesetzt:

<asyncIsolationServer synchronizeContextSwitch="false" synchronizeContextSwitchTimeout="00:00:01"
  maxActiveServiceDomains="0" serviceDomainSynchronizationLockTimeout="00:00:01.5000000"
  maxUseServiceDomains="100" maxServiceDomainMemorySize="150000"

Auszüge Asynchrone Isolationsräume:

Die Werte "lifeTimeLeaseTime" , "lifeTimeRenewOnCalltime", "contextQuotaMax",  

"poolInitialSize" und "poolMaxSize" haben wir für die asynchronen Isolationsräume auf Standard belassen.

<lifetimeManager serviceDomainPollTime="00:01:00" />

  <serviceDomain lifeTimeLeaseTime="04:00:00" lifetimeRenewOnCalltime="04:00:00"

   isolationModel="process" poolInitialSize="5" poolMaxSize="5"

   poolMinSize="1" maxElasticCount="5" contextQuotaMax="4" contextSwitchLevel="2" />
...
</asyncIsolationServer>

Hinweis aus Sage Erklärungen zur Verdopplung des "contextQuotaMax" Werts:

Noch SOAP in Verwendung?

Sofern noch SOAP-Services aktiv implementiert sind und genutzt werden, muss man darauf achten, auch für diese SOAP-Services die korrekten Einstellungen in der Konfigurationsdatei der Applikationsserver vorzunehmen!

Sonst laufen die SOAP-Services mit den Default-Einstellungen, die eben kontraproduktiv sein können!