Grundprinzip

Bei Problemen sollte immer von außen nach innen geprüft werden:

Dienst
↓
HTTPS / Port / Zertifikat
↓
Login / Session
↓
Patientenkontext
↓
Navigation / Formular
↓
Datenquelle
↓
Speichern / Script / Rechte
↓
Logdatei / Fehler-ID

Die meisten Fehler lassen sich so deutlich schneller eingrenzen.

WebAkte ist nicht erreichbar

Zuerst prüfen, ob der Windows-Dienst läuft:

Get-Service MCDMS.WebAkte

Erwartet:

Status : Running

Ist der Dienst gestoppt:

Start-Service MCDMS.WebAkte

HTTPS-Port prüfen

Beispiel bei Port 8443:

netstat -ano | findstr ":8443"

oder:

Test-NetConnection mcdms-webakte.klinik.intern -Port 8443

Erwartet:

TcpTestSucceeded : True

Status-Endpunkt prüfen

Invoke-WebRequest `
  https://mcdms-webakte.klinik.intern:8443/api/status `
  -UseBasicParsing

Erwartet:

StatusCode : 200

Der Status-Endpunkt bestätigt, dass der WebServer grundsätzlich erreichbar ist.

Er beweist noch nicht, dass:

• MCDMS-Login funktioniert
• SQL erreichbar ist
• Scripts funktionieren
• konkrete Formulare korrekt konfiguriert sind

Dienst startet nicht

Prüfen:

• stimmt der konfigurierte APPPATH?
• existiert {APPPATH}\Web?
• existiert {APPPATH}\Web\PROGRAM\MCDMS.WebServer.exe?
• ist MCDMS5API korrekt installiert?
• läuft die Anwendung x86?
• besitzt das Dienstkonto die erforderlichen Rechte?
• sind WEB.INI und FORMULARE.INI gültig?
• liegt ein kontrollierter Konfigurationsfehler vor?

Logverzeichnis:

{APPPATH}\Web\LOGS

Ein kontrollierter Konfigurationsfehler beendet den Dienst absichtlich, statt ihn in einen Neustart-Loop zu schicken.

HTTPS funktioniert nicht

DNS prüfen

Resolve-DnsName mcdms-webakte.klinik.intern

Port prüfen

Test-NetConnection mcdms-webakte.klinik.intern -Port 8443

SSL-Bindung prüfen

netsh http show sslcert

URLACL prüfen

netsh http show urlacl

WEB.INI prüfen

Beispiel:

[SERVER]
EnvironmentName=Production
Prefixes=https://mcdms-webakte.klinik.intern:8443/
AllowedHosts=mcdms-webakte.klinik.intern
AllowInsecureHttpDevelopment=FALSE

Browser zeigt Zertifikatswarnung

Prüfen:

• stimmt der verwendete DNS-Name mit dem Zertifikat überein?
• enthält das Zertifikat den Hostnamen im SAN?
• ist das Zertifikat noch gültig?
• besitzt es einen privaten Schlüssel?
• vertraut der Client der ausstellenden CA?
• ist das richtige Zertifikat an den HTTPS-Port gebunden?

Login funktioniert nicht

Die Anmeldung erfolgt über die vorhandene MCDMS-Benutzerverwaltung.

Prüfen:

• funktioniert derselbe Benutzer in MCDMS?
• ist die MCDMS5API korrekt installiert?
• läuft der WebServer x86?
• stimmt der APPPATH?
• kann der Dienst die MCDMS-Umgebung erreichen?
• wurde das Login-Limit erreicht?
• steht im Log eine passende Fehler-ID?

Relevante Themen im Log sind typischerweise:

AUTH
COM
SERVICE

Sitzung läuft ab

Die Sessionwerte werden in WEB.INI konfiguriert:

[SESSION]
IdleTimeoutMinutes=30
AbsoluteTimeoutHours=8
MaxSessionsPerUser=3

Prüfen:

• ist das Idle-Timeout zu klein?
• wurde die maximale Gesamtdauer erreicht?
• existieren bereits zu viele parallele Sessions?
• wurde die Session wegen eines Sicherheitsfehlers invalidiert?

