Dieses Dokument enthält eine Übersicht über das Design der posps-Schnittstelle, die Funktionalität und die grundlegenden Interaktionen zwischen Server und Client. Nachdem Sie diese Übersicht gelesen haben, sollten Sie einige Beispiele lesen um einen detailierteren Einblick in die Interaktionen zu bekommen. Die Referenz enthält einen kompletten Leitfaden zu den Web Service-Operationen und Datentypen.
Der posps web service definiert eine Schnittstelle zwischen einer Kasse (point of sale, POS) und der Apotheken-Warenwirtschaft (pharmacy IT system, PS). Die Kassen sind Clients, die auf den PS Server zugreifen. Der Web Service wird durch das WSDL-Dokument posps.wsdl definiert, das die XML Schema Typdefinitionen in posps.xsd beinhaltet. (Die posps-*.xsd Schemata definieren Wrapper-Elemente für die Parameter der WSDL-Operationen, die in eigenen Namespaces definiert sein müssen.)
Das Ziel des Web Service ist es, die Business-Logik und Datenhaltung, die bereits in der Warenwirtschaft existieren, für neue Arten von Kassen wiederzuverwenden. Eine Kasse, die neu in eine Apotheke integriert wird, kann damit dem Apotheker die volle Funktionalität und das Wissen der bereits installierten Warenwirtschaft zur Verfügung stellen. Es entsteht nicht die Notwendigkeit, Daten auf verschiedenen Systemen zu speichern und zu aktualisieren und die Gefahr von Fehlern aufgrund von verschiedenen Berechnungsregeln besteht nicht.
Die posps web service Schnittstelle unterstützt zwei Aktivitäten: Verkauf und Abholung. Während eines Verkaufs kann der Kunde interaktiv die Artikel auswählen, die er kaufen möchte. Eine Abholung erlaubt es dem Kunden, Artikel abzuholen, die er bestellt hat (eventuell über einen Web Shop), oder die nicht verfügbar waren als er vorher die Apotheke besucht hat. Der Unterschied ist, dass bei einer Abholung die Artikel vom Apotheker zusammengestellt wurden und entweder vollständig oder gar nicht abgegeben werden.
Der Web Service teilt die Aufgaben zwischen POS und PS folgendermaßen auf.
Das PS
Der POS
Das Diagramm zeigt die Anwendungsfälle, die von der Aktivität Verkauf abgedeckt werden. Anforderungen und Artikel- oder Personensuche werden üblicherweise als Teil eines Verkaufs durchgeführt, das ist aber nicht unbedingt notwendig. Der sell Anwendungsfall wird durch die Operationen des Sale Port-Typs realisiert, search articles und persons durch den Search Port-Typ und order articles durch den Order Port-Typ.
Andere Funktionen, die ein PS üblicherweise anbietet (wie Verkaufs-Historie, Berichte, Verwaltung der Artikel- und Personen-Datenbanken etc.) sind nicht durch diese Schnittstellen-Spezifikation abgedeckt. Es wird erwartet, dass diese in proprietärer PS Client-Software implementiert ist, die parallel zu dem POS Client (möglicherweise auf einem anderen Rechner) laufen kann.
Das folgende Aktivitätsdiagramm illustriert die Ablauf und die übliche Verteilung der Operationen zwischen POS und PS für einen Verkauf. Es zeigt nur die Haupt-Operationen.
Alle Aktivitäten außer calculate prices entsprechen direkt posps-Operationen. Wenn der POS eine Änderung im Verkauf signalisiert, berechnet das PS die Preise der Artikel und den Gesamtpreis neu und schickt diese Informationen zurück zum POS. Wenn der POS sicher ist, dass es keine weiteren Änderungen an den Positionen des Verkaufs gibt, kassiert er den vom PS berechneten Gesamtbetrag vom Kunden und bestätigt die Zahlung. Nach diesem Punkt ist keine Änderung am Verkauf erlaubt, die den Gesamtpreis ändert. (Eine Ausnahme dieser Regel ist, dass wenn eine Zahlung annulliert wird, der Verkauf wieder geändert werden darf.)
Dieses Beispiel zeigt die Operationen, die bei einem einfachen Verkauf durchgeführt werden, in denen ein einzelner Artikel von einem Kunden in Selbstbedienung gekauft wird. Der Kunde bleibt anonym, seine Daten werden nicht erfasst.
Als erstes startet der POS einen neuen Verkauf. Er sucht nach dem vom Kunden angefragten Artikel, übernimmt die ArticleId aus dem Suchresultat und fügt eine Position mit diesem Artikel zum Verkauf hinzu. Dann lässt er den Kunden den Gesamtbetrag, den das PS berechnet hat, bezahlen und bestätigt danach die Zahlung gegenüber dem PS. Nach erfolgreicher Zahlung fordert der POS den verkauften Artikel beim PS an. Der POS verfolgt den Lieferstatus, und sobald der Artikel zum POS geliefert wurde, übergibt er ihn dem Kunden. Der POS aktualisiert den Lieferstatus der Position, fragt beim PS die Kassenbeleg-Daten an und druckt ihn. Zuletzt sagt der POS dem PS dass es den Verkauf abschließen kann.
In diesem Beispiel reicht der Kunden ein Rezept ein, auf dem ein einzelnes Medikament verordnet ist. Der Kunde wird durch den Apotheker bedient.
Der Verkaufsvorgang wird vom POS gestartet. Er sucht nach dem Eintrag, der den Apotheker beschreibt, der den POS bedient und fügt ihn zum Verkauf hinzu. Wenn der Kunde ein Rezept einreicht, sucht der POS den Patienten, auf den das Rezept ausgestellt ist, in der Personen-Datenbank. Er fügt die Person hinzu und erzeugt dann ein Rezept das auf diese Person verweist. Da der Patient auch der Kunde ist, setzt der POS die gleiche Person als Kunde. Dann sucht er den verschriebenen Artikel und fügt ihn zum Verkauf hinzu. Der Apotheker wird die Lieferung des Artikels überwachen wollen, bevor er den Kunden bezahlen lässt. Deshalb fordert der POS den Artikel vor dem Bezahlen an. Sobald der Artikel geliefert ist, aktualisiert er die Position mit dem Lieferstatus. Dann lässt er den Kunden den Gesamtbetrag zahlen und bestätigt die Zahlung gegenüber dem PS. Zuletzt wird der Kassenbeleg gedruckt und der Verkauf geschlossen.
Die Anwendungsfälle bei der Abholung sind denen der Verkaufs ähnlich. Der Anwendungsfall pickup wird durch die Operationen des Pickup Port-Typs realisiert, search for persons durch den Search Port-Typ und request pickup order durch den Order Port-Typ. Da die Artikel einer Abholung vorher zusammengestellt werden, ist es üblicherweise nicht notwendig, nach ihnen zu suchen (außer, der POS will zusätzliche Artikelinformationen anzeigen die nur über die Suche verfügbar sind).
Das folgende Aktivitätsdiagramm illustriert den Ablauf einer typischen Abholung. Es zeigt nur die Haupt-Operationen.
Alle Aktivitäten außer list articles entsprechen direkt posps-Operationen. Wenn der POS die vom Kunden eingegebene Abholnummer sendet, schickt das PS die Liste der Artikel, die zum Abholauftrag gehören, an den POS.
Das Sequenzdiagramm illustriert die Operationen, die für eine einfache Selbstbedienungs-Abholung durchgeführt werden.
Der POS startet den Abholvorgang nach Aufforderung durch den Kunden. Der Kunde gibt seine Abholnummer ein. (Der Mechanismus, durch den er diese erhalten hat, ist nicht durch die Schnittstelle spezifiziert.) Der POS schickt die Nummer durch den Aufruf vom setPickupCode an das PS. Das PS antwortet mit den Informationen zu den zum Abholauftrag gehörenden Artikeln und dem Preis, den der Kunde bezahlen muss (wenn er nicht bereits beim Anlegen des Abholauftrags bezahlt hat). Der POS lässt den Kunden bezahlen und bestätigt dann die Zahlung gegenüber dem PS. Nach erfolgreicher Zahlung fordert der POS den Abholauftrag an und verfolgt die Lieferung, bis alle zum Abholauftrag gehörenden Artikel geliefert wurden. Dann lässt er das PS den Kassenbeleg erzeugen, druckt ihn, übergibt die Artikel dem Kunden und schließt die Abholung.
