Beschreibung der Lösung

Mit dem "oxaion Cloud Native" Angebot stellt Aptean das oxaion ERP-System in einer überwachten Cloud-Infrastruktur bereit. 

Infrastruktur

Aptean betreibt das Angebot auf Basis der "Software as a Service"-Infrastruktur von Microsoft Azure. 

Application Server

• Aptean betreibt oxaion in einem zentralen, virtualisierten Kubernetes-Cluster
• Jeder Kunde erhält innerhalb des Kubernetes-Clusters einen eigenen, isolierten Namespace. Jeder Kunde ist also systemtechnisch strikt getrennt
• Für jeden Kunden werden 3 oxaion Umgebungen betrieben (Produktiv, Staging (=Test) und Entwicklung)
• Die Produktivumgebung wird permanent betrieben. Staging und Entwicklung werden nur bei Bedarf hochgefahren und nach einiger Zeit an Inaktivität automatisch von Aptean heruntergefahren
• Jedem Kunden stehen im Namespace definierte Hardware-Ressourcen in Abhängigkeit des gewählten Subscription-Modelles (siehe unten) zur Verfügung. 
• Der Einsatz mehrerer paralleler Application-Server ist ab den Subscription-Modellen "L" möglich.
• Der Kubernetes-Cluster wird in der Region "Germany West Central" (=Rechenzentrum Frankfurt) betrieben. Ist das Rechenzentrum in dieser Region nicht verfügbar, erfolgt der Betrieb am lokal nächsten verfügbaren Standort innerhalb der europäischen Union.
• Die physischen Nodes sind mit aktuellen Server-Prozessoren und gängigen Taktfrequenzen ausgestattet.
• Aptean überwacht die Auslastung der physischen Nodes und fügt weitere Hardware zum Cluster hinzu, sobald die CPU-Reserven nicht mehr ausreichen.

Datenbank

• Als Datenbank wird die "Database as a Service"-Datenbank "Microsoft Azure SQL Server" eingesetzt.
• Jeder Kunde erhält eigene und von anderen Kunden isolierte Datenbanken mit eigenen Zugangsdaten.
• Die Datenbanken werden in einem Elastic Pool betrieben, d.h., die Datenbanken werden auf geteilten Hardware-Infrastruktur betrieben.
• Die Größe der Datenbank ist in Abhängigkeit des Subscriptions-Modelles begrenzt (siehe unten).
• Die Datenbank speichert alle Daten verschlüsselt.

Client

