VonDoczuDoc.de

Hier nun Version 2 ohne Puffer-Ordner.

Aufgabe
Damit eAU wieder läuft: Plugins-Pfad automatisiert bereinigen.
Version 2 kommt ohne Auslagern dern .jar-Dateien daher und ist damit quasi updatefest (neue Ordner müssen manuell nachgetragen werden - sicher ist sicher).

Was macht die Batch-Datei?
1) Die Batchdatei killt die Java-Prozesse des CGM Communicator
2) Die Batchdatei entleert alle Ordner unterhalb \turbomed\programm\communicator\plugins
Das war´s auch schon.
An manchen Clients reicht´s einmalig. An anderen muss es alle paar Stunden passieren. Nun ja...

Anwendung:
TM beenden
Batchdatei "Als Administrator ausführen"
TM starten

Wichtig:
- Anpassung an eigene Laufwerke/Ordner erforderlich.
- Auf Terminalserver beachten, dass das Killen der Java-Prozesse dann alle angemeldeten Stationen einschließt, so dass dort jeweils TM zwar weiterläuft, aber für alles, was der Communicator so macht, unter Umständen die stationsbezogenen Communicator-Instanzen wieder zu starten sein werden (TM beenden, starten, fertig)

Haftung:
Schließe ich aus. Alles auf eigene Verantwortung.
Mir sind keine negativen Aspekte bekannt.


Hinweis zur eigenen Sicherheit: Die Batch ist "so" nicht direkt wirksam, um Schaden durch versehentliches Ausführen zu vermeiden.
Die beiden mit REM startenden Zeilen UNBEDINGT an den Arbeitsplatz bzw. RDP-Server anpassen und danach das REM entfernen.
Die pause-Anweisung am Ende kann auch entfernt werden. Sie dient nur der Funktionskontrolle...
PS: Hier befindet sich bewusst kein Dateianhang. Zum Einen blockieren moderne Browser und Virenscanner Download/Ausführung von BAT-Dateien aus gutem Grund. Zum Anderen ist ein gewisses Maß an Grundwissen obligatorisch. Und die Anpassung kann so nicht vergessen werden

Wie schlimm ist das denn?
Also nicht die Batch, die sicherlich Rettungsanker für Viele sein kann.
Sondern der Anlass: Ein hochbezahltes Unternehmen schafft es nicht, seine Produkte den Alltagserfordernissen entsprechend anzupassen??
Wenn dies ein Betriebsprogramm für Kernkraftwerke wäre, ließe sich ausmalen, wie die Zukunft aussähe ....

Respekt für die, die immer noch weiter machen mit diesem System ....

Und vor allem Respekt für Retter in der Not, Aufklärer und Wasauchimmer wie die zweitevierzig

W. Steuber hat geschrieben:Wie schlimm ist das denn?
Also nicht die Batch, die sicherlich Rettungsanker für Viele sein kann.
Sondern der Anlass: Ein hochbezahltes Unternehmen schafft es nicht, seine Produkte den Alltagserfordernissen entsprechend anzupassen??
Wenn dies ein Betriebsprogramm für Kernkraftwerke wäre, ließe sich ausmalen, wie die Zukunft aussähe ....

Respekt für die, die immer noch weiter machen mit diesem System ....

Und vor allem Respekt für Retter in der Not, Aufklärer und Wasauchimmer wie die zweitevierzig

Danke für die Blumen.
Der Aufwand ist überschaubar, und mit vielleicht 1 Stunde gezielter Programmierung wäre das ganze mit Abfrage der Registry für die Pfade, mit für RDP auch sitzungsbezogene Taskbeendigung (Java) und als signierter Installer mit Mini-GUI abzuliefern.
Wie lange hatte CGM nun dafür Zeit?!
Ach nee, die baden lieber in ihrem Geldspeicher mit dem Zufluss aus aus SWP für RKI-Zertifikate, Fremdkonnektor-Anbindungen und einem ePA-Zuschlag beim Zugangsdienst.

Zurück zur Batch: Leistet seit Wochen gute Dienste. Heute die letzte Praxis versorgt, ab morgen dann die neue Fassung für alle. Besonders in den Stoßzeiten sind die Unterbrechungen damit gut im Griff.



