AUSFÜHRBARE REFERENZ

Integrationsleitfaden

Das Portal zeigt den gesamten Auftrag mit getrennten Simulatoren. Die Nachrichten sind echte HTTP-, WebSocket- und XML/TCP-Übertragungen. Zahlung und physische Ausgabe sind simuliert. Die Downloadpakete enthalten unseren Code und unsere Anschlussdokumentation.

Gollmann-Paket ProPharma-Paket Gesamte Demo

Praxisabgleich · 08.10.2026

15’274 vollständige WWKS-Nachrichten aus einem lokalen Praxislog wurden mit ORCA verglichen. Belegt sind KeepAlive, StockInfo, Output und Input. Der Simulator zeigt jetzt bei der Ausgabe Queued → InProcess → PartialDispense → Completed oder Incomplete. Zwischenmeldungen bestätigen noch keinen Abschluss und werden nicht als zusätzliche Packungen gezählt.

Die fünf Artikel tragen echte Namen, Pharmacodes und EAN/GTIN aus dem Log. Preise, Bestände, Packungskennungen und Zahlung bleiben Testwerte. Der Hustensirup ist Solmucalm für Erwachsene, 180 ml. Der vollständige Abgleich steht in den Downloadpaketen unter integrations/PRAXISABGLEICH.md; das Originalprotokoll wird nicht veröffentlicht.

Reservation, TaskInfo, Abholterminal und ShoppingCart sind in diesem Ausschnitt nicht belegt. Einlagerungsdialoge werden nicht aktiv simuliert. Routing über Teilnehmerkennung 0 und reale Förderzeiten benötigen weiterhin das konkrete Herstellerprofil. State=Available allein bestätigt keine frei reservierbare Menge; AvailableQuantity und Reserved sind weiterhin Demoergänzungen.

Farben im Tec-Log

Blau · Existing: dokumentierte WWKS2-/WWKS2+-Dialogfamilie, beispielsweise StockInfo, Output, TaskInfo oder ShoppingCart. Das bedeutet keine bereits geprüfte Herstellerintegration.

Orange · Angenommen: Reservations-Erweiterung mit noch unbestätigter Gollmann-Unterstützung oder eigener ORCAPickupCommit-Prototyp. Orange · Existing + Erweiterung: vorhandener Dialog mit Demoergänzung, beispielsweise AvailableQuantity in StockInfo oder Reservationsbezug in Output.

Grau kennzeichnet reine Simulatorsteuerung beziehungsweise nicht zugeordnete Dialoge. Aufklappen zeigt die konkrete Einordnung und die Originalnachricht. «Angenommen» bezeichnet eine Entwicklungsannahme, keine Herstellerzusage.

Warenkorb und Reservation

Packungen zunächst unverbindlich sammeln. Erst «Warenkorb reservieren» prüft und reserviert den gesamten Warenkorb; danach ist die Testzahlung möglich. Bei fehlenden Mengen bleibt der Warenkorb bearbeitbar. «Reservation freigeben / bearbeiten» erhält die Positionen und gibt die Mengen frei.

Ein initialer simulierter Bestandsdialog füllt den gemeinsamen Bestandsspeicher. Nach Simulatoroperationen wird er erneut abgeglichen; Artikelklicks und das Browser-Polling lesen den gespeicherten Stand. Eine echte Live-Anbindung ist noch nicht umgesetzt.

Aufgaben je Rolle

Welche Dialoge sind gesetzt, welche vorgeschlagen?

Auch AvailableQuantity, die Reservationssemantik und die Deduplizierung im Simulator sind explizite Referenzannahmen. Der Adapter ist noch kein vollständiger zertifizierter WWKS2-Client. Die Herstellerpakete benennen jede Anschlussstelle und die verlangten Tests. Originalmails und Herstellerhandbücher werden nicht veröffentlicht.

Fristen und Wiederanlauf

1. Erste Packung: 20 Minuten Checkout, 28 Minuten technische Haltefrist. Keine Verlängerung durch weitere Artikel.
2. Ab Minute 15 Countdown. Ab Minute 20 kann keine neue Zahlung starten.
3. Eine bereits laufende, noch ungeklärte Zahlung hält die Reservation. Der Zeitpuffer allein ist kein Beweis eines Zahlungsabbruchs.
4. Nach Zahlung und bestätigtem Roboter-Commit entsteht der Abholcode. Bezahlte Abholaufträge haben in dieser Demo keine automatische Verfallzeit.
5. Verlorene Ausgabeantwort: Ausgabezustand mit gleicher Kennung abfragen. Niemals blind nochmals ausgeben.
6. Vollständige Ausgabe: ProPharma-Verarbeitung. Teilabgabe: sichtbarer Klärungsfall. Automatische Nachlieferung und Rückerstattung sind nicht implementiert.

Die Demo speichert Zustände in SQLite. Nach Neustart stellt „Status & ausstehende Vorgänge abgleichen“ offene Zusagen, Ausgaben und Buchungen wieder her. Ein echter Zahlungsanbieter muss vor dem Freigeben einen endgültigen Zahlungszustand liefern.

ProPharma: Bestand und Beleg unterscheiden

Ziel ist der bekannte E-Bestellungsprozess: elektronischen Auftrag einlesen, Kreditverkauf auf „Geliefert“ abschliessen und den Zahlungsrecord mit externer Zahlungsreferenz auf 0 verbuchen. Eine bereits über die Roboterkommunikation erfasste Bestandsbewegung darf beim späteren Verkauf nicht nochmals abgezogen werden. Das reale Mapping wird am vorhandenen Import angeschlossen.

