worm_init() - wie oft ?

[ISMIRSCHLECHT]

Hi,

beim theoretischen Aspekt der Mehrfachzugriffs auf die TSE von mehreren Rechnern aus ergab sich eine Frage:
Ein mehrfaches worm_init() muß fehlschlagen, das ist klar.
Es sei denn, ich gebe den Context nach getaner Arbeit (Transaktion, Information) jedes Mal wieder frei mit worm_cleanup()
Macht man das, kann man das (socher KANN mans), soll oder muß man das ?
Ich richte den Context und die Worminfo am Anfang ein und tschüss.
Bis jetzt ist geplant, daß nur ein Rechner/Kasse auf den TSE schreibt, aber gesetzt den Fall einer Mehrkassennutzung...

Was denkt Ihr da so ?
ism

[herbstrot]

Moin,

das Init kann nur einmal gemacht werden (Finale TSE).
Bei Mehrfachnutzung muss der Client auf der TSE registriert werden ohne ein nochmaliges Init.

worm_cleanup() nutzen wir überhaupt nicht, da unsere Klasse bei jeder Aktion erstellt und danach wieder freigegeben wird.

[Neumann]

Ich plane dafür einen TSE-Server, der dann auf einem Rechner als Dienst läuft.

Kommunikation über HTTP/Rest.

Verwende für solche Sachen TMS-XData, damit ist es sehr einfach.

[hhcm]

Zitat von herbstrot:

worm_cleanup() nutzen wir überhaupt nicht, da unsere Klasse bei jeder Aktion erstellt und danach wieder freigegeben wird.

Und was steht im Destructor der eigenen Klasse?

Zitat:

Ich plane dafür einen TSE-Server, der dann auf einem Rechner als Dienst läuft.

Das habe ich gestern irgendwo gelesen, das sollte auch der richtige Weg sein. Es soll leute geben die auf einem PC die TSE als Netzlaufwerk freigeben.
Bei einem Selbsttest (welcher ja mal gut und gerne 20 Sek. dauern kann) würde ein anderer Client einen I/O Fehler bekommen. Da ist es sinniger einen "Server" zu schalten der eine art queue abarbeitet.

[DeddyH]

Zitat von hhcm:

Zitat:

Ich plane dafür einen TSE-Server, der dann auf einem Rechner als Dienst läuft.

Das habe ich gestern irgendwo gelesen, das sollte auch der richtige Weg sein

Das ist ja lustig, ich war am Montag bei Epson und habe da erwähnt, dass wir das genau so machen. Da sagte man mir, dass sie davon zum ersten Mal hören, die Idee aber gut finden.

[hhcm]

Gefunden

https://support.gastro-mis.de/suppor...cs/36000014164

[ISMIRSCHLECHT]

Hi,

hab ich auch gelesen und daraufhin diese Frage gestellt.
Ich mache es als Middleware, die einen TCPIP-Server darstellt und somit nur eine TSE braucht.
Zugriffe natürlich gegenseitig verriegelt, denkt auch an den Timerthread !
ism

[arnof]

Zitat von Neumann:

Ich plane dafür einen TSE-Server, der dann auf einem Rechner als Dienst läuft.

Kommunikation über HTTP/Rest.

Verwende für solche Sachen TMS-XData, damit ist es sehr einfach.

Also, nach interner Rücksprache können wir unseren REST-TSE Server gerne anderen Kassenherstellern anbieten:

unterstützt folgende TSE's:

- swissbit TSE
- Epson Drucker TSE
- Epson USB TSE
- Cryptovision (Bundesdruckerei)

Der Dienst ermöglich den Zugriff von bis zu 100 Kassen pro TSE (empfohlen 10-20 Kassen pro TSE).
Der Dienst ersetzt auch den angekündigten LAN Server von swissbit, d.h. keine weitere Hardware oder VM nötig.

Der Dienst stellt einen REST Server zur Verfügung und kann auch per SSL genutzt werden.

Kosten pro TSE 50 EUR, wer Interesse hat kann ein PN senden.

Integration in Ihr Delphiprojekt: ab Berlin komplettes natives Delphibeispiel mit allen Funktionen und Quelltext ist an einem Tag einblindbar! Für ältere Versionen, die kein Json unterstützen bieten wir eine DLL die alle Funktionen kapselt und ebenfalls schnell eingebunden werden kann.

Des Weiteren bieten wir in Kürze auch Prüfsoftware an.

[Neumann]

Zitat:

Also, nach interner Rücksprache können wir unseren REST-TSE Server gerne anderen Kassenherstellern anbieten:

Kommt leider zu spät, jetzt ist fast fertig. Wird auch teuer, wenn man das für z.B. für 500 Kunden braucht.

[arnof]

Zitat von Neumann:

Zitat:

Also, nach interner Rücksprache können wir unseren REST-TSE Server gerne anderen Kassenherstellern anbieten:

Kommt leider zu spät, jetzt ist fast fertig. Wird auch teuer, wenn man das für z.B. für 500 Kunden braucht.

So ist das , ist auch teuer in der Entwicklung.