Zwar weicht es etwas vom Thema ab, aber so ein paar Erlebnisse der letzten Wochen lassen mich nun hart durchgreifen und Ernst machen. Zwischenstand:
- Zwei laufende Wechsel zu T2med, einer zu MedOff (Praxis mit zugeflogenen MFA, die es in- und auswendig kennen).
- Weitere sind sprungbereit.
- "Meine" Praxen, die ab 30.09.2023 noch mit einem CGM-PVS arbeiten (mit Ausnahme ALBIS und natürlich einigen Kolleginnen und Kollegen, die dem Ruhestand entgegensehen), dürfen sich einen neuen Servicedienstleister suchen. Und das wird schwer in unserer Region... zumindest wenn man zweistellige Stundensätze, freie Hardware-Wahl ohne "Doktoren-Aufschlag" sowie kreative/moderne Ansätze schätzen gelernt hat und unterbrechende Aktionen gern über Nacht erledigt sieht. Das sieht nur geschrieben so forsch aus - in diesen stressigen Zeiten sind (bisher) alle dankbar für diesen "Ruck". Und nach 30 Minuten Demo-Client ist das sowieso ein Selbstläufer.

Ziel: Stressbegrenzung/Fürsorge für mein Team, mich selbst, die vielen frustrierten MFA samt deren Brötchengebenden (scnr) und am Ende Wirtschaftlichkeit für alle. Kurz: Partnerschaftlich nach vorn schauen. Da habe ich es mit den 4 Viechern aus Bremen: "Etwas Besseres als den xyz finden wir überall." Für xyz kann eine beliebige Kombi aus drei Buchstaben eingesetzt werden, z.B. Tod oder WTF oder irgendwas mit C.

Neuester Tiefschlag: VPN-Zugangsdienst 12 Monate weiterzahlen, obwohl Konnektor unbrauchbar. Für ein anderes CGM-Programm kostet das Modul für Fremdkonnektoren gut 300 Euro netto und dann monatlich was bei 10 Euro. Also sponsore ich zum Dank die Datenkonvertierung zu T2med (bin frei, bekomme keine Sonderkonditionen) und behalte die Praxis in guter Betreuung. Letztlich gebe ich damit den Umsatz aus dem Mehraufwand für die CGM eAU zurück. Das sind mir meine geschätzten Praxen wert. Und noch mehr - aber das gehört hier nicht ins Forum

Auf einen kurzen Mittwoch - 42nd

Ich gebe hier ja nur ungern den "Party-Pooper", aber wenn ich mir o.g. Ordner ansehe, finden sich dort eigentlich nur Dateien, die seit dem letzten Update nicht mehr verändert wurden. Somit sehe ich nicht wirklich, daß hier primär das Problem sitzen soll. Der ganze skizzierte Vorgang wird schon zum gewünschten Ergebnis führen, aber wohl eher als eine Art "Sekundäreffekt".
Viel interssanter ist in diesem Zusammenhang eigentlich <TM-Pfad>\Daten\Var\aWinS\local\<Host- bzw. Clientname>, dessen Leerung (nach PC-Neustart bzw. Ab- und wieder Anmelden der Terminalsitzung -> "automatische" Bereinigung evtl. hängender Java-Prozesse) bis jetzt jedesmal zuverlässig die nach Absturz des eMuster-Centers auftauchende CGM-Connect-Nervmeldung wieder beseitigt hat.
Legt man nun besagten Ordner als Verknüpfung auf den Desktop oder dort eine Einzeiler-Batchdatei zur "EIn-Klick-Bereinigung" ab, kann der eigentliche "Reparaturvorgang" problemlos von jedem Benutzer selbst durchgeführt werden.

Den Inhalt von
<TM-Pfad>\Daten\Var\aWinS\local\<Host- bzw. Clientname>,
löschen klingt gut.
Müssen die Javaprozesse überhaupt vorher beendet werden?

Die betreffenden Java-Prozesse müssen beendet werden, weil sie auf die Dateien zugreifen.
Beim aWinS kommt wohl noch mindestens ein Prozess von CGM Assist hinzu. Denn beim Absturz kann TM diese Prozesse nicht beenden. Und selbst beim normalen Beenden bleibt CGM Assist manchmal offen.

@McLeod: Danke für diesen spannenden Tipp. Eine Ebene "höher" suchen, denn -> Interessant, wenn der andere Weg auch zum Ziel führt.

Am Ende sind Wirkung und Ergebnis beider Varianten meiner ersten Sichtung nach gleich ->

1) Die Batchdatei löscht unter plugins die stationsbezogenen (beim TS die globalen) Einstellungen des communicators, die beim Start von CGM Connect (vermutlich) aus der Datenbank heraus regeneriert werden.
Konkret werden ausschließlich die Dateien in den aufgeführten Unterordnern gelöscht. Die sind nicht seit dem Update unverändert, sondern werden im Betrieb sowohl gelesen als auch geschrieben (kleine SQlite und sowas, sind auslesbar). Die Ordnerstruktur und die .jar fasst die Version 2 nicht mehr an.

