| Subject | Pin Server architecture |
|---|---|
| Author | peter@cyionics.com |
| Post date | 2003-08-15T12:13:16Z |
H Helen
I thought I might bring this discussion over to this group as you suggested from the IBO list as we are now discussing architecture.
I'm a little worried that I may be taking the wrong path so I thought I might explain my reasoning further.
The application is designed to sit on a server in the shops back office, this server will more than likely be running Firebird locally.
There is 1 instance of my application running, it's job is to hold small local pin stock and information, supply POS terminals with pins and info, keep track of pin stock, sales etc.
There are various Prepay Pin numbers for sale in the store each just a printed plastic card with a barcode on and a description of the product.
The tills connect to my application via a TCP socket, there is a sever socket in my application.
The sequence is a follows
The card is scanned and a request for some information sent to my application.
The application then returns the product information requested, description, value etc. as needed.
These are read requests only.
The till can then ask to reserve a product of that barcode type, my application then uses a server side procedure to find and mark as reserved a pin of that type if available.
Finally if the transaction is completed then the till can supply back the unique key id of the pin reserved, this pin is then marked as sold.
The Read, Reserve and Sold operation are all self contained, so they execute quickly and without user intervention, at no time do they hold anything else up.
Furthermore my application also via a VPN network can contact another server that handles the distribution of pins to the shops from the telecom supplier. My application may re-order from here if stocks hit a low trigger level.
other functionality is sales reconciliation, reports etc
So a typical sale might be
Till Server
info 'barcode' value returns Value as string
reserve 'barcode' operator 0 - for fail, unique Pin-ID if successful (ID)
Sell ID 0 for fail , same ID as sent for success
In between each operation other tills can request data.
The traffic down the network to the tills is very small and fast, the tills only request the information they need , and each is a self contained database operation.
The original spec from the client called for a shared file system running over a NetBEUI layer, this worried me and I persuaded them to let me use a database engine , Firebird in this case and I'm so glad I did.
This also gives the client the ability to view the local shops database to resolve problems etc over the internet / VPN.
Can you see any problems with this architecture Helen, or indeed I would welcome comments from anybody else.
Rgds
Peter Cyionics
[Non-text portions of this message have been removed]
I thought I might bring this discussion over to this group as you suggested from the IBO list as we are now discussing architecture.
I'm a little worried that I may be taking the wrong path so I thought I might explain my reasoning further.
The application is designed to sit on a server in the shops back office, this server will more than likely be running Firebird locally.
There is 1 instance of my application running, it's job is to hold small local pin stock and information, supply POS terminals with pins and info, keep track of pin stock, sales etc.
There are various Prepay Pin numbers for sale in the store each just a printed plastic card with a barcode on and a description of the product.
The tills connect to my application via a TCP socket, there is a sever socket in my application.
The sequence is a follows
The card is scanned and a request for some information sent to my application.
The application then returns the product information requested, description, value etc. as needed.
These are read requests only.
The till can then ask to reserve a product of that barcode type, my application then uses a server side procedure to find and mark as reserved a pin of that type if available.
Finally if the transaction is completed then the till can supply back the unique key id of the pin reserved, this pin is then marked as sold.
The Read, Reserve and Sold operation are all self contained, so they execute quickly and without user intervention, at no time do they hold anything else up.
Furthermore my application also via a VPN network can contact another server that handles the distribution of pins to the shops from the telecom supplier. My application may re-order from here if stocks hit a low trigger level.
other functionality is sales reconciliation, reports etc
So a typical sale might be
Till Server
info 'barcode' value returns Value as string
reserve 'barcode' operator 0 - for fail, unique Pin-ID if successful (ID)
Sell ID 0 for fail , same ID as sent for success
In between each operation other tills can request data.
The traffic down the network to the tills is very small and fast, the tills only request the information they need , and each is a self contained database operation.
The original spec from the client called for a shared file system running over a NetBEUI layer, this worried me and I persuaded them to let me use a database engine , Firebird in this case and I'm so glad I did.
This also gives the client the ability to view the local shops database to resolve problems etc over the internet / VPN.
Can you see any problems with this architecture Helen, or indeed I would welcome comments from anybody else.
Rgds
Peter Cyionics
[Non-text portions of this message have been removed]