• Der oxaion Client wird über das öffentliche Internet vom oxaion Application Server heruntergeladen und auf dem lokalen PC des Anwenders ausgeführt.
• Dazu kommt die oxaion Webstart-Technologie zum Einsatz, um den oxaion Client automatisiert auf die PCs der Anwender auszurollen und aktuell zu halten
• Die oxaion Webstart-Technologie setzt eine lokale Java-Installation auf dem Client-PC in der jeweils aktuellsten Version voraus. Installation und Verwaltung der Java-Installationen liegt in der Verantwortung des Kunden
• Die Kommunikation zwischen Client und oxaion Server erfolgt verschlüsselt über HTTPS (SSL).
• Jeder Kunde erhält je Umgebung eine kundenspezifische URL (z. B. https://jet.kundenname.nucleus.apteancloud.com), über die der Client heruntergeladen und betrieben wird
• Optional kann der Kunde über ein Support-Ticket veranlassen, dass die URL / IP-Adresse nur für bestimmte IP-Ranges freigegeben wird. Damit kann dann z. B. gesteuert werden, dass der oxaion Client nur aus einem bestimmten Unternehmentsnetz heraus nutzbar ist. So kann die Sicherheit weiter erhöht werden.

Nucleus-Client

• Optional kann der Nucleus-Client (= Webbrowser) verwendet werden. Nucleus ist ein kostenpflichtiges Zusatzprodukt und muss separat erworben werden.

Speicherplatz für Dokumente

• Jede Umgebung wird mit zwei Speicherplätzen ausgestattet.
• Speicherplatz 1 "shared" ist maximal 1 GB groß und wird zur temporären Speicherung von Druckausgaben verwendet und für die Speicherung von oxaion Reports.
• Speicherplatz 2 "data" ist abhängig vom gewählten Subscription-Modell (M, L oder XL). Er wird zur Speicherung von Konfigurationen (z. B. Design-Modus), sowie für die Speicherung von DMS-Dokumenten verwendet.
• Benötigt ein Kunde mehr Speicherplatz für DMS-Dokumente, muss zusätzlicher Speicher nachgekauft werden.

Authentifizierung

• Benutzer können ausschließlich über Microsoft Entra ID authentifiziert werden. Die Einrichtung und Verwaltung des Microsoft Entra ID Accounts liegt ausschließlich in Kundenverantwortung.
• Es gelten somit automatisch die vom Kunden gewählten Einstellungen zur Sicherheit, z. B. zur Passwort-Komplexität oder der Zwei-Faktor-Authentifizierung.

Bandbreite / Netzwerkgeschwindigkeit

• Die benötigte Bandbreite ist abhängig vom Anwenderverhalten. Werden z. B. viele DMS-Dokumente gespeichert oder geladen, ist eine deutlich höhere Bandbreite notwendig.
• Für den Regelbetrieb ohne DMS-Dokumente sind pro Benutzer ca. 100 Kilobit (downstream + upstream) bereitzustellen.
• Jedes der beiden Rechenzentren ist redundant an das Internet-Backbone angeschlossen.
• Auch für Kunden empfiehlt sich, die eigene Internetanbindung redundant zu betreiben (z. B. mit zwei getrennten Hauszuführungen, redundanten Routern, usw.).

Drucken auf physischen Druckern

• oxaion verwendet ein serverseitiges Drucksystem. Damit dieses auf lokalen Druckern nutzbar ist, wird das Produkt "Aptean Cloud Printing" im Zuge der oxaion Installation im lokalen Netzwerk des Kunden installiert (Mitwirkung des Kunden erforderlich)

Mailversand

• Alle von oxaion ausgehenden E-Mails werden über SMTP versendet. Der Kunde muss dazu einen SMTP-Server bereitstellen, der über das öffentliche Internet (= mit einer öffentlichen IP-Adresse oder Domain-Namen) angesprochen werden kann. Bereitstellung und Konfiguration des SMTP-Servers liegen in Kundenverantwortung. Weitere Informationen und Details finden Sie unter E-Mail Versand in der Cloud per SMTP Server.

Subscription-Modelle

Die Subscription-Modelle unterscheiden sich in Bezug auf die bereitgestellten Hardware-Ressourcen und die Anzahl an parallel betriebener (=skalierter) oxaion Application Server. Da allerdings nicht (nur) die Anzahl der Benutzer, sondern vor allem das Verhalten der Benutzer (= wie arbeiten die Benutzer mit dem System) Einfluss auf die notwendige Hardware und die Performance hat, lässt sich nur ungenau prognostizieren, wie viele Benutzer mit welchem Modell arbeiten können. Es kann also sein, dass ein Kunde mit 40 Usern bereits im Modell "M" verschlechternder Performance erhält, während ein anderer Kunde mit 70 Usern noch optional mit dem Modell "M" arbeiten kann. 

Ein Wechsel von einem kleineren in ein größeres Modell ist jederzeit möglich. Es empfiehlt sich daher "klein" zu starten und dann zu wachsen.

Modell "M"

Ausgelegt für etwa 50 Benutzer

Modell "L"

Ausgelegt für etwa 125 Benutzer

Modell "XL"

Ausgelegt für etwa 250 Benutzer

Weitere Modelle

Auf Anfrage / Bedarf entwickeln wir gerne mit Ihnen gemeinsam weitere Modelle für größere Szenarien. Bitte sprechen Sie uns an

Backup

• Da die Umgebung auf hochverfügbarer Hardware betrieben wird, ist das Backup hauptsächlich für fachliche Rücksicherungen auf Wunsch / Veranlassung des Kunden vorgesehen.
• Es wird das data-Verzeichnis mit den Datei-Dokumenten (z. B. DMS-Dateien, kundenspezifischen Einstellungen), sowie die Datenbank unabhängig voneinander gesichert und zurückgespielt
• Datei-Sicherung im Produktivsystem:
  • Jede Nacht um 24:00 Uhr UTC werden die Dateien gesichert.
  • Es werden die letzten 7 Tage aufbewahrt und anschließend rollierend überschrieben.
  • Jede Sonntags-Sicherung wird 8 Wochen lang aufbewahrt und anschließend rollierend überschrieben.
  • Jede Monats-Sicherung (1. des Monats) wird 12 Monate lang aufbewahrt und anschließend rollierend überschrieben.
  • Jede Jahres-Sicherung (1.1.) wird 5 Jahre lang aufbewahrt und anschließend rollierend überschrieben.
• Datei-Sicherung im Test- und Entwicklungssystem:
  • Jede Nacht um 24:00 Uhr UTC werden die Dateien gesichert
  • Es werden die letzten 7 Tage aufbewahrt und anschließend rollierend überschrieben
• Datei-Sicherungen können auf Einzel-Dateibasis zurückgesichert werden. Dies erfolgt nach Stellung eines Tickets durch den Kunden.
• Datenbank-Sicherung im Produktivsystem:
  • Es erfolgt eine permanente "Point in Time" Sicherung der letzten 7 Tage.
  • Jede Sonntags-Sicherung wird 8 Wochen lang aufbewahrt und anschließend rollierend überschrieben.
  • Jede Monats-Sicherung (1. des Monats) wird 12 Monate lang aufbewahrt und anschließend rollierend überschrieben.
  • Jede Jahres-Sicherung (1.1.) wird 5 Jahre lang aufbewahrt und anschließend rollierend überschrieben.
• Datenbank-Sicherung im Test-Entwicklungssystem:
  • Es erfolgt eine permanente "Point in Time" Sicherung der letzten 7 Tage.
• Datenbank- und Dateisicherung sind Geo-Redundant (sowohl im Test- als auch im Produktivsystem), d.h., sie werden in zwei Rechenzentren gespeichert (im Normalfall in "Germany West Central" (Frankfurt) und "Europa Westen" (Amsterdam). Weiter gelten die oben gemachten Anmerkungen bzgl. Verfügbarkeit der Rechenzentren.
• Das Backup wird verschlüsselt gespeichert.
• Kunden können nicht direkt auf das Backup zugreifen. Das Backup wird vollständig von Aptean "gemanaged".

Disaster Recovery

• Abbrüche oder Neustarts des Application Servers führen zu einem temporären Logout der Benutzer, die anschließend den oxaion Client neu starten müssen um sich neu anzumelden.
• Die Kubernetes-Cluster basieren auf mehreren physischen Nodes, so dass Hardwareausfälle in der Regel nicht zu einem Ausfall der Cluster führen, sondern 'maximal' den automatischen Neustart des Application Servers auf einem anderen Node veranlassen (=kurze Downzeit zwischen 30 Sekunden und 5 Minuten mit der oben beschriebene Auswirkung auf Benutzer).
• Für den unwahrscheinlichen Fall eines kompletten Ausfalls des gesamten Rechenzentrums, werden die Kubernetes-Cluster und Datenbanken automatisch in der 2. Verfügbarkeitszone hochgefahren. Dies kann zu Downzeiten von mehreren Minuten bis zu vier Stunden führen.

Patches und Kundenmodifikationen

• Aptean spielt Patches an der Infrastruktur (z. B. Betriebssysteme, Kubernetes, Datenbanken, Sicherheitsupdates) selbständig und regelmäßig durch. Diese erfolgen in der Regel ohne "Downzeit". 
• Sollte für einen Infrastruktur-Patch eine Downzeit notwendig sein, wird der Patch Samstags zwischen 6 und 12 Uhr CET eingespielt. Kunden werden zuvor per E-Mail darüber hinformiert. Solche Downzeiten werden auf maximal 6 pro Jahr begrenzt.
• Patches des ERP-Systems werden nach Zuruf und Auftrag des Kunden eingespielt. Dabei wird zuerst die Testumgebung aktualisiert und muss anschließend durch den Kunden getestet werden. Nach Kundenfreigabe erfolgt dann die Übernahme in das Produktivsystem.
• Das Einspielen und Aktivieren von oxaion Patches erfolgt ausschließlich durch Mitarbeiter der Aptean.
• Der Kunde kann maximal ein Mal pro Jahr das Einspielen eines ERP-Patches anfordern.
• oxaion stellt auch im Cloud-Betrieb die Möglichkeit bereit, beliebige Kundenmodifikationen vorzunehmen. Allerdings ist dies ausschließlich durch Mitarbeiter der Aptean möglich. Eine Entwicklung durch Mitarbeiter / Personen des Kunden ist nicht vorgesehen

Betrieb und Datenschutz

• Aptean überwacht die Systeme 24x7 in Bezug auf technische und Infrastruktur-Fehler. 
• Eine fachliche Überwachung und aktive Fehlerbeseitigung (z. B. nicht laufende oxaion Asynchron-Jobs) erfolgt Mo-Fr. zw. 08:00 und 17:00 Uhr deutscher Zeit
• Erfasst ein Kunde ein Ticket über das Ticket-Portal, wird dieses von Mo-Fr. zw. 08:00 und 17:00 Uhr deutscher Zeit überwacht und bearbeitet.
• Die technische Überwachung der Systeme erfolgt durch internationale Mitarbeiter und Standorte der Aptean (z. B. auch über USA und Indien).
• Aptean legt dabei selbstverständlich die mit jedem Kunden getroffenen Datenschutzvereinbarungen zu Grunde.

System-Verfügbarkeit / SLA

Zur Gesamtlösung gehören unterschiedliche Komponenten und Dienstleistungen, die unterschiedliche Verfügbarkeitszeiten besitzen. Aptean definiert für die einzelnen Teile jeweils einzelne Verfügbarkeiten. In Abhängigkeit der vom Kunden gewählten Betriebszeiten und ERP-Konfigurationen kann die Netto-Verfügbarkeit durch den Kunden beeinflusst werden (kostenpflichtige Zusatzkonfiguration). In der Standard-Konfiguration arbeitet oxaion mit einem nächtlichen "exklusiven Tagesabschluss". Während dieser Zeit ist das oxaion ERP-System fachlich nur eingeschränkt verfügbar (z. B. sind keine dispositionsrelevanten Daten oder Prozesse verfügbar)

1. Verfügbarkeit der URLs, der Webserver und der Kubernetes-Cluster: 99,5%
2. Verfügbarkeit der Datenbank: 99,5%
3. Brutto-Verfügbarkeit des oxaion ERP-Systems: 99%
4. Die Netto-Verfügbarkeit des ERP-Systems ist Abhängig von der Dauer des Tagesabschlusses (siehe oben).

Geplante und angekündigte Service- oder Patch-Zeiten sind von den Verfügbarkeitszeiten ausgenommen.

Bitte beachten Sie, dass die Service- und Monitoring-Zeiten deutlich geringer sein können. Tickets und Störmeldungen werden nur während der Service-Zeiten bearbeitet.

Funktionale Restriktionen