The system integrator should select the SDK that is appropriate for the POS system. For example, for a POS system implemented in Java, the Java SDK must be selected.
|Response times||50 - 250ms, depending on the network latency|
|Process flow||Asynchronous. Start and update transactions therefore do not cause a delay in the recording system. Waiting for a response is required only for a Finish transaction.|
|Service functions||Idempotent. A process can be repeated as often as required. However, the expected side effect occurs only once.|
|Simultaneously opened transactions per TSS||unlimited|
|Supported operating systems||Linux, Windows, etc. (platform independent)|
The data volume for a transaction depends on the payload to be signed, but it is very low across the board.
Assuming an absolute minimum of data to be secured, the data volume per transaction is << 1 kilobyte. If a larger volume of data needs to be secured, for example, to completely record POSLog transactions, the data volume also increases. The maximum amount of data that can be backed up is theoretically unlimited.
The complete protection of POSLog transactions has the advantage that other services such as archiving or accounting can process the transaction data.
Example of a payload: Minimum data of the attribute processData for a processType "cash voucher" according to the field specification of DSFinV-K
Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar. It can be assumed that 1 kB - 256 kB of data are transferred per transaction, depending on whether it is a cash voucher, a purchase order (long-lasting transaction) or another transaction.
Due to our asynchronous architecture, the bandwidth can be very low, e.g., comparable to ISDN. To complete a transaction, however, you must wait for our system to respond. Here, the network latency is the limiting factor, since the data to be transmitted takes up a minimal volume.
The response times of the fiskaly cloud are significantly influenced by the latency of the network connection. Within the fiskaly cloud, response times average 64 ms in our test system for KassenSichV. Please note that the test system is not yet optimized for performance. Response times of less than 50 ms can be expected in our production system.
(Screenshot of a fiskaly Cloud-TSS test run)
The latency of the network connection of the integrator to the data centers of the fiskaly cloud must be taken into account. The current location of the fiskaly cloud infrastructure is Frankfurt am Main (redundant). Further locations can be provided if required, for example in Düsseldorf and Munich.
The number of simultaneously opened transactions per TSS is not limited in the fiskaly cloud. Any number of transactions can be kept open.