--- title: 07 Exemplarische Vorgehensweise für ein Testsystem description: "## Ziel Dieses Kapitel beschreibt beispielhaft, wie eine MCDMS WebAkte in einer Testumgebung eingerichtet und schrittweise geprüft werden kann. Ziel ist eine Umgebung, die dem späteren Klinikbetrieb möglichst nahekommt: ``` MCDMS-Testinstallation ↓ interner DNS-Name ↓ HTTPS-Zertifikat ↓ MCDMS WebAkte ↓…" url: "https://aspi-gmbh.de/docs/exemplarische-vorgehensweise-fuer-ein-testsystem/" updated: "2026-10-15" category: Anleitungen / MCDMS WebAkte --- # 07 Exemplarische Vorgehensweise für ein Testsystem ## Ziel Dieses Kapitel beschreibt beispielhaft, wie eine MCDMS WebAkte in einer Testumgebung eingerichtet und schrittweise geprüft werden kann. Ziel ist eine Umgebung, die dem späteren Klinikbetrieb möglichst nahekommt: ``` MCDMS-Testinstallation ↓ interner DNS-Name ↓ HTTPS-Zertifikat ↓ MCDMS WebAkte ↓ MCDMS-Benutzer ↓ Testpatient ↓ erstes Formular ↓ Rechte / Scripts / Datenbank ``` Für produktive Kliniksysteme sollten vorhandene DNS-, PKI-, Zertifikats- und Clientverwaltungsstrukturen verwendet werden. ## 1. Testsystem festlegen Vor Beginn sollten mindestens folgende Werte bekannt sein: ``` MCDMS APPPATH Servername IP-Adresse DNS-Name der WebAkte HTTPS-Port Dienstkonto Testbenutzer Testpatient ``` Beispiel: ``` APPPATH: D:KlinikenTESTMCDMS Server: TEST-MCDMS01 IP-Adresse: 192.168.2.50 DNS: mcdms-webakte.test.local HTTPS-Port: 8443 ``` Der DNS-Name sollte während der gesamten Einrichtung identisch verwendet werden. Also: ``` DNS mcdms-webakte.test.local Zertifikat SAN mcdms-webakte.test.local HTTPS-Prefix https://mcdms-webakte.test.local:8443/ Browser https://mcdms-webakte.test.local:8443/ ``` ## 2. MCDMS-Testumgebung prüfen Bevor die WebAkte eingerichtet wird, sollte die vorhandene MCDMS-Testinstallation selbst funktionieren. Prüfen: - MCDMS startet - MCDMS-Benutzer kann sich anmelden - Testpatient vorhanden - Patient kann in MCDMS geöffnet werden - MCDMS5API installiert und registriert - verwendete SQL-Verbindung funktioniert - benötigte Access-Datenbanken erreichbar - MCDMS-Scripts grundsätzlich ausführbar Die WebAkte sollte nicht zur Fehlersuche einer bereits fehlerhaften MCDMS-Testinstallation verwendet werden. ## 3. Internen DNS-Namen anlegen Auf dem internen DNS-Server wird ein Eintrag für die WebAkte angelegt. Beispiel: ``` mcdms-webakte.test.local → 192.168.2.50 ``` Auf einem Client prüfen: ``` Resolve-DnsName mcdms-webakte.test.local ``` Die zurückgegebene IP-Adresse muss dem WebAkte-Server entsprechen. ## 4. Serverzertifikat bereitstellen Wenn bereits eine interne Zertifizierungsstelle vorhanden ist, sollte diese verwendet werden. Benötigt wird ein Serverzertifikat für: ``` mcdms-webakte.test.local ``` Der DNS-Name muss im `Subject Alternative Name` enthalten sein. Das Zertifikat wird im Zertifikatspeicher des lokalen Computers installiert: ``` Lokaler Computer └─ Persönlich └─ Zertifikate ``` Prüfen: ``` Get-ChildItem Cert:LocalMachineMy | Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey ``` Erwartet: ``` HasPrivateKey = True ``` Den Thumbprint des **Serverzertifikats** notieren. ## 5. Optional: eigene Test-CA Nur wenn für das Testsystem keine vorhandene Zertifizierungsstelle genutzt werden kann, kann eine eigene Test-CA eingerichtet werden. Diese sollte ausschließlich für die Testumgebung verwendet werden. Für einen produktiven Klinikbetrieb ist normalerweise keine eigene WebAkte-Zertifizierungsstelle erforderlich. Die WebAkte verwendet dort das von der Klinik bereitgestellte Serverzertifikat. Die bisherige Testsystembeschreibung enthält hierfür bereits einen ausführlichen optionalen Test-CA-Ablauf. 07 Exemplarische Vorgehensweise… ## 6. Clientvertrauen prüfen Der Testclient muss der ausstellenden Zertifizierungsstelle vertrauen. Beim Browseraufruf darf später keine Zertifikatswarnung erscheinen. In einer realen Klinik erfolgt die Zertifikatsverteilung üblicherweise zentral, beispielsweise über: - Active Directory - Gruppenrichtlinien - MDM ## 7. WebAkte bereitstellen Das freigegebene Deployment wird nach: ``` {APPPATH}Web ``` kopiert. Beispiel: ``` D:KlinikenTESTMCDMSWeb ``` Die wesentliche Struktur lautet: ``` Web ├─ WEB.INI ├─ FORMULARE.INI ├─ PROGRAM ├─ SETUP ├─ LOGS ├─ HTML ├─ CSS ├─ JS └─ IMAGES ``` ## 8. WEB.INI für das Testsystem vorbereiten Beispiel: ``` [SERVER] EnvironmentName=Production Prefixes=https://mcdms-webakte.test.local:8443/ AllowedHosts=mcdms-webakte.test.local AllowInsecureHttpDevelopment=FALSE ``` Auch ein produktionsnahes Testsystem sollte bereits mit HTTPS betrieben werden. Weitere Konfigurationen wie Patientensuche, Session und Aktenstruktur können anschließend ergänzt werden. ## 9. WebAkte installieren PowerShell 5.1 als Administrator öffnen. Zum Setup-Verzeichnis wechseln: ``` cd "D:KlinikenTESTMCDMSWebSETUP" ``` Bei lokaler MCDMS-Installation beispielsweise: ``` .Install.ps1 -ServiceAccount LocalSystem ``` Während der Installation werden unter anderem benötigt: ``` HTTPS-Prefix CertificateThumbprint MCDMS APPPATH ``` Beispiel: ``` HTTPS-Prefix: https://mcdms-webakte.test.local:8443/ CertificateThumbprint: APPPATH: D:KlinikenTESTMCDMS ``` Das Setup richtet die erforderlichen Komponenten ein, insbesondere: - WEB.INI-Serverkonfiguration - HTTP.sys - HTTPS-Zertifikatbindung - erforderliche URLACL - gegebenenfalls Firewallregel - Windows-Dienst - automatischen Start - Recovery-Konfiguration ## 10. Windows-Dienst prüfen ``` Get-Service MCDMS.WebAkte ``` Erwartet: ``` Status : Running ``` Falls erforderlich: ``` Start-Service MCDMS.WebAkte ``` ## 11. HTTPS-Port prüfen Beispiel: ``` netstat -ano | findstr ":8443" ``` oder vom Client: ``` Test-NetConnection mcdms-webakte.test.local -Port 8443 ``` Erwartet: ``` TcpTestSucceeded : True ``` ## 12. Status-Endpunkt prüfen ``` Invoke-WebRequest ` https://mcdms-webakte.test.local:8443/api/status ` -UseBasicParsing ``` Erwartet: ``` StatusCode : 200 ``` Damit ist zunächst nur bestätigt, dass der WebServer erreichbar ist. ## 13. Browserzugriff testen Im Browser: ``` https://mcdms-webakte.test.local:8443/ ``` Es darf keine Zertifikatswarnung erscheinen. Danach zunächst nur die Grundfunktionen prüfen: ``` Login ↓ Patientenliste ↓ Patientensuche ↓ Patient auswählen ↓ Patientenstammblatt ↓ Navigation ``` ## 14. MCDMS-Login testen Mit einem vorhandenen MCDMS-Testbenutzer anmelden. Prüfen: - Anmeldung erfolgreich - Benutzername korrekt - Klinikname korrekt - keine erneute Anmeldeschleife - keine COM-/MCDMS-Fehler im Log ## 15. Testpatient auswählen Einen bekannten Testpatienten suchen. Prüfen: - Patient erscheint in der Liste - Suche funktioniert - Patient kann ausgewählt werden - Patientenkopf wird angezeigt - Patientenwechsel funktioniert - „Zuletzt“ wird aktualisiert Für alle weiteren Tests sollte ausschließlich ein freigegebener Testpatient verwendet werden. ## 16. Erstes einfaches Formular anlegen Als erstes sollte bewusst ein sehr einfaches SQL-Formular verwendet werden. Beispiel: ``` [FORMULAR_TEST] Title=Testformular HTML=HTMLTestTEST.html Edit=TRUE MultiRecord=TRUE Delete=TRUE AllowDuplicate=TRUE Database=FRM_WEBTEST;FRMID;PatientID OrderBy=FRMID;DESC ``` Beispieltabellenstruktur: ``` FRMID int Identity PK PatientID int TEXT1 nvarchar(255) DATUM date AKTIV bit ``` HTML: ``` Testformular
``` ## 17. Formularfunktion testen Der Test sollte mindestens umfassen: ``` + Neu ↓ Werte eingeben ↓ Speichern ↓ Datensatz erneut öffnen ↓ Werte vergleichen ↓ ändern ↓ erneut speichern ↓ löschen ↓ duplizieren ``` Dabei prüfen: - PatientID wurde korrekt gesetzt - technischer Primärschlüssel wurde automatisch erzeugt - Browser kann PatientID oder PK nicht manipulieren - Datensatz erscheint nur beim richtigen Patienten ## 18. Rechte testen Jetzt sollte nicht nur mit einem Administrator getestet werden. Empfohlen sind mindestens: ``` Administrator Benutzer mit Recht 3 Benutzer mit Recht 2 Benutzer mit Recht 1 Benutzer ohne Recht ``` Bei einem MCDMS-Formular beispielsweise: ``` MATCHCODE=TEST_WEB ``` Prüfen: - Anzeige - Bearbeitung - Neuerfassung - Löschen - Eigentümerregel Auch negative Tests durchführen: Ein Benutzer ohne Berechtigung darf das Formular nicht allein durch Eingabe einer URL öffnen können. ## 19. ScriptLoadHTML testen Beispiel: ``` ScriptLoadHTML=CONFIGScriptsWEBTestload.mcfscr ``` Das Script kann beispielsweise eine PatientVar setzen. Im HTML: ```
[#TESTVAR#]
``` Prüfen: - Script läuft - richtiger Patientenkontext - Wert wird angezeigt - keine interaktive Desktopfunktion benötigt ## 20. ScriptSaveHTML testen Beispiel: ``` ScriptSaveHTML=CONFIGScriptsWEBTestsave.mcfscr ``` Test: ``` Datensatz speichern ↓ SQL kontrollieren ↓ Scriptwirkung kontrollieren ↓ Formular erneut laden ``` Wichtig: `ScriptSaveHTML` läuft nach dem SQL-Commit. Ein Scriptfehler darf daher nicht mit einem fehlgeschlagenen SQL-Speichern verwechselt werden. ## 21. Master-/Detailformular testen Erst wenn das einfache Formular funktioniert, sollte ein Master-/Detailformular eingerichtet werden. Beispiel: ``` Database=FRM_TEST;FRMID;PatientID#FRM_TEST_DETAIL;ID;FRMID;PatientID ``` Prüfen: - Master speichern - mehrere Detailzeilen - Zeile hinzufügen - Zeile ändern - Zeile entfernen - vollständiges Speichern - erneut laden - Duplizieren - Löschen ## 22. Mehrere Detailbereiche testen Danach können mehrere sichtbare Detaillisten verwendet werden: ``` ``` mit genau einem gemeinsamen: ```