2) Das Löschen der Stationseinstellungen im CGM Assist (aWinS) führt zu... Neuaufbau der Einstellungen in aWinS und danach zum... Neuaufbau der Dateien in den Ordnern, die in der Batch aufgeführt sind.

Was sich daraus schließen lässt:
Die Ursache liegt in der Ebene /%$/&@ CGM ASSIST bzw. dessen Konfiguration, die während der Laufzeit zu Fehlern oder Hängern in den Dateien unterhalb plugins führt. Oder noch weiter oben.

Vermuten kann ich hier verbuggten Code oder "zu viele Kochende", denn was so ein Debug-Trace hergibt, ist schon eine Menge. Beim KIM-Clientmodul ist es ja ähnlich, aber das ist ein anderes Thema.
Auch vermute ich, dass CGM ASSIST für alles herhalten muss, weil alles nur noch dort entwickelt und per Schnittstelle an TM, ALBIS und Co. angebunden wird.

Seitenhieb auf ASSIST und CGM CONNECT: Lt. Beschreibung TURBOMED ist CGM CONNECT zu keinem Zeitpunkt zwingend erforderlich, sondern rein freiwillig. Ich würde sagen, dass es erforderlich IST. Allenfalls ist ein Konto (Praxiskonto, Arztkonto) nicht zwingend nötig.

ok, mit dieser Batch-Datei (wir habeen Nr1 angepasst) können wir das Problem beim Einlesen der Karten bei Neupatienten und neuen Karten einigermaßen lösen. Nach Absturz kann der Patient sofort wieder eingelesen werden.
(Es scheint ein Problem mit dem Länderkennzeichen zu geben, so wie es aussieht, es wird nach dem Absturz erneut abgefragt als Adressänderung.)
Die eAUs lassen sich dann auch wieder erstellen, wenn nach dem Versand der PC hängt. oder die DMPs u.s.w
P.S.: Mittlerweile können wir alle eAU auf eimal abschicken, nicht mehr portionsweise


Dennoch ist das, was hier von der Firma geboten wird, eine Zumutung

kurze Frage: Kann es sein, dass der Fehler "201" auch durch das gleiche Problem erzeugt wird.
Bei uns in der Praxis funktionierte die eAU für 1,5 Tage, seitdem kommt die Fehlermeldung, dass das Passwort nicht korrekt sei..

in der Datei: "KIMMailprotokoll" steht folgendes geschrieben:
03.01.2023 11:41:17|<PRAXISNAME>@tm.kim.telematik|erfolgreich|erfolgreich
03.01.2023 17:48:21|<PRAXISNAME>@tm.kim.telematik|fail|Exception when getting mails. Invalid password. The mail poller stopped.

