Transaction server is a different mode of Data Director which is interactive. When running in Transaction Server mode, the Data Director behaves differently from the regular Data Director mode. In Transaction Server mode, the functionality is greatly reduced and a log database is not required.
The Transaction server works as a service which reads the data from source database and takes that data to the destination database; creates the connection with destination database and writes the data into destination database. Using transaction server, it is not possible to have different services to read data from source database and write data into destination database.
The Transaction server does not create packages of data and this is the reason why the transaction server does not use a log database to keep track of data packages.
The Transaction server is an interactive mode of Data Director which can make queries to remote database and can get the results. Transaction server is able to send data to remote database. The main reason for running the Data Director in Transaction Server mode is to allow the LS Retail POS to communicate with remote databases. This allows the POS Terminals to look up the data such as customer balance and stock availability from a central database.
The Transaction Server allows the LS POS to make queries to the Back Office database when the LS POS is configured to run offline.
Before the transaction server functionality can be activated on the POS, LS Data Director service is required to run in transaction server mode on the same network. The Transaction Server can also be used over a Wide Area Network (WAN) but the performance will be slower. It can be used for special queries.
If at any point of time, the transaction server service is not working, the information of the transactions which are to be sent to a remote database is kept in the source database in table 99001615 – Trans.
Server Work Table. When the connection is re-established using the transaction server service with a
remote database, it will send the pending transactions to the remote database first. For example - When the user logs on the POS or posts any transaction and finds the transaction server working, pending data will be sent to remote database.
For example – in the below diagram, there are two transaction servers (TSs) added; one at the central database and one at the Navision node.
FIGURE 5.6 -1: TRANSACTION SERVER ARCHITECTURE
LS Retail
LS Retail
Scheduler DD Client OCXDD Client
LS Retail
POS
DD
Navision
TS
Scheduler DD Client OCXDD
Central
LS POS.Net
DD: Data Director
TS : Transaction Server
TS
Navision
DD
MS SQLIn this example, the LS Retail system at the node (may be POS or store) can open up a connection to the central database and make queries as if the central database was local to it. This has an advantage of being faster than to connect remotely using the normal Microsoft Dynamics NAV method. Similarly, all POSs connect to the local database through the TS saving the concurrent number of users which need to be available since the TS handles all the requests through one connection.
Whenever immediate online information is needed or needs to be updated, the TS should be used. Prerequisites for transaction server
1. One DD Service should be created in transaction server mode.
2. Setup needs to be done at LS Retail - POS, Profiles, Functionality; select the Trans. Server tab.
FIGURE 5.6 -2: FUNCTIONALITY PROFILE
Different options for selecting the type of transactions and the remote server with which the transaction server should communicate are defined in the table below.
To activate a function, place a check mark in front of the relevant line and select a distribution location that contains all the necessary connection parameters that the Transaction Server requires in order to process the request. The distribution location is the remote server to which that type of query should be made.
Note
This must be done on each POS (if the POS is offline) that will use the Transaction Server, and distribution location for the remote database should be defined with distribution server as transaction server service.
Transaction
type Description
Send Transaction
At the end of a sale, when a transaction is posted to the POS database, it is also pushed to the remote database defined in the send transaction server. If the remote database is unavailable, the transaction will only be stored in the POS database. When the remote database becomes available, all unsent transactions will be sent at once. Please note that the system does not detect when the remote database becomes available. This will be triggered when connection will be created with remote database using transaction server.
Void Posted Transaction
At the end of voiding the transaction, transaction is posted to the POS database; it is also pushed to the remote database being defined in void posted transaction server database.
Suspend - Retrieve Transactions
Suspend - When the suspend button is pressed on the POS, the POS
Transactions and related lines are sent to the specified remote database.
Retrieve-When the cashier requests a list of suspended transactions from the
remote database, only the headers are sent back to the local database.
After selecting a specific POS Transaction from the list, the whole transaction is requested from the server. If successful, the transaction is deleted from the remote database. The transaction is now only available on the POS and can be finalized, suspended again, etc.
If it is not possible to suspend the transaction to a remote database, the POS will suspend it locally.
If it is not possible to retrieve the transaction from the remote database, the POS will display an error. There can be two reasons for this. One is that the suspended transaction is stored in the remote database and cannot be retrieved. In this case the customer has no other option than to rescan the items. The second reason is that the POS that suspended the transaction was unable to store it in the remote database. In this case the customer must return to the POS Terminal where the transaction was last suspended in order to retrieve it.
Customer
The cashier selects the customer to check. The POS sends a request for the updated status of the customer. The results of this query are written to the POS database. From here, the transaction proceeds normally. If the customer is blocked or has exceeded his balance, the standard POS application will take the appropriate action.
Since this is a query to the remote database, error handling is rather simple. If the remote database is unavailable, the POS will use the values stored in the POS database.
If connecting to the database fails, it is possible to specify a secondary server for this request as backup.
Data Entries
Create-Entries are created as before. It is important that unique initial numbers are set up for each POS.
After finishing the sale, an attempt is made to send the entry to the remote database. If the attempt fails, the Replication Counter is used to mark the entry. Otherwise, if there are previous entries which could not be sent, an attempt is made to send them. If successful, the Replication Counter is set to 0 (zero). Apply-The Transaction Server attempts to fetch the entry from the server. If successful, the entry is marked with the terminal number and sent back to the
remote database (to prevent others from being able to apply it during the sale). If unsuccessful an error is displayed, and the user is prompted to either retry, or abort. A user with manager privileges or with the value Continue on TS Error set in the Staff card retries and the attempt fails again the entry is accepted. An entry is inserted into the POS's local database where amount is set to 0, and the applied amount is the amount entered.
If the entry on the server was already reserved by another POS, an error is displayed. A manager is able to circumvent this error.
After posting the sale, an attempt is made to send the entry (same as above). If the entry has 0 in the amount field, the entry is read from the server, and the Original Amount value is added to the entry.
If the update is unsuccessful, the entry is handled in the same way as in (a).
Staff validation
The POS sends a request to the Transaction Server, asking for the status of the staff member. The Transaction Server copies the corresponding staff record to the POS database. Once the staff record has been copied, the POS application will process the data locally. The POS application will first check whether the staff member is blocked. If so, the staff member cannot log on to the POS.
If the POS is unable to get answers from the Transaction Server, the POS uses the Staff information in its local database to determine whether logon is allowed or not.
Floating Cashier
The POS sends a request to the Transaction Server, asking for the status of the floating cashier.
Inventory Lookup
This field is used to get Inventory Lookup with Transaction Server.
The command in question does not work in the normal sales menu. It only works in the lookup menu, and only so when an Item lookup or Variant lookup is done. One thing need to make sure that a special Lookup table is updated for this
purpose in the head office Database (or the one where the query will be made). For which product groups the Lookup should work need to be specified and after doing so, it need to be enabled for each store. This will trigger an update on the table Lookup table.
The Lookup table should be updated regularly, either manually or automatically (from the Scheduler), at least each time a new Item, or store is added.
Login Staff
A check mark in this field indicates that the system will use the Transaction Server and the location in field Login Staff for login/logout from POS in the Time Registration Module.
Serial No. Check
A check mark in this field means that the Transaction Server Serial Number check is enabled for this POS. Transaction server will check for the validity of the serial number entered at POS in the remote database.
Loyalty
This field contains the ID of the distribution location to or from which Loyalty points are sent. If this field is enabled, it means that the loyalty points will be sent using transaction server to remote database.
Online Trans. Backup
A check mark in this field means that the Online Transaction Backup is in use for this POS. Transaction server will keep the backup of transactions using transaction server in remote database being mentioned in “online trans. Backup server”.
POS Cash Mgt
A check mark in this field means that the information required for cash management is retrieved from remote database server using transaction server.