Allgemeine Informationen zu sM-Client R5.0.7: Die publizierte
Werbung
Allgemeine Informationen zu sM-Client R5.0.7: Die publizierte Version 5.0.7 enthält einen Nachbearbeitungsprozess, um liegen gebliebene Meldungen nochmals zu verschicken bzw. zu empfangen. Meldungen, welche während einer bestimmten Zeitspanne im Status „message-handler-validate message“ oder „message-handler await validation“ hängengeblieben sind, werden als „stuck messages“ betrachtet. Das Timeout unterscheidet sich für kleine Meldungen (Grösse < 1MB) und grosse Meldungen (Grösse > 1MB). Die Grösse der Meldungen und der beiden Timeouts werden in globalconfig.properties mit den Parametern stuck.retry.small.msg.size, stuck.retry.time.offset.minutes, und stuck.retry.big.msg.minutes konfiguriert (Standardwerte, also ohne zusätzliche Konfiguration, sind 1048576, 60 bzw. 720; das entspricht 1 MB, 60 Minuten und 720 Minuten (=12h)). Zusätzlich gibt es noch einen Parameter namens stuck.job.interval.minutes (default Werte, 60min), welcher beschreibt, nach welchem Intervall liegen gebliebene Meldungen gesucht werden. Diese vorkonfigurierten Default-Werte sollten nur unter besonderen Umständen und in Absprache mit dem sM-Client-Support geändert werden. Die Konfiguration muss also diesbezüglich nicht angepasst werden. Mit dem „StuckMessageDetector“ werden die liegengebliebenen Meldungen jeweils noch einmal versendet/empfangen. Zusätzlich beschränken wir die maximale Anzahl von Verarbeitungsversuchen, um zu vermeiden, dass Meldungen in einen unendlichen Loop gelangen. Die maximale Anzahl von Versuchen ist in global-config.properties mit dem Parameter stuck.retry.max.amount konfigurierbar und wird per Default auf den Wert 2 gesetzt. Wenn eine Meldung die maximale Anzahl von Versuchen erreicht, wird der entsprechende Error geloggt; die Meldung bleibt in diesem Fall im TempVerzeichnis liegen. Eine weitere namentliche Verbesserung dieser Version betrifft das Verhalten beim Herunterfahren des sMClients: die Meldungen werden nicht mehr ins failed-Verzeichnis verschoben, falls ein graceful Shutdown während der Meldungsvalidierung oder der PDF-Generierung gemacht wird. Die Meldung wird in diesem Fall intern als „Reprocess due to shutdown“ markiert und nach dem erneuten Starten des sM-Clients wieder weiter verarbeitet (dabei wird beim Herunterfahren die Exception: „org.jbpm.JbpmException: JbpmConfiguration(jbpm.cfg.xml) is closed“ geloggt). Um sicher zu sein sollte der sM-Client während des Herunterfahrens keine neuen Meldungen zum Senden oder Empfangen erhalten. Ansonsten besteht die Gefahr, dass in Einzelfällen Meldungen ohne Audit-Trail-Eintrag (und ohne aussagekräftigen Error im Log) im TempFolder liegen bleiben. Dieses Verhalten wird in einer folgenden Version verbessert. Wir empfehlen dazu, dass zuerst JBoss abgeschaltet wird und danach HornetQ. Bei Ausfall der Datenbank versucht JBoss die Verbindung wieder herzustellen (siehe unten unter Empfohlene Konfiguration). Change Log R5.0.7.5: CHANGED: Nachbearbeitungsprozess: Die Meldungen, die in Status "message-handler-validate message" und "message-handler await validation" liegengeblieben haben, werden nochmals versendet/empfangen. o Die Timeouts werden in global-config.properties mit den Parameters stuck.retry.time.offset.minutes und stuck.retry.big.msg.minutes konfiguriert (Standardwerte sind 60 bzw. 720, also 60min und 720min (=12h)). o Die Suchfrequenz nach liegengebliebenen Meldungen wird durch den Parameter stuck.job.interval.minutes (Default 60min) konfiguriert. o Die maximale Anzahl neuer Versuche ist im File global-config.properties durch den Parameter stuck.retry.max.amount (Default 2mal) konfigurierbar. CHANGED: Update JBPM Version auf 3.2.14. CHANGED: Entfernen alter Workarounds von R5.0.4. (nicht relevant für die Benutzer). CHANGED: Empfang von Sammelmeldungen mit ungültigen oder invaliden Einzelmeldungen (ech0058v4). Die ungültigen oder invaliden Einzelmeldungen bleiben in der ZIP-Datei mit einer error.xml Datei und werden in den Failed-Ordner geschrieben. Ebenso wird mit invaliden ZIP-Dateien verfahren (ohne error.xml). CHANGED: StuckMessageDetector startet per Default 2h nachdem der sM-Client gestartet ist. CHANGED: Keine Überbleibsel im Temp-Ordner nachdem Meldungen nochmals versendet/empfangen werden. CHANGED: Kein Memory Leak mehr mit Patch von Xalan (für XML Processing der grossen Meldungen). CHANGED: Zusätzliche Log-Informationen wurden hinzugefügt, Memory Informationen werden alle 2 Minuten geloggt, dazu werden nun in jedem Fall Informationen geloggt, wann welche Meldung wohin verschoben wird. CHANGED: SMCTESTING-376: Graceful shutdown während Meldungsverarbeitung. Das Problem ist wie oben beschrieben teilweise gelöst. FIXED:SMCSUPPORT-792: Triage ist möglich für ELM Test-Meldungen. FIXED: SMCSUPPORT-811: Grösse von ELM Meldungen wird jetzt korrekt abgefragt. FIXED: SMCSUPPORT-822: Für ELM Meldungen Name der PDF-Datei wie in Spezifikation, also bis auf die Endung gleich wie der Meldungs-File-Name. FIXED: SMCSUPPORT-847: eventDate wird als messageDate im Datenbank gespeichert, falls messageDate in der Meldung nicht verfügbar ist. FIXED: SMCSUPPORT-855: PDF-Generated Fehler. Auftreten des Fehler wird verhindert. Caveat: Meldungen welche sich beim Update in dem Status befinden, werden vom Nachbearbeitungsprozess nicht aufgeräumt. FIXED: SMCSUPPORT-869: Abhängigkeit zu EOReg Meldungen. FIXED: SMCSUPPORT-878: Fehler bei Erstellung des sedex-Umschlags. FIXED: SMCSUPPORT-883: sM-client DB-Error beim Empfang einer ELM Meldung. FIXED: SMCSUPPORT-894: PDF Generierung ELM mit Gemeinde-Splitting. FIXED: SMCTESTING-370: PDF-Generierung in ELM-Domain funktioniert nicht FIXED: SMCTESTING-373: Meldungen werden sequentiell bearbeitet und nur von einem Mandanten gleichzeitig zugegriffen. FIXED: Suche nach interner Meldungs-ID funktioniert nicht. (Caveat: Im Spezialfall, dass nach einer Meldung gesucht wird, die nicht eine eineindeutige Meldungs-ID hat, gibt es einen Fehler. Dies kann produktiv aber nicht vorkommen.) Empfohlene Konfiguration für JBoss-Server und Datenbank: Wichtig: Für die PDF-Generierung muss der JAVA_OPTS-Parameter -Dlog4j.configuration unbedingt gesetzt werden. Siehe SMCSUPPORT-757 2GB für MaxHeapSize und MinHeapSize für JBoss-Servers, um unnötiges Memory Swapping für Windows zu vermeiden. Das entspechende Konfigurationsfile ist in [JBoss Installationsverzeichnis]/bin/run.conf.bat zu finden. Ersetzen Sie die Zeile 43 als: set "JAVA_OPTS=-Xms2048M -Xmx2048M -XX:MaxPermSize=512M" innodb_lock_wait_timeout (konfiguriert in my.ini im MySQL Installationsverzeichnis ) sollte auf 150 erhöht werden (falls der Parameter nicht aufgeführt ist, muss er neu gesetzt werden). Um die Performance der Datenbank zu verbessern, liefern wir ein Skript um Indexes auf die jBPMTabellen zu erstellen. Ausführen des Aktualisierungsskripts (z.B. update-smclient-oracle.sql für Oracle) entsprechend der verwendeten Datenbank Im Falle von MySQL soll INNODB als Engine gesetzt sowie der Parameter validationQuery (Tomcat) oder <valid-connection-checker-class-name> (JBoss) auf dem Applikation Server konfiguriert werden, siehe Beispiel-Dateien unten. jms.sender.timeout.hours in message-handler-[domain].properties muss grösser als stuck.retry.big.msg.timeout im global-config.properties gesetzt werden. (ACHTUNG: jms.sender.timeout.hours ist im Stunden und stuck.retry.big.msg.timeout in Minuten gesetzt) Beispielkonfigurations-Files Beispiel [JBOSS_HOME]/server/default/deploy/smclient-ds.xml (JBoss 4.2.3 und 5.1 mit MySQL, mssql und oracle) smclient-mysql-ds.xml smclient-mssql-ds.xml smclient-oracle-ds.xml Beispiel CATALINA_HOME/config/CATALINA/localhost/ smclient.xml Datei für Tomcat (mit MySQL, siehe Kommentar für andere DBs) smclient.xml Auszug von standalone.xml <datasource> für EAP6.1 mit MySQL, mssql und oracle standalone-eap61-myssql-datasource.txt standalone-eap61-mssql-datasource.txt standalone-eap61-oracle-datasource.txt