Im "Communicator"Protokoll tauchen in dem Zeitraum folgende Infos auf:
2023-01-03 15:06:52,059 [DEBUG] [GMR] cgm.connect.connector.plugindb.RetryingDataSource - Retrying to establish a database connection, attempt no 7.
2023-01-03 15:06:54,061 [DEBUG] [VSJ] cgm.connect.connector.plugindb.RetryingDataSource - Database connection failed
java.sql.SQLException: Cannot create PoolableConnectionFactory (Verbindung ist unterbrochen: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831"
Connection is broken: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831" [90067-199])
at org.apache.commons.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:653) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.apache.commons.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:531) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:731) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at com.cgm.connect.connector.plugindb.AbstractDataSource.getConnection(AbstractDataSource.java:35) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.H2BasicDataSource.getConnection(H2BasicDataSource.java:29) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.RetryingDataSource.connectWithRetry(RetryingDataSource.java:76) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.RetryingDataSource.getConnection(RetryingDataSource.java:64) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugins.smartupdate.dao.LiquibaseUtil.updateDatabase(LiquibaseUtil.java:26) ~[SmartUpdate-core-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugins.smartupdate.SmartUpdatePlugin.init(SmartUpdatePlugin.java:147) ~[SmartUpdate-core-2.3.1.jar:2.3.1]
at com.cgm.connect.communicator.plugins.smartupdate.CommunicatorSmartUpdatePlugin.initialize(CommunicatorSmartUpdatePlugin.java:133) ~[Communicator-SmartUpdate-Plugin-2.3.1.jar:2.3.1]
at com.cgm.connect.communicator.plugin.ServicePluginManager.initialize(ServicePluginManager.java:304) ~[Communicator.jar:2.3.1]
at com.cgm.connect.connector.plugin.AbstractServicePluginManager.initializePlugin(AbstractServicePluginManager.java:402) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugin.AbstractServicePluginManager.lambda$new$0(AbstractServicePluginManager.java:103) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.common.util.plugin.PluginManager.lambda$installPlugin$13(PluginManager.java:669) ~[util-2.3.0.jar:2.3.0]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source) [?:?]
at java.util.concurrent.CompletableFuture$Completion.run(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
Caused by: org.h2.jdbc.JdbcSQLNonTransientConnectionException: Verbindung ist unterbrochen: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831"
Connection is broken: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831" [90067-199]
...und so weiter..

kann damit jemand was anfangen?

Reicht das aus, wenn das an dem Rechner durchläuft wo die Signierung ausgeführt wird?
Kann es irgendwelche Probleme geben, wenn man das in einem Client-Server-System auf dem Server und allen Arbeitsplätzen ausführt?
(Hab es bisher nur auf einem Client getestet und das scheint nicht auszureichen?

FortiSecond hat geschrieben:Hier nun Version 2 ohne Puffer-Ordner.

n manchen Clients reicht´s einmalig. An anderen muss es alle paar Stunden passieren. Nun ja...

Anwendung:
TM beenden
Batchdatei "Als Administrator ausführen"
TM starten

Wichtig:
- Anpassung an eigene Laufwerke/Ordner erforderlich.
- Auf Terminalserver beachten, dass das Killen der Java-Prozesse dann alle angemeldeten Stationen einschließt, so dass dort jeweils TM zwar weiterläuft, aber für alles, was der Communicator so macht, unter Umständen die stationsbezogenen Communicator-Instanzen wieder zu starten sein werden (TM beenden, starten, fertig)

Kurz: Es kann nicht schaden, das an allen Stationen auszuführen.
Eigentlich sollte es reichen, an den signierenden Stationen die Batch laufen zu lassen. Aber möglicherweise muss der Server es auch haben. Kann ich gerade nicht prüfen (Zeit).

Inzwischen arbeite ich auch mit dieser Batch, Vielen Dank an Fortisecond

Mehr durch Zufall bin ich allerdings auf einen kleinen Schreibfehler in einer Zeile gestoßen
Die Zeile
del /s /q %plugpath%ubePlugin
soll vermutlich
del /s /q %plugpath%CubePlugin
lauten

Ich arbeite jetzt mit folgender Syntax, die zugleich auch den TM Installationspfad abfragt
**************************************************************************************************************
@echo off
::Auslesen der Windowsversion
reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set OS=32BIT || set OS=64BIT
if %OS%==32BIT goto :Win32
if %OS%==64BIT goto :Win64

::Auslesen des TurboMed Installationspfades aus der Registry
:Win32
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win32
echo TurboMed Installation: %x%
set TmPfad=%x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo%TmPfad% als Variable TmPfad gesetzt
echo Die Variable wurden aus der Registry ausgelesen
goto :Weiter

:Win64
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win64
echo TurboMed Installation: %x%
set TmPfad=%x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo Die Variable wurden aus der Registry ausgelesen
echo TmPfad=%TmPfad% gesetzt
goto :Weiter

:Weiter
set plugpath=%TmPfad%\turbomed\programm\communicator\plugins\
echo PlugPath=%plugpath% gesetzt
Pause
wmic process where ExecutablePath='%TmPfad%\\TurboMed\\Programm\\communicator\\jre\\bin\\javaw.exe' delete
pause
del /s /q %plugpath%AeND
del /s /q %plugpath%ArminPlugin
del /s /q %plugpath%CgmAssist
del /s /q %plugpath%Clickdoc
del /s /q %plugpath%Connectdiagnostic
del /s /q %plugpath%CubePlugin
del /s /q %plugpath%DaleUV
del /s /q %plugpath%DaleUVCommunication
del /s /q %plugpath%DigaStore
del /s /q %plugpath%eInvoice
del /s /q %plugpath%EPrescription
del /s /q %plugpath%EVaccinationCertificateService
del /s /q %plugpath%IdentityProvider
del /s /q %plugpath%JesajaNetPlugin
del /s /q %plugpath%KomLePlugin
del /s /q %plugpath%KvCommunicationsPlugin
del /s /q %plugpath%MedDataPlugin
del /s /q %plugpath%Privadis
del /s /q %plugpath%ReadinessCheck
del /s /q %plugpath%SaniQPlugin
del /s /q %plugpath%SecureFileTransfer
del /s /q %plugpath%SecureMailClient
del /s /q %plugpath%SimpleFileTransfer
del /s /q %plugpath%SmartUpdate
del /s /q %plugpath%TelematikPlugin
del /s /q %plugpath%vitaphone
del /s /q %plugpath%WebService
pause
********************************************************************************************************

Danke FortiSecond,
Danke rfbdoc,

funktioniert.

Erhalte noch eine Fehlermeldung in "CGM CONNECT diagnostics:
@ W.Steuber

Ja der Wechsel zu T2MED ist dringend notwendig. Tue mich aber da noch ganz schön schwer. Völlig anderes feeling, Verhalten..

Grüsse aus Kiel
Johnny

Entwarnung:
plötzlich ist der Fehler in CGM CONNNECT diagnostics weg.
Was also habe ich verändert?

Keine Ahnung

Grüsse aus Kiel
Johnny

Moin,
seit dem aktuellen Update + Patch ist die eAU ein Trauerspiel, dauernd funtioniert sie nicht. Wir machen folgendes: jeden Morgen wird der Kim-Dienst am Server über einen Task beendet und neu gestartet. Bei bedarf starten wir die Batchdatei (s.o.) an der lokalen Station, manchmal mit Erfolg. Was auch helfen kann ist, TM am Server zu starten und da eine eAU zu erstellen, dann funktioniert sie auch schon mal wieder. Da man aber im laufenden Betreib für diese Spielchen meist keine Zeit hat, schalten wir die ab und drucken Sie und sagen dem Pat. dass er sie verschicken muß. Ein Koco-Box Neustart (wie von der Hotline enpfohlen) hat die Situation leider verschlimmbessert.
Morgen probiere ich mal folgendes: vor dem Start von TM lasse ich die Batch laufen, mal sehen ob das hilft.

Also, ich muss der Ehrlichkeit halber einfach mal mitteilen, dass - toi toi toi - bei mir bei zugegebenermaßen seltenem eAU-Versand keine Fehlermeldungen mehr kommen, und auch kein Computer mehr abstürzt ....

Moin,
wir haben heute die eAU abgeschaltet. Hotline sucht nach der Ursache, kennt sie aber noch nicht. Die bleibt jetzt aus bis das wieder läuft.

Danke nobbie für den Hinweis,

Bei mir selbst: eAU nie eingeschaltet, KIM nicht etabliert, e-Akte nicht etabliert. Drucken weiterhin auf Papier aus.

Abstürze halten sich in Grenzen, am Server eigentlich so gut wie gar nicht, an den Clients 1-3x am Tag.


Grüsse aus Kiel
Johnny

Nobbie hat geschrieben:Moin,
seit dem aktuellen Update + Patch ist die eAU ein Trauerspiel, dauernd funtioniert sie nicht. Wir machen folgendes: jeden Morgen wird der Kim-Dienst am Server über einen Task beendet und neu gestartet. Bei bedarf starten wir die Batchdatei (s.o.) an der lokalen Station, manchmal mit Erfolg. Was auch helfen kann ist, TM am Server zu starten und da eine eAU zu erstellen, dann funktioniert sie auch schon mal wieder. Da man aber im laufenden Betreib für diese Spielchen meist keine Zeit hat, schalten wir die ab und drucken Sie und sagen dem Pat. dass er sie verschicken muß. Ein Koco-Box Neustart (wie von der Hotline enpfohlen) hat die Situation leider verschlimmbessert.
Morgen probiere ich mal folgendes: vor dem Start von TM lasse ich die Batch laufen, mal sehen ob das hilft.

Gaanz vorsichtig schließe ich mich an... KIM Dienst immer neu starten, Batch-Datei gleich früh auf allen Rechnern... scheint zumindest Linderung zu bringen.. vorläufig... Danke an alle Findigen hier...

Moin,
laut Hotline ist die Instabilität bekannt, aber nicht die Ursache. Das aktuelle Update wird da keine Besserung bringen. Warten wirs ab was kommt.

Moin,
das eMuster Center schmiert bei uns nicht mehr ab. Ich habe alle alten Einträge gelöscht, seit dem funktioniert es. Die eAU ist bei uns aber wieder abgeschaltet. Wenn die an einem Platz nicht mehr funktioniert, TM beenden, Batch Datei starten, TM starten und warten, dann gehts wieder. Das ist mir aber zu blöd im laufenden Betrieb.