This page (revision-22) was last changed on 26-Nov-2021 10:22 by lurtan

This page was created on 26-Nov-2021 10:22 by jmyers

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
22 26-Nov-2021 10:22 14 KB lurtan to previous
21 26-Nov-2021 10:22 14 KB rforbes to previous | to last

Page References

Incoming links Outgoing links
GENUS CLOCK APPLICATIONS
GENUS CLOCK APPLICATIONS

Version management

Difference between version and

At line 3 changed one line
!!!GENUS CLOCK APPLICATIONS
!!!Genus Clock Applications v1.02
At line 6 changed 2 lines
!G1 Clock Type
[GenusClockApplication_01.jpg]
G1 Clock Type
At line 9 changed 2 lines
!G2 Clock Type
[GenusClockApplication_02.jpg]
G2 Clock Type
At line 13 changed one line
*There are currently two clock applications with various types of readers. They are all on the same version with each release.
*Highline currently has two clock applications with various types of readers. They are all on the same version with each release. The current clock version for ePersonality 4.09 Application and web server is 2.03.04
At line 20 changed one line
*This configuration information will initially be held in permanent memory on the terminal and will be loaded into memory only when the time clock is booted(application starts up).
*This configuration information will initially be held in permanent memory on the terminal. This information is loaded into memory only when the time clock is booted(application starts up).
At line 24 changed one line
[GenusClockApplication_03.jpg]
|#TITLE = High Line Time Clock|- main screen title|TITLE = HL (Devel) Time Clock
|#WELCOME_MESSAGE|-Idol page Welcome message. Only referenced by a G2 application.|WELCOME_MESSAGE = Welcome
|#PASSCODE = <passcode>|- clock administrator passcode|PASSCODE = 9
|#ALLOW_KEYING = true/false|- toggle for allowing keying of employee/badge numbers|ALLOW_KEYING = false
|#VALID_KEYED_VALUES =|-Employee Badge or Person codes which are allowed to be keyed when ALLOW_KEYING = false. (Spaces not supported.)|VALID_KEYED_VALUES = 56,5000
|#USE_BADGE = true/false|- toggle for use of badge numbers (true= badge in ITCC, false=person_code)|USE_BADGE = true
|#MIN_BADGE_LEN = 4|- minimum length of badge/employee number|MIN_BADGE_LEN = 2
|#MAX_BADGE_LEN = 10|- maximum length of badge/employee number|MAX_BADGE_LEN = 6
|#ENTER_JOB = true/false|- toggle for allowing a list of assignment Authorized jobs for selection during IN punches.|ENTER_JOB = true
|#ENTER_COST_CENTER = true/false|- toggle for entering cost center information|ENTER_COST_CENTER = false
|#VALID_COST_CENTERS = |- comma delimited list of valid cost centers. (Spaces not supported.)|VALID_COST_CENTERS = 1234,5678
|#VALIDATE_PUNCHES = true/false|- toggle for validating punches on server ( validation will occur regardless if Keyed.)|VALIDATE_PUNCHES = false
|#STORE_BIO = true/false|- toggle for storing biometric templates on server.|STORE_BIO = false
|#QUEUE_FULL|-an "Out of Order" message displayed Once the punch queue is full. ( G1 20 Characters Max.)|QUEUE_FULL = Clock Out of Order. Please advise your manager.
|#QUEUE_FULL2|-Used in G1 applications for 2nd line text messages ( G1 20 Characters Max.)|QUEUE_FULL2 = Advise your manager.
|#QUEUE_LIMIT|-Used to define the MAXIMUM number of queued punches allowed to be in the queue IF less than the maximum physical limit.|QUEUE_LIMIT = 200
|#THAW_LIMIT |-Used to define the number of queued punches allowed to be in the queue and automatically thaw the clock to accept punches.|THAW_LIMIT = 0
At line 27 changed one line
[GenusClockApplication_04.jpg]
|#BIO_SENSITIVITY = 0 to 7|- biometric sensitivity level|BIO_SENSITIVITY = 4
|#BIO_QUALITY = 0 to 2|- biometric quality level|BIO_QUALITY = 1
|#MIFARE_POLL_INTERVAL|- Mifare Card reading interval in ms.|MIFARE_POLL_INTERVAL = 10
|#MSG_TIME = 3000/<milliseconds>|- milliseconds to wait for display messages|MSG_TIME = 3000
|#DELAY_TIME = 5000/<milliseconds>|- milliseconds to delay screens|DELAY_TIME = 5000
|#IDLE_TIMEOUT 5000/<milliseconds>|- milliseconds between idle screen refreshes|IDLE_TIMEOUT 5000
|#QUEUE_SLEEP_TIME = 50000/<milliseconds>|- time between connections to the server|QUEUE_SLEEP_TIME = 50000
|#DATA_SERVER_TYPE = HTTP/ORACLE/WEB|- data transfer method|DATA_SERVER_TYPE = HTTP
|#PING_SLEEP_TIME = 30000/<milliseconds>|- time between pings to the server storing device information.|PING_SLEEP_TIME = 0
At line 30 changed one line
[GenusClockApplication_05.jpg]
|#HOST_URL = http://<host>:<port>/<webapp>/<process> - server connection string
|#HOST_URL = http://192.168.97.165:8988/selfService/clock.process -example
|HOST_URL = http://192.168.97.165:8988/selfService/clock.process
At line 56 added 3 lines
|#WB_RETRY_INTERVAL = 60000/<milliseconds> - retry frequency for invalid POSTs
|WB_RETRY_INTERVAL = 60000
At line 33 changed one line
[GenusClockApplication_06.jpg]
|#DATABASE_DRIVER = oracle.jdbc.driver.OracleDriver - database driver class
|DATABASE_DRIVER = oracle.jdbc.driver.OracleDriver
At line 63 added 12 lines
|#DATABASE_URL = jdbc:oracle:thin:@<host>:<port>:<sid> - database URL
|DATABASE_URL = jdbc:oracle:thin:@NSI:1521:NSI
|#DATABASE_USER = <user> - database user name
|DATABASE_USER = P2K
|#DATABASE_PSWD = <password> - database password
|DATABASE_PSWD = p2k
|#DB_RETRY_INTERVAL = 60000 / <milliseconds> - retry frequency for invalid connection attempts
|DB_RETRY_INTERVAL = 60000
At line 36 changed one line
*There are four main pieces of software that are required to be loaded and maintained on the clocks.
*There are 4 main pieces of software that are required to be loaded and maintained on the clocks.
At line 40 changed one line
**System Provided
**High Line Provided
At line 43 changed 3 lines
*The first two are only required when and if CMI sends out an upgrade. It is suggested that the app be tested on all new versions provided from CMI before a client installs the new software, unless specifically directed by CMI. Notification should be made if that clients are on higher versions when reporting issues found after the install.
*Loading all four pieces of software is preformed via TFTP communication.:\\{{tftp -i <ipaddress> PUT App.jar \flashdisk\App.jar}}
*The first two are only required when and if CMI sends out an upgrade. It is suggested that HL test the app on all new versions provided from CMI before a client installed the new software unless specifically directed by CMI. HL should be notified if that clients are on higher versions when reporting issues found after the install.
*The Load all four pieces of software is preformed via TFTP communication.
TFTP [-i] host [GET | PUT] source [destination]
At line 62 changed 3 lines
%%information These setting are adjusting features of the bio and Mifare readers which are NOT provided. These are features of the hardware and when changing these values to something different than provided in the config file, CMI support should be consulted.%%
*Delay times for displaying messages(MSG_TIME), clock idle time (time when no key strokes have been recorded)(IDLE_TIMEOUT) and function completion time before returning to the idle screen (DELAY_TIME) may be set in milliseconds to ensure users have time to read the information on the clock screens.
*Data server communication does have an attribute however only HTTP request types are currently supported. (DATA_SERVER_TYPE)
%%information:These setting are adjusting features of the bio and Mifare readers which are NOT provided by High Line. These are features of the hardware and when changing these values to something different than provided in the config file CMI support should be consulted.%%
*Delay times for displaying messages(MSG_TIME), clock idle time (time when no key strokes have been recorded)(IDLE_TIMEOUT) and function completion time before returning to the idle screen (DELAY_TIME) may be set in milliseconds to ensure users have time to read the information on the clock screens.
*Data server communication does have an attribute however ONLY HTTP request types are currently supported. (DATA_SERVER_TYPE)
At line 67 changed one line
*The functionality described below is as it pertains to the G2 application and is common to the G1. Functionality not available in the G1 will be identified.
*For clock functionality please refer to the provided xls story boards giving screen illustrations and available keys. The functionality described below is as it pertains to the G2 application and is common to the G1. Functionality not available in the G1 will be identified.
At line 71 changed 2 lines
*The idle screen is the screen which all clocks revert back to when waiting for a user to punch. This screen may include such information as a main title(TITLE), welcome message (WELCOME_MESSAGE), punch IN and OUT(*) prompts(*), verification prompt(*), software version(G2 only), time stamp including date and time.\\(*) - Located on function buttons only on the G1: F1-Punch IN, F2-Punch OUT F3-verify, F4-Enroll(**), F5-remove print(if applicable to clock reader) (**), F6-Edit punch(**), F11 - Turn Debug on and off, F12-Memory Capacity Test /Current queue size.
*The G2 provides access to the administrator's screen and functions using the F1 key(**).\\(**) -These functions are restricted and requires an administrator to enter the admin pass code defined in the configuration file (PASSCODE) before access is granted.
*The idle screen is the screen which all clocks revert back to when waiting for a user to punch. This screen may include such information as a main title(TITLE), welcome message (WELCOME_MESSAGE), punch IN and OUT(*) prompts(*), verification prompt(*), Software Version(G2 only), time stamp including date and time.
(*) - Located on function buttons only on the G1: F1-Punch IN, F2-Punch OUT F3-verify, F4-Enroll(**), F5-remove print(if applicable to clock reader) (**), F6-Edit punch(**), F11 - Turn Debug on and off, F12-Memory Capacity Test /Current queue size.
*The G2 provides access to the administrators screen and functions using the F1 key(**).
(**) -These functions are restricted and requires an administrator to enter the admin pass code defined in the configuration file (PASSCODE) before access is granted.
At line 76 changed 5 lines
*A user may then be requested to enter a valid cost center code if defined in the configuration file (ENTER_COST_CENTER). The entered code is validated against a list provided in the configuration file (VALID_COST_CENTERS). An error sound and light will tell the user of an invalid entry and the punch attempt is stopped. If a valid cost center code is entered, the user will then be allowed to continue the punch.
*The user will be asked to identify themselves using the reader built into the clock being used. If permitted (ALLOW_KEYING), a prompt will be displayed, stating a badge code may be entered manually to identify the employee. If this is set to 'False', all keying for all employees will be removed. If using a biometric reader, some employees may be unable to record a bio template successfully. If that is the case, the administrator may define specific employees who are allowed to key their badge. (VALID_KEYED_VALUES a comma separated list of badge numbers). All badge values will be validated for minimum and maximum length. (MIN_BADGE_LEN, MAX_BADGE_LEN)
*When an employee badge is keyed or if badge validation is required (VALIDATE_PUNCHES), the entered badge will be sent immediately to the server. An active employment will be searched for using either the person code or the clock card code as defined by (USE_BADGE) .
*Employees may be requested to punch into a specific job (ENTER_JOB). When this is true, the information collected identifying the employee is sent immediately to the server for validation and a list of jobs the employee may clock into is returned to the clock. If the employee has only one assignment, the punch will be recorded and the clock will declare a successful punch recorded. The number of jobs an employee can punch into the G2 clock is limited to 8 (as there are 8 selection buttons).
*If validation is not required, the punch details will be stored into clock memory (the queue) for speed to allow the next user to punch. All details collected within the defined (QUEUE_SLEEP_TIME) are sent to the server. Once the details are stored in the queue a successful completion message is given and the clock is reset back to the welcome screen for the next user.
*A user may then be requested to enter a valid cost center code if defined in the configuration file (ENTER_COST_CENTER). The entered code is validated against a list provided in the configuration file (VALID_COST_CENTERS). An error sound and light will tell the user of an invalid entry and the punch attempt is stopped. If a valid cost center code is entered the user will then be allowed to continue the punch.
*The user will be asked to identify themselves using the reader built into the clock being used. If permitted (ALLOW_KEYING ) a prompt stating a badge code may be entered manually to identify the employee will be displayed. If this is set to false. All keying for all employees will be removed. If using a biometric reader some employees may be unable to record a bio template successfully; If that is the case the administrator may define specific employees who are allowed to key their badge. ( VALID_KEYED_VALUES a comma separated list of badge numbers). All Badge values will be validated for minimum and maximum length. ( MIN_BADGE_LEN, MAX_BADGE_LEN)
*When an employee badge is keyed or if badge validation is required ( VALIDATE_PUNCHES ) the entered badge will be sent immediately to the server. An active employment will be searched for using either the person code or the clock card code as defined by (USE_BADGE) .
*Employees may be requested to punch into a specific job. (ENTER_JOB) When this is true the information collected identifying the employee is sent immediately to the server for validation and a list of jobs the employee may clock into is returned to the clock. If the employee has only one assignment the punch will be recorded and the clock will declare a successful punch recorded.
*If validation is not required the punch details will be stored into clock memory (the queue) for speed to allow the next user to punch. All details collected within the defined (QUEUE_SLEEP_TIME) are sent to the server. Once the details are stored in the queue a successful completion message is given and the clock is reset back to the welcome screen for the next user.
At line 83 changed 3 lines
*The Idle screen has a function button dedicated to initiate the employee verification. When pressed, the user is given two choices. One to verify using the reader and the other to enter the employee number.
%%information The employee number will be either the "Person code" (defined in [IEID]) or the employees defined "clock card code" (defined in [ITCC]). This is important to know depending on the reader type being used. The clock card code may only be a numeric value since both clocks (G1 and G2) only support numeric keying. The USE_BADGE in the configuration file defines this, a true value will validate against the HR IEID record. A false value will validate against the ITCC record.%%
*Validation using the reader will verify the badge number (Please refer to USE_BADGE attribute.) on the server. Biometric readers will verify that biometric templates exist in the clock memory first then check the server for validation.
*The Idle screen has a function button dedicated to initiate the employee verification. When pressed the user is given two choices. One to verify using the reader or to enter the employee number.
%%information: The employee number will be either the eP "Person code" (defined in IEID) or the employees defined "clock card code" (defined in ITCC). This is important to know depending on the reader type being used. The clock card code may only be a numeric value since both clocks (G1 and G2) only support numeric keying. The USE_BADGE in the configuration file defines this; A true value will validate against the HR IEID record. A false value will validate against the ITCC record.%%
*Validation using the reader will verify the badge number ( Please refer to USE_BADGE attribute. ) on the server. Biometric readers will verify that biometric templates exist in the clock memory first then check the server for validation.
At line 95 changed 4 lines
*The enroll key is used to capture two finger print bio scans referred to as templates and record them into the clock memory. An option to store the print templates on the server is provided in the configuration file (STORE_BIO). If this attribute is false, two templates will be stored on the clock only. The true two templates will be stored on both the clock being used and in the database which the web server points to.
*The template may be verified that it was stored correctly by viewing the ITCC effective record for the badge the templates were enrolled with.
[GenusClockApplication_07.jpg]
*The enroll key is used to capture two finger print bio scans referred to as templates and record them into the clock memory. An option to store the print templates on the server is provided in the configuration file (STORE_BIO). If this attribute is false two templates will be stored on the clock only; If true two templates will be stored on both the clock being used and in the database which the web server points to.
*The template may be verified it was stored correctly by viewing the ITCC effective record for the badge the templates were enrolled with.
At line 100 changed one line
%%information If the config file is defined to use the "True" badge, the ITCC clock card code must match the person code and the administrator must use the person code as the badge number when enrolling the employee at the clock. The reason for this is that validation will be looking to the HR identity record using the entered badge and looking for a person code. Since the templates are stored in ITCC, the clock card code must match in order to store the templates.%%
%%information:If the config file is defined to use badge "true" the ITCC clock card code must match the person code and the administrator must use the person code as the badge number when enrolling the employee at the clock. The reason for this is that validation will be looking to the HR identity record using the entered badge and looking for a person code. Since the templates are stored in ITCC the clock card code must match in order to store the templates.%%
At line 103 changed 2 lines
*When 'Remove' is selected, the administrator will be provided with two options. The first is to remove a single employee and prompted for a badge number (Reminder: This may be either a clock card code or person code depending what was used to enroll the employee and what the config file has defined with USE_BADGE.). The templates associated to that badge number will be removed from memory on that clock only. If prints were stored on the server they will remain.
*The second option is to remove ALL templates stored on that clock only. This feature is provided for testing purposes and not recommended for a live clock. The admin will be prompted to enter ten "9's" in a row for confirmation before this is executed.
*When remove is selected the administrator will be provided with two options. The first is to remove a single employee and prompted for a badge number ( Reminder: This may be either a clock card code or person code depending what was used to enroll the employee and what the config file has defined with USE_BADGE. ) . The templates associated to that badge number will be removed from memory on that clock only. If prints were stored on the server they will remain.
*The second option is to remove ALL templates stored on that clock only. This feature is provided for testing purposes and not recommended for a live clock. The admin will be prompted to enter 10 "9"'s in a row for confirmation before this is executed.
At line 110 changed one line
*This feature is useful in tuning the clock depending on the use.\\ \\Example: If the clock generally has more than 50 employees punching IN/OUT at a time the clock may encounter a high volume of stored punches. In the field, memory could potentially be filled up if a network or database was not available.\\ \\This test will identify to the administrator the maximum number of punches before it must shut down and wait for communication to upload. A sample punch will be requested in order to use the correct amount of memory for each punch. The clock will then queue as many punches the clock will successfully record. That number will be made available to the administrator.
*This feature is useful in tuning the clock depending on the use.
Example: If the clock generally has 50 > employees punching IN/OUT at a time the clock may encounter a high volume of stored punches. In the field, memory could potentially be filled up if a network or database was not available.
This test will identify to the admin the maximum number of punches before it must shut down and wait for communication to upload. A sample punch will be requested in order to use the correct amount of memory for each punch. The clock will then queue as many punches the clock will successfully record. That number will be made available to the administrator.
At line 112 changed one line
*Once the maximum is found each company may decide the maximum memory capacity is not a business practice they would like to allow each clock to hold in cases of emergency. There are two configuration file attributes available to set a ceiling for stored punches where the clock will stop allowing punches and provide a configurable message to the users that a manager must be notified the clock is full. The second is used once communication comes back on line the clock will begin again down loading queued punches. When the queue size reaches the thaw limit, the clock will then become operational and accept punches.\\ \\Both attributes are located in the configuration file as QUEUE_LIMIT and THAW_LIMIT. The queue full message is configurable and in the configuration file as QUEUE_FULL, in addition, for the G2 only, a second line is provided as QUEUE_FULL2.
*Once the maximum is found each company may decide the maximum memory capacity is not a business practice they would like to allow each clock to hold in cases of emergency. There are two configuration file attributes available to set a ceiling for stored punches where the clock will stop allowing punches and provide a configurable message to the users that a manager must be notified the clock is full. The second is used once communication comes back on line the clock will begin again down loading queued punches. When the queue size reaches the thaw limit the clock will then become operational and accept punches.
Both attributes are located in the configuration file as QUEUE_LIMIT and THAW_LIMIT. The queue full message is configurable and also in the configuration file as QUEUE_FULL and for the G2 only a second line is provided as QUEUE_FULL2.
At line 115 changed one line
*The Administrator is given the ability to clear all punches in the queue. This is generally used for testing purposes. Upon selection the user will be prompted to enter ten number 9's to confirm the removal of all queued punches.
*The Administrator is given the ability to clear all punches in the queue. This is generally used for testing purposes. Upon selection the user will be prompted to enter 10 number 9's to confirm the removal of all queued punches.
At line 118 changed 6 lines
*This is a feature which runs transparent to users. Administrators may define a time in milliseconds which the clock will ping the server (PING_SLEEP_TIME).
*Each ping includes the machine name, time, the clock software version.
*The ping information is stored in the device information field of Define Clock Devices [ITCD] screen.
*If the clock device record was made with data in the device information field previous to the initial ping, that data will be appended to at the end. All xml data received will always be the last appended.
%%information If text is added after the xml it will be lost after the next ping.%%
[GenusClockApplication_08.jpg]
*This is a feature which runs transparent to users. Administrators may define a time in milliseconds which the clock will ping the server. (PING_SLEEP_TIME)
*Each ping includes the machine name, time, the HL clock software version.
*The ping information is stored in the device information field of ITCD - Define clock devices.
*If the clock device record was made with data in the device information field previous to the initial ping, that data will be appended to at the end. All xml data received will always be the last appended.
%%information: If text is added after the xml it will be lost after the next ping.%%
This page (revision-22) was last changed on 26-Nov-2021 10:22 by lurtanTop