Integration in das Kassensystem
this section will be revised and adapted for the certified version 2 of the the fiskaly Cloud-TSS!
Der Systemintegrator sollte das SDK auswählen, das für das Kassensystem geeignet ist. Zum Beispiel muss für ein in Java implementiertes Kassensystem das Java-SDK ausgewählt werden.
Technische Anforderungen
| Kategorie | Anforderung |
|---|---|
| Antwortzeiten | 50 - 250ms, abhängig von der Netzwerklatenz |
| Prozessablauf | Asynchron. Start- und Update-Transaction verursachen somit keine Verzögerung im Aufzeichnungssystem. Nur für Finish-Transaction muss auf die Antwort gewartet werden. |
| Service-Funktionen | Idempotent. Ein Vorgang kann beliebig oft wiederholt werden. Der erwartete Seiteneffekt tritt jedoch nur ein einziges Mal ein. |
| Unterstützte Betriebssysteme | Linux, Windows, u.a. (plattformunabhängig) |
Datenvolumen für eine Transaktion
Das Datenvolumen für eine Transaktion ist abhängig vom zu signierenden Payload, jedoch pauschal sehr gering.
Geht man von einem absoluten Minimum an abzusichernden Daten aus, so beträgt das Datenvolumen pro Transaktion << 1 Kilobyte. Ist ein größeres Volumen an Daten abzusichern, zum Beispiel um POSLog Transaktionen vollständig zu erfassen, steigt auch das Datenvolumen. Das Maximum der abzusichernden Daten ist theoretisch unbegrenzt.
Die vollständige Absicherung von POSLog Transaktionen bringt den Vorteil, dass weitere Servicedienste wie z.B. Archivierung oder Accounting die Transaktionsdaten weiter verarbeiten können.
Beispiel eines Payloads: Mindestdaten des Attributs processData für einen processType “Kassenbeleg” lt. Feldspezifikation der DSFinV-K Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar Es ist anzunehmen, dass pro Transaktion 1 kB - 256 kB an zB. Daten übermittelt werden. Je nachdem, ob es sich um einen Kassenbeleg, eine Bestellung (lang andauernder Vorgang) oder anderen Vorgang handelt.
Die Bandbreite kann aufgrund unserer asynchronen Architektur sehr gering sein, z.B. via ISDN. Für den Abschluss einer Transaktion muss jedoch auf die Antwort unseres Systems gewartet werden. Hier ist die Latenzzeit des Netzwerkes die einschränkende Komponente, da die zu übermittelnden Daten ein sehr geringes Volumen einnehmen.
Antwortzeiten
Die Antwortzeiten der fiskaly cloud werden maßgeblich durch die Latenzzeiten der Netzwerkanbindung beeinflusst. Innerhalb der fiskaly cloud können wir in unserem Testsystem zur SIGN DE API (KassenSichV) bereits Antwortzeiten von durchschnittlich 64 ms aufweisen. Zu beachten ist, dass das Testsystem noch nicht auf Durchsatz optimiert ist. Es können Antwortzeiten von unter 50 ms in unserem Produktivsystem erwartet werden.
(Screenshot eines fiskaly Cloud-TSE Testdurchlaufs)
Zu berücksichtigen ist die Latenzzeit der Netzwerkanbindung des Integrators an die Rechenzentren der fiskaly cloud. Aktueller Standort der fiskaly cloud Infrastruktur ist Frankfurt am Main (redundant), weitere Standorte können bei Bedarf zum Beispiel in Düsseldorf und München zur Verfügung gestellt werden.