Nach Ablauf wird beim nächsten Zugriff erneut die Anmeldung verlangt.

Benutzer wird nach Patientenwechsel abgemeldet

Das kann ein bewusstes Sicherheitsverhalten sein.

Beim Patientenwechsel muss der alte MCDMS-Kontext sauber geschlossen und zurückgesetzt werden.

Schlägt beispielsweise ClosePatient oder das Zurücksetzen des PatientVar-Kontexts fehl, wird kein neuer Patient freigegeben und die Session wird fail-closed beendet. PROJECT-HANDOVER

In diesem Fall:

• Serverlog prüfen
• Fehler-ID suchen
• MCDMS-/COM-Fehler untersuchen

Patient wird nicht gefunden

Prüfen:

• ist der Patient in der aktuell ausgewählten Patientenselection enthalten?
• ist STAMMDAT.MDB erreichbar?
• stimmt StandardDatabase?
• liefert StandardSQL den Patienten?
• enthält das Resultset das konfigurierte Patienten-ID-Feld?
• beschränkt eine zusätzliche Selection den Patientenbestand?

Die Patientensuche arbeitet immer innerhalb der aktuell ausgewählten Patientenliste.

Patientenauswahl ist leer

Prüfen:

• ist die Access-Datenbank erreichbar?
• liefert die konfigurierte SQL-Abfrage Datensätze?
• ist das Patienten-ID-Feld enthalten?
• besitzt das Dienstkonto Zugriff auf die Datenbank?
• ist die konfigurierte Selection gültig?

„Zuletzt“ zeigt keine Patienten

Prüfen:

[PATIENT]
RecentEnabled=TRUE
RecentPatientCount=10

Die Datei liegt unter:

{APPPATH}\CONFIG\USER\<LOGINNAME>.VRL

Zusätzlich werden die dort enthaltenen Patienten beim Lesen erneut gegen die aktuelle Sichtbarkeit geprüft.

Navigationsbereich erscheint nicht

Prüfen:

• ist der Zweig in [AKTENSTRUKTUR] der WEB.INI definiert?
• ist jeder Parent vorher definiert?
• stimmt die Schreibweise?
• wurde nach einer Änderung der Dienst neu gestartet?

Beispiel:

[AKTENSTRUKTUR]
Verwaltung
Verwaltung\DRV
Verwaltung\DRV\Anträge

Formular erscheint nicht

Prüfen:

• existiert der Abschnitt in FORMULARE.INI?
• existiert die konfigurierte HTML-Datei?
• passt der HTML-Pfad zum gewünschten Navigationszweig?
• besitzt der Benutzer das erforderliche Recht?
• stimmt der konfigurierte MATCHCODE?
• greift AdminOnly?
• greift ONLY_USERS?
• enthält das Formular einen Startup-Konfigurationsfehler?

Beispiel:

HTML=HTML\Therapie\ERGOMETERTRAINING.html

gehört zum Zweig:

Therapie

Benutzer sieht ein Formular nicht trotz MATCHCODE

Prüfen:

• stimmt der MATCHCODE exakt mit MCDMS überein?
• liefert MCDMS für den Benutzer tatsächlich ein Recht > 0?
• ist der Benutzer Administrator?
• ist eventuell der Akteneintrag in MCDMS gesperrt?
• steht im Log eine Rechteprüfung mit Fehler-ID?

Für MCDMS-Rechte gelten:

-1 gesperrt
 0 kein Zugriff
 1 lesen
 2 bearbeiten
 3 Vollzugriff

Formular lädt nicht

Prüfen:

• HTML-Datei vorhanden?
• Formular-Konfiguration gültig?
• Datenbank erreichbar?
• Master-/Detailstruktur korrekt?
• ScriptLoadHTML gültig?
• verwendete Templatefelder gültig?
• stimmt der Datenbanktyp?
• ist bei Access DatabaseFile erreichbar?

