You can configure groups of terminals to operate in permanent offline mode even when the terminals are able to connect to the application server. When the terminals operate in this mode, all transactions are collected and stored locally on the terminal. The terminal will not attempt to send any transactions to the application server. The terminals will remain in this mode until their Operating State changes (manually or by a scheduled service). When a terminal’s Operating State changes, the terminal will send the offline data to the application server, even though its Operating Mode is offline.
This configuration is designed to accelerate the data collection process by eliminating or reducing database queries and data processing time. The offline data will be sent to the application server only during scheduled times, via a service instance.
For example, a facility may have a large number of employees clocking it at the start of a shift. To expedite this process, the clock-in terminals will be set to operate in COMPLETE_OFFLINE mode. In this mode, transactions will continuously be collected and stored locally on the terminal. The terminals will make no attempt to send the data to the application server, even though the terminals have a valid connection to the application server. Data collection will happen more quickly because the transactions are not being transmitted and validated.
The Operating State of the terminals will determine when or if the offline data is sent to the application server for processing. For one hour before and one-half hour after the shift starts, these terminals will have an Operating State of OFFLINE_PUNCH_NO_TRANSMISSION. In this state, the terminals will not send any data to the application server. This state will allow the terminals to collect the clock-ins more quickly. About an hour after the start of the shift, when most all the employees have clocked in, a scheduled service (COMPLETE_OFFLINE_STATE_CONTROLLER) changes the Operating State of the terminals to OFFLINE_QUEUE. In this state, the terminals send their offline data to the application server. The terminals remain in OFFLINE_QUEUE state for about an hour to give them enough time to send the offline data to the application server. Finally, the service will change the Operating State of the terminals to OFFLINE_PROCESSING. When the terminals are in this Operating State, the Offline Data Processor service will process the queued offline data and send it to the database. In addition, terminals in the OFFLINE_PROCESSING state will stop sending offline data to the application server.
See Also:
This feature requires the following:
You must have the Terminal Operating State module included in your license file.
The Terminal Operating State module must be enabled.
To check if the module is included in your license and enabled:
Click Main Menu > Configuration > System > Licensing.
Find the Terminal Operating State record.
The following boxes must be checked: Licensed and Module Enabled.
This feature is designed for the following B-Client applications and terminals:
Terminal |
B-Client Version |
9540 |
B-Client XML3 |
9300 |
B-Client XML10 |
The following configuration is required for this feature:
Create one or more Terminal Off Policies.
Assign the Terminal Off Policies to appropriate Terminal Profiles using Terminal Profile Setting form.
Go to the Operating State form and verify that the Terminal Off Policies have their Operating State set to ONLINE.
Create three instances of the COMPLETE_OFFLINE_STATE_CONTROLLER service. Change the STATE parameter for one instance to OFFLINE_NO_PUNCH_TRANSMISSION. Change the STATE parameter for the other instances to OFFLINE_QUEUED and OFFLINE_PROCESSING respectively.
Note: You do not need to schedule an instance of the COMPLETE_OFFLINE_STATE_CONTROLLER service with the STATE ONLINE, because the terminals are required to be COMPLETE_OFFLINE mode.
Schedule the service instance for OFFLINE_NO_PUNCH_TRANSMISSION to run approximately one hour before and one-half hour after the start of each shift. This service instance will change the Operating State of the terminals to OFFLINE_NO_PUNCH_TRANSMISSION. Although the terminals have a valid connection to the application server, the terminals will collect and store all transactions locally. The terminals will not attempt to send this data to the application server.
Schedule the service instance for OFFLINE_QUEUED to run approximately one hour after the shift starts, when all the employees have clocked in. The terminals should remain in this state for about an hour. This service instance will change the Operating State of the terminals to OFFLINE_QUEUED. The terminals will continue to collect and store transactions locally but will also send their offline data to the application server.
Schedule the service instance for OFFLINE_PROCESSING to run about an hour after the service instance for OFFLINE_QUEUED has run. This service instance will change the Operating State of the terminals to OFFLINE_PROCESSING. The terminals will stop sending offline data to the application server. The Offline Data Processing service will process the queued offline data.
If necessary, the Operating State of the terminals can be changed manually at any time using the Operating State form.
Make sure the Offline Data Processor service is scheduled to run at least once after the COMPLETE_OFFLINE_STATE_CONTROLLER service changes the Operating State of the terminals to OFFLINE_PROCESSING. If the Offline Data Processor service runs when the Operating State is not OFFLINE_PROCESSING (or ONLINE), then the service will not process the offline data and it will remain in the queue.
To change how often the system will attempt to connect to the server when the terminal is offline, use the OFFLINE_CHECK_ONLINE_TIME setting on the Terminal Profile Setting form. You can also use the ONLINE_CHECK_ONLINE_TIME setting to change how often the system will attempt to connect to the server when the terminal is online.
To audit the terminal Operating State changes, go to the Audit Group form and check the Enabled box next to the TERMINAL Audit Group. Make sure the terminal_operating_state table is also Enabled on the Audit Group Table tab. Once these settings are enabled, you can go to the Audit Log form and view the audit data.