Bestellungen, Subscriptions, Produkte und mehr

Subscriptions und Orders

Zunächst ist es wichtig zwischen einer Subscription (=Abo) und einer Order (=Bestellung) zu unterscheiden. Im Folgenden verwenden wir die englischen Begriffe, weil diese auch in der Swagger-Doku genutzt werden.

Die Subscription spiegelt einen gewissen Lizenzumfang für einen Softwareservice wider. Die Lizenzen sind letztendlich bestellbare Produkte. Als Beispiel kann man eine Subscription für das Portfolio SwyxON erzeugen. Die Subscription enthält dann bspw. 5 Basic-User und 10 Premium-User. SwyxON kann folgend für diese Anzahl User / Lizenzen (=Produkte) genutzt werden.

Der Produktumfang der Subscription kann jederzeit verändert werden.

Technisch wird die Subscription mit einer Order erzeugt. Es ist auch möglich mit einer Order mehrere Subscriptions gleichzeitig zu erzeugen.

Die Subscription kann jederzeit mit einer weiteren Order in ihrem Produktumfang verändert werden (=Bestelländerungen). Eine existierende Subscription kann weiterhin mit einer Order terminiert werden.

Beim Erstellen einer Subscription wird auch ein Startdatum angegeben ("wish-date"), dieses Startdatum kann auch das heutige Datum sein. Zum Startdatum wird die Subscription "ausgeliefert". D.h. das ist der Zeitpunkt ab dem die Subscription kostenpflichtig wird und der bestellte Produktumfang der Subscription genutzt werden kann.

Solange eine Subscription noch nicht ausgeliefert ist, verursacht sie also keine Kosten und kann in diesem Zustand mit einer Order gecancelt (abgebrochen) werden.

Produkte

Wie oben beschrieben, kann ein Produkt einer nutzbaren Lizenz gleichgesetzt werden. Die Subscription beinhaltet also aus bestellte Produkte. Die Produktmenge der Subscription kann mit Orders verändert werden.

SubscriptionLine

Damit erklärt sich der Begriff der SubscriptionsLines. Eine SubscriptionLine beschreibt beschreibt wieviele Produkte eines bestimmten Typs in einer Subscriptions enthalten sind.

Auf das Beispiel von oben zurückgreifend, bei dem eine Subscription für SwyxON 5 Basic-User und 10 Premium-User beinhaltet, würde die Subscription also aus 2 SubscriptionLines bestehen:

• SubscriptionLine 1: 5x Basic
• SubscriptionLine 2: 10x Premium

Jeder SubscriptionLine ist mit einer eindeutigen SubscriptionLine uuid versehen.

Um Produkte eindeutig benennen zu können, wird jedem Produkt eine eindeutige ID zugeordnet. Dies sind die product uuids. Diese product uuids sind für jeden Wholesaler eindeutig, aber unterschiedlich. D.h. ein Wholesaler A hat z.B. für die Basic User die product uuid X, ein anderer Wholesaler B hat für die Basic User jedoch die product uuid Y.

Damit ergibt sich, dass die product uuids zunächst via API am Operator abgefragt werden müssen. Die product uuids sind in sogenannten Catalogs organisiert, die bestimmte Mengen von product uuids enthalten. Letztendlich lassen sich mit Catalogs also Produkte organisieren (z.B. ein Catalog mit SwyxON Produkten, ein Catalog mit Enreach Contact Produkten usw.).

Product uuids sind also pro Wholesale Account unterschiedlich, aber immer eindeutig. Die product uuids müssen für den Kontext eines Endkunden des Wholesalers abgefragt werden. Jedem Konto im Operator, und damit jedem Kunden im Operator ist ebenfalls eine eindeutige uuid, die account uuid zugeordnet.

Initiale Produkte

Die "initialen Produkte" kann man sich als "Hauptprodukte" vorstellen, denen weitere Produkte zugeordnet sind. Beispielsweise ist ein SwyxON Server ein solches initial product. Diesem SwyxON Server sind dann Produkte zugeordnet, wie die Benutzertypen Basic-, Professional- und Premium-Benutzer, aber auch die Add-Ons System Phone-Produkt, Swyx Direct for MS Teams-Produkt usw.

Relationen / Validierung

Hier ist zu erkennen, dass es durchaus gleichnamige Produkte gibt, die jedoch unterschiedliche product uuids haben, weil sie unterschiedlichen, initialen Produkten zugeordnet sind. Ein Beispiel ist der Basic-Benutzer. Diesen gibt es in 3 verschiedenen Varianten, dementspr. gibt es 3 verschiedene product uuids für ihn. Die 3 Varianten sind notwendig, weil der Basic-Benutzer im Kontext der 3 verschiedenen initialen Produkten SwyxON Server, Swyx Flex Server und Swyx Kauf Server bestellt werden kann.

Neben obengenannter Zuordnung von Produkten zu initialen Produkten, können auch andere Beziehungen/Relationen der Produkte untereinander definiert werden. Es kann z.B. via API definiert und abgefragt werden wie häufig ein Produkt B bestellt werden kann, wenn ein Produkt A bestellt ist. Es kann auch deklariert werden, dass Produkt B zwingend bestellt werden muss, wenn Produkt A bestellt ist.

Ein gutes Beispiel dafür sind die Konferenzräume der SwyxWare. Eine Swyx-Subscription wird immer eine Anzahl Konferenzräume enthalten, die genau der Summe der Professional- und Premium-Benutzer entspricht. D.h. wenn Sie die Anzahl der Professional- oder Premium-Benutzer einer Swyx-Subscription verändern, müssen Sie gleichzeitig die Anzahl der Konferenzräume auf die Summe beider nachjustieren, ansonsten wird beim Bestellvorgang die Validierung dieser Regel fehlschlagen und die Bestellung abgelehnt werden.

Sämtliche Relationen der Produkte untereinander können via API zu Beginn ermittelt werden. Die Einhaltung dieser Regeln garantiert, dass Sie nur valide Bestellungen aufgeben.

Bestellungen / Mutations

Wie genannt, können Subscriptions mit Orders=Bestellungen erzeugt und verändert werden. Diese Subscription-Veränderungen werden Mutation genannt. Jeder Mutation ist eine eindeutige uuid zugeordnet.

An einer Subscription können die vorhandenen Mutations abgefragt werden. Eine Mutation hält den Status nach, sowie den Zeitpunkt wann sie erzeugt wurde, wann sie ausgeliefert wurde usw. Via der Mutationsliste, die auf einer Subscription abgefragt werden kann, als auch der via dieser vorgenommenen Orders kann also die komplette Historie einer Subscription von ihrer Erstellung, über ihre Veränderungen, bis zu ihrer Terminierung nachverfolgt werden. Sowohl Status, Zeitpunkt und Produktmenge der Subscriptions sind so lückenlos recherchierbar.