Bei einem technischen Ladefehler zeigt die WebAkte eine korrelierbare Fehler-ID.

Formular kann nicht gespeichert werden

Prüfen:

Edit=TRUE

Zusätzlich:

• Datenbank erreichbar?
• Tabelle vorhanden?
• Primärschlüssel korrekt?
• Patientenfeld korrekt?
• besitzt der Benutzer Schreibrecht?
• stimmen HTML-Felder mit realen DB-Spalten überein?
• passen Datentypen und Feldlängen?
• ist ScriptSaveHTML korrekt?

Fehler „MasterFieldWritable“

Beispiel:

Bearbeitbares Formularfeld besitzt keine zulässige SQL-Zielspalte.
Check=MasterFieldWritable
MasterField=THROMBOSE

Bedeutung:

Ein editierbares HTML-Feld mit:

name="THROMBOSE"
data-field="THROMBOSE"

wurde gefunden, aber der WebServer erkennt keine passende beschreibbare Spalte.

Prüfen:

• existiert die Spalte wirklich?
• stimmt die Tabelle?
• läuft der WebServer gegen die erwartete Datenbank?
• wurde die Spalte erst nach dem letzten Start hinzugefügt?
• wurde der Dienst danach neu gestartet?
• ist die Spalte Identity/computed/rowversion oder anderweitig technisch geschützt?

Ein unbekanntes editierbares Feld wird bewusst nicht still ignoriert. PROJECT-HANDOVER

Checkbox speichert nicht

Prüfen:

• existiert die DB-Spalte?
• ist sie beschreibbar?
• verwendet das Feld sowohl name als auch data-field?
• sind beide Namen identisch?

Beispiel:

<input type="checkbox"
       name="BTM"
       data-field="BTM">

Hidden-Feld bleibt leer

Prüfen, ob das Feld tatsächlich als echtes Masterfeld vorhanden ist:

<input type="hidden"
       name="ErstelltVon"
       data-field="ErstelltVon"
       value="[#ErstelltVon#]">

Nur eine PatientVar oder Templatevariable allein erzeugt keine Datenbankspeicherung.

Bestehender Datensatz zeigt keinen PatientVar-Wert

Das ist grundsätzlich korrekt.

Bei vorhandenen SQL-Datensätzen ist SQL die maßgebliche Quelle.

Ein leerer SQL-Wert wird nicht automatisch durch eine PatientVar überschrieben.

PatientVar-Initialisierung ist nur beim neuen Datensatz für noch unbelegte Felder vorgesehen.

Master-/Detailformular speichert Details nicht

Prüfen:

• stimmt die Database=...#...-Konfiguration?
• existieren Master- und Detailtabelle?
• stimmen Detail-PK, Master-FK und PatientID?
• besitzt das HTML data-mcdms-detail-list?
• existiert genau ein template[data-mcdms-detail-row]?
• besitzen die Detailfelder data-detail-field?
• stimmt die Spalten-Allowlist?
• existiert beim Delete der erforderliche Cascade-FK?

Mehrere Detailbereiche funktionieren nicht

Bei mehreren sichtbaren Detailbereichen müssen alle echten Container statisch markiert sein:

<tbody data-mcdms-detail-list></tbody>
<tbody data-mcdms-detail-list></tbody>
<tbody data-mcdms-detail-list></tbody>

Es bleibt genau ein gemeinsames Detailtemplate.

Prüfen:

• sind alle Listen statisch vorhanden?
• gibt es genau ein Template?
• verwenden alle Bereiche dieselben Detailfelder?
• übernimmt das formularseitige JavaScript die visuelle Verteilung?
• wird BEREICH als normales Detailfeld gespeichert?

Detailreihenfolge ist falsch

Prüfen:

OrderByDetails=ID;ASC

oder die fachlich gewünschte Spalte.

Ist OrderByDetails ungültig oder fehlt, wird sicher nach dem Detail-PK sortiert.

Löschen funktioniert nicht

Prüfen:

Delete=TRUE

Dann zusätzlich:

• hat der Benutzer ausreichende Rechte?
• ist er Eigentümer, falls nur Recht 2 vorliegt?
• läuft ScriptDelete erfolgreich?
• gehört der Datensatz zum aktuellen Patienten?
• ist bei Master/Detail der Cascade-FK korrekt?

Wenn ein Delete-Script konfiguriert ist:

ScriptDelete=CONFIG\Scripts\WEB\delete.mcfscr

muss dieses erfolgreich abgeschlossen werden.

Duplizieren wird nicht angeboten

Prüfen:

MultiRecord=TRUE
AllowDuplicate=TRUE

Zusätzlich muss der Benutzer die erforderlichen Rechte besitzen.

Bei Master/Detail werden Master und Details gemeinsam kopiert.

RecordView=LIST funktioniert nicht

Prüfen:

MultiRecord=TRUE
RecordView=LIST

Zusätzlich benötigt das HTML:

<div data-mcdms-record-list></div>

und:

<template data-mcdms-record-row>

sowie passende:

data-record-field

Felder.

Prüfen außerdem:

• OrderBy-Spalte vorhanden?
• persistente Order-Spalte numerisch?
• DB-Spalten tatsächlich beschreibbar?
• keine inkompatible Master/Detail-Konfiguration?

Script wird nicht ausgeführt

Prüfen:

• ist der Pfad relativ zu {APPPATH}?
• existiert die .MCFSCR-Datei?
• liegt sie innerhalb des erlaubten APPPATH?
• stimmt die Dateiendung?
• enthält der Pfad Traversal oder UNC?
• ist das Script vollständig serverseitig ausführbar?
• liefert ein vorheriges Script in der Folge bereits Fehler?

Beispiel:

ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr

Mehrere Scripts:

ScriptLoadHTML=CONFIG\Scripts\a.mcfscr;CONFIG\Scripts\b.mcfscr

werden von links nach rechts ausgeführt.

ScriptSaveHTML meldet Fehler, Daten sind aber gespeichert

Das ist ein definierter Ablauf.

ScriptSaveHTML läuft erst nach dem SQL-Commit.

Daher gilt:

SQL gespeichert
↓
COMMIT
↓
ScriptSaveHTML

Schlägt das Script anschließend fehl, bleibt der Datensatz gespeichert.

Es erfolgt kein Rollback. PROJECT-HANDOVER

Im Dialog erscheint eine Fehler-ID, über die der zugehörige Serverlog gefunden werden kann.

Action funktioniert nicht

Prüfen HTML:

<button type="button"
        data-mcdms-action="DRUCKEN">

und FORMULARE.INI:

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Der Action-Name muss übereinstimmen.

Zusätzlich prüfen:

• Script vorhanden?
• Benutzer-/Patientenkontext gültig?
• Script erfolgreich?
• ungespeicherte Änderungen verhindern eventuell ActionReload?

Formular sieht nach Speichern falsch aus

Nach normalem Speichern erfolgt ein partieller Formularrefresh.

Identische <script>-Elemente werden dabei nicht erneut ausgeführt.

Formular-JavaScript muss deshalb:

• event-delegiert oder
• idempotent

geschrieben sein.

Wenn eine rein visuelle JavaScript-Markierung nach dem Speichern verschwindet, ist häufig genau dieser Lifecycle die Ursache. app

Navigation oder Aktenstatus zeigt alten Stand

Beim fachlichen Öffnen eines Aktenzweigs wird der Patientenaktenstand frisch geladen.

Falls dennoch ein alter Stand sichtbar ist:

• Zweig erneut öffnen
• Fehlerdialog beachten
• Serverlog prüfen
• prüfen, ob der externe MCDMS-Vorgang wirklich in der erwarteten PatientAkte-Datenbank angekommen ist

Schlägt der Refresh fehl, soll kein alter Aktenstand als vermeintlich aktuell weiterverwendet werden.

Native MCDMS-Dokumente lassen sich nicht öffnen

Prüfen:

• gehört die AkteID zum aktuellen Patienten?
• ist der Dokumenttyp in [NATIVE_AKTE] zugelassen?
• existiert die Datei?
• liegt sie im zulässigen Datenpfad?
• stimmt die Dateiendung?
• besitzt der Benutzer ausreichende MCDMS-Rechte?
• liegt ein Traversal-/Reparse-Sicherheitsproblem vor?

Status lässt sich nicht ändern

Prüfen:

• aktuelles MCDMS-Recht?
• Eigentümer des Eintrags?
• ist der Benutzer Administrator?
• aktueller Status?
• wird versucht, einen grünen Eintrag wieder freizugeben?

Für das Verlassen eines grünen Zustands kann eine zusätzliche Freigabe erforderlich sein.

FORMULARE.INI geändert, Änderung wird nicht sichtbar

FORMULARE.INI wird beim Start geladen.

Dienst neu starten:

Restart-Service MCDMS.WebAkte

WEB.INI geändert, Änderung wird nicht sichtbar

Auch WEB.INI wird beim Start geladen.

Restart-Service MCDMS.WebAkte

HTML geändert, Änderung wird nicht sichtbar

HTML wird beim Formularaufruf neu gelesen.

Prüfen:

• wurde wirklich die richtige HTML-Datei geändert?
• verweist FORMULARE.INI auf diese Datei?
• zeigt der Browser eventuell noch eine alte statische Ressource?
• bei Bedarf Browser vollständig neu laden

Ein WebServer-Neustart ist für reine HTML-Änderungen normalerweise nicht erforderlich.

CSS oder JavaScript geändert, aber Browser zeigt alten Stand

Bei Browser-Caching kann ein vollständiges Neuladen helfen:

Strg + F5

Prüfen außerdem:

• richtige Datei geändert?
• richtige Ressource eingebunden?
• CSP blockiert eine externe Ressource?
• JavaScript-Syntaxfehler?
• Formularscript abhängig vom Partial-Refresh?

Fehler-ID verwenden

Bei technischen Fehlern zeigt die WebAkte möglichst eine korrelierbare Fehler-ID.

Beispiel:

Fehler-ID: 20261014-085352-0FD0

Diese ID im Log suchen.

Logpfad:

{APPPATH}\Web\LOGS

Datei:

MCDMS-WebAkte-yyyy-MM-dd.log

Die Loggingarchitektur korreliert Fehler über diese ID und hält technische Details bewusst aus dem Benutzer-Dialog heraus. PROJECT-HANDOVER

Erweiterte Formulardiagnose

Für gezielte Fehlersuche kann vorübergehend gesetzt werden:

[LOGGING]
DetailedFormDiagnostics=TRUE

Danach Dienst neu starten.

Nach der Diagnose wieder:

DetailedFormDiagnostics=FALSE

Typische Logbereiche

Je nach Fehler können unter anderem auftreten:

AUTH
COM
SCRIPT
SQL
FORM
CONFIG
VRL
HTTP
SERVICE

Wichtiger als der Bereichsname ist im aktuellen System die Fehler-ID und der zugehörige Operation-/Step-/Check-Kontext.

Bei unbekannten Fehlern

Empfohlene Reihenfolge:

1. Fehler-ID notieren
2. Logdatei des Tages öffnen
3. nach Fehler-ID suchen
4. Operation / Step / Check prüfen
5. Formular-ID und technische Metadaten prüfen
6. erst danach Konfiguration oder HTML ändern

Nicht sinnvoll ist es, bei einem unbekannten Fehler sofort mehrere Konfigurationsdateien oder Formularfelder gleichzeitig zu ändern.

Nach Änderungen testen

Nach einer Fehlerkorrektur mindestens den betroffenen Ablauf erneut vollständig prüfen.

Beispiel bei Formularproblemen:

Patient wählen
↓
Formular öffnen
↓
Datensatz laden
↓
ändern
↓
speichern
↓
erneut öffnen
↓
Wert prüfen

Bei sicherheitsrelevanten Problemen zusätzlich prüfen, dass ein anderer Patient oder ein Benutzer mit geringerem Recht nicht auf den Datensatz zugreifen kann.