In der Referenz verlangt Close die vollständige Ausgabe und Zahlungsdeckung. Dieser Simulatorvertrag ist keine Aussage, dass ein standardmässiges Close bereits „Geliefert“ bedeutet.

Lokal starten

Python 3.11 oder neuer, ZIP entpacken, Start-ORCA.cmd ausführen, lokale Demo öffnen. Beim ersten Start werden Abhängigkeiten installiert. Die vier Prozesse laufen bis Strg+C. Es wird weder eine Firewallregel noch ein Autostart eingerichtet.

Shop → HTTP :8765 → ORCA → WebSocket → Adapter
                                        ├─ XML/TCP :6051 → Gollmann-Simulator
                                        └─ XML/TCP :6052 → ProPharma-Simulator

Alle drei lokalen Ports sind an 127.0.0.1 gebunden. TCP 6050 ist keine notwendige öffentliche Freigabe. Die reale WaWi-/Roboterverbindung bleibt separat und wird anhand von Hello-Nachrichten, Fähigkeiten und vorhandenen Rollen zugeordnet.

.\.venv\Scripts\python.exe -m unittest discover -s tests -v

Hoststar und Windows

Das Portal und die PHP-Vermittlung liegen beim Webhoster. Ein lokaler Relay-Prozess holt die Aufträge ausgehend per HTTPS ab. Keine eingehende Verbindung und keine NAT-Regel erforderlich. Der Windows-PC muss eingeschaltet sein und die Demo ausführen. Fällt er aus, bleiben Portal und Downloads verfügbar; API-Anfragen melden einen Verbindungsfehler.

Hoststar-Paket: öffentliche Dateien nach /orca, privates Verzeichnis ausserhalb des Dokumentwurzelverzeichnisses. Alternativ geschützt mit Require all denied unter /orca/_private; den direkten Zugriff zwingend auf HTTP 403 prüfen. Ein zufälliger Bridge-Schlüssel verbindet Gateway und Relay, er gehört nicht ins öffentliche Paket.

Windows-Konfiguration: .var/relay-settings.json mit url und token. Dann Start-Hosted-ORCA.cmd. Für das WordPress-Plugin ZIP installieren und [orca_demo] in eine Seite einfügen; Standardziel ist https://kaser-bamert.ch/orca/, optional über den Filter orca_demo_url ändern.

Was jetzt geprüft werden kann

Der lokale Integrationstest deckt den normalen Ablauf, Konkurrenz um die letzte Packung, Fristen, verzögerte Zahlung, verlorene Ausgabe- und Buchungsantwort, Teilabgabe, WaWi-Ausfall, Kernneustart und Sitzungstrennung, gemeinsame Welt, globalen Reset und Journalbegrenzung ab. Zusätzlich kann jeder Fall im Portal ausgelöst werden.

Offen bleiben reale Gollmann-/ProPharma-Kompatibilität, physische Fachsensorik, echte Zahlung, Mailversand und die Installation in einer konkreten WordPress-Instanz. Die öffentliche Beta arbeitet mit realen Artikelidentitäten, simulierten Preisen/Beständen und einfachen Mengen-/Sitzungslimits; sie ist kein Produktionsshop.

Zahlungsbestätigung und neue Testrunde

Die simulierte Zahlungsbestätigung trifft nach ca. zehn Sekunden serverseitig ein, auch wenn der Browser geschlossen wurde. Der Shop liest alle zwei Sekunden den ORCA-Status; der kleine Ring rechts bei der Zahlung zeigt das Warten an. Die gesamte Seite wird dabei nicht blockiert.

Beim späteren Zahlungsanschluss meldet der Provider den Abschluss serverseitig. Beispielsweise verlangt Saferpay für TWINT Notification-URLs. Die Payment-Page-Integration prüft den Transaktionsstatus anschliessend per Assert. Auftrag, Betrag und Währung müssen zum erwarteten Vorgang passen; wiederholte Notifications dürfen keine zweite Verarbeitung auslösen. Der konkrete Zahlungsanbieter ist noch nicht angeschlossen. Die zehn Sekunden sind ein Demo-Ablauf, keine zugesicherte Provider-Antwortzeit.

„Simulation zurücksetzen“ oben im Portal stellt Bestand, Reservationen, Aufträge, Zahlungen, Ausgaben, Verkäufe, Fehlerfälle, Journal und Uhr auf Anfang. Standardmässig teilen alle Besucher eine gemeinsame Welt; der Reset gilt für alle. Mit ORCA_DEMO_MODE=session kann vor dem Start auf getrennte Browserwelten umgestellt werden. Unterbrochene Resets werden vor der weiteren Auftragsverarbeitung abgeglichen.

Nachrichtenjournal

Ansicht: maximal 50 Einträge. Puffer: maximal 300 inklusive Archiv; älteste entfallen. Archivieren blendet Einträge aus der aktuellen Ansicht aus. Der JSON-Export enthält alle noch gespeicherten Originalnachrichten. Filter nach Nachrichtentyp, Archivstatus und Text. Automatische Bestands- und Statusabfragen bleiben ausserhalb des Journals.

XML wird eingerückt und farbig angezeigt. Der Linter prüft Syntax, WWKS-Hülle und Id/Source/Destination am Dialogelement. Hersteller-XSDs und fachliche Dialogkonformität werden damit nicht validiert.