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 4 changed 2 lines
Project Objective
The overview should outline the business intent, purpose and scope of the project. (1-2 sentences)
At line 7 removed one line
Topics explained:
At line 9 removed 16 lines
Developer Information
Source code
Batch files
Compiling
Configuration file
Java libraries and clock system files
Available Memory
Consultant Information
Clock Types and Applications
Configuration Attributes
Loading Clocks
Clock re-booting
Usability Configuration
Functionality
At line 27 changed 5 lines
• The source code for both G1 and G2 applications is kept in a package as part of the standard product code
com.highlinecorp.timeclock
• Copies of the source each release are kept on
pandora\dfs\ePersonality\Time_Clock_Software\From PD
• For each release zip files are kept: 1) a built G1 app, G2 app and zipped with the configuration files (These are the zip files which may be released to clients) 2) The current build scripts used to generate the apps 3) A copy of the Genus clock app source which keeps track of the eP version in the zip file names.
*The source code for both G1 and G2 applications is kept in a package as part of the standard product code\\com.highlinecorp.timeclock
*Copies of the source each release are kept on\\pandora\dfs\ePersonality\Time_Clock_Software\From PD
*For each release zip files are kept:
*#a built G1 app, G2 app and zipped with the configuration files (These are the zip files which may be released to clients)
*#The current build scripts used to generate the apps
*#A copy of the Genus clock app source which keeps track of the eP version in the zip file names.
At line 34 changed 4 lines
• Deploying Genus class libraries ( from CMI ), deploying genus system file ( from CMI ), Compiling HL code, building jar files, deploying the App.jar and configuration file, retrieving - Existing App.jar, config files and genus classes and libraries are all accomplished through DOS batch files.
• They are all located in C:\HLApplication\HLApplication\dd\timeclock\bat
• They are organized to work with G1 and G2 types separately. Each clock type requires different class libraries and different java files to build different App.jar files although they are named the same.
• The App.jar created for each clock type G1 or G2 will support Biometric, Mifare and proximity readers.
*Deploying Genus class libraries ( from CMI ), deploying genus system file ( from CMI ), Compiling HL code, building jar files, deploying the App.jar and configuration file, retrieving - Existing App.jar, config files and genus classes and libraries are all accomplished through DOS batch files.
*They are all located in:\\C:\HLApplication\HLApplication\dd\timeclock\bat
*They are organized to work with G1 and G2 types separately. Each clock type requires different class libraries and different java files to build different App.jar files although they are named the same.
*The App.jar created for each clock type G1 or G2 will support Biometric, Mifare and proximity readers.
At line 40 changed 8 lines
• For ease of development the clock applications may be developed from within JDeveloper. Although development is done here, it is important that compilation of the code be compiled on a java version no newer than 1.05.0.11 and compiler set to 1.4. The code must be written and compiled to be compatible with the J2ME Personal Profile 1.1
• The application must be compile outside JDeveloper before a built and may be done using the cmd file located in : C:\HLApplication\HLApplication\dd\timeclock\bat
• The batch files with naming of either G1 .... or G2 ..... have been developed. The purposes of each are:
1) Deploy clock library and system files (provided from CMI)
2) Compile application code outside JDeveloper required before a build.
3) Build the jar file.
4) Deploy configuration and application to a clock.
~) Are "gets" for getting the above files off an existing clock.
*For ease of development the clock applications may be developed from within JDeveloper. Although development is done here, it is important that compilation of the code be compiled on a java version no newer than 1.05.0.11 and compiler set to 1.4. The code must be written and compiled to be compatible with the J2ME Personal Profile 1.1
*The application must be compile outside JDeveloper before a built and may be done using the cmd file located in:\\C:\HLApplication\HLApplication\dd\timeclock\bat
*The batch files with naming of either G1 .... or G2 ..... have been developed. The purposes of each are:
*#Deploy clock library and system files (provided from CMI)
*#Compile application code outside JDeveloper required before a build.
*#Build the jar file.
*#Deploy configuration and application to a clock.
*#Are "gets" for getting the above files off an existing clock.
*These files are configured via the ~setvars.cmd file.
At line 49 removed 3 lines
• These files are configured via the ~setvars.cmd file.
At line 53 changed 4 lines
• The configuration file is located in: C:\HLApplication\HLApplication\dd\timeclock\config
• The file name is app.conf
• This file is used for both the G1 and G2 clock types of all readers. It contains all supported clock feature attributes and some attributes in the database configuration that have been planned for but not developed or supported.
• Each attribute has an example with explanation line and the actual attribute and value. The example line is remarked by placing a # at the beginning of the line, so it will not be loaded into the clock.
• The configuration file is located in: C:\HLApplication\HLApplication\dd\timeclock\config
• The file name is app.conf
• This file is used for both the G1 and G2 clock types of all readers. It contains all supported clock feature attributes and some attributes in the database configuration that have been planned for but not developed or supported.
• Each attribute has an example with explanation line and the actual attribute and value. The example line is remarked by placing a # at the beginning of the line, so it will not be loaded into the clock.
At line 60 changed one line
• Extra unused lines may also be remarked for reference and not used.
• Extra unused lines may also be remarked for reference and not used.
At line 67 changed one line
• This config file needs to be loaded before the application in order for it to be read by the application at start up. (see the "G2 4 Deploy file" described above. )
• This config file needs to be loaded before the application in order for it to be read by the application at start up. (see the "G2 4 Deploy file" described above. )
At line 70 changed one line
• The supporting java libraries are provided to High Line from Control Module Incorporated. The current supported versions as of May 13, 2010 for the G2 are:
• The supporting java libraries are provided to High Line from Control Module Incorporated. The current supported versions as of May 13, 2010 for the G2 are:
At line 75 changed one line
• G1 available memory:
• G1 available memory:
At line 77 changed one line
• G2 available memory:
• G2 available memory:
At line 95 changed one line
• The time clock application will be a set of Java programs that are compiled centrally, packaged and transferred to each terminal as follows:
• The time clock application will be a set of Java programs that are compiled centrally, packaged and transferred to each terminal as follows:
At line 97 changed one line
• 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
• 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 103 changed one line
• Parameters and options will be maintained in a central configuration file that can be transferred to the terminals at any time with the following command:
• Parameters and options will be maintained in a central configuration file that can be transferred to the terminals at any time with the following command:
At line 105 changed 2 lines
• 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).
• The following parameters with explanations will be supplied in a configuration file:
• 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).
• The following parameters with explanations will be supplied in a configuration file:
At line 219 changed one line
• There are 4 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 226 changed 2 lines
• 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 are is preformed via TFTP communication.
• 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 are is preformed via TFTP communication.
At line 230 changed one line
• Examples:
• Examples:
At line 235 changed one line
• It is suggested to used cmd files to aid in this process and keep track of where the software has been loaded when multiple clocks exist. (Note all spaces in the examples above.)
• It is suggested to used cmd files to aid in this process and keep track of where the software has been loaded when multiple clocks exist. (Note all spaces in the examples above.)
At line 238 changed 2 lines
• The Genus clocks may require a reboot once in a while to load new software. This is accomplished by either physically unplugging the clock from the power source or loading a new App.jar file.
• If a new app.conf file is loaded, the newly changed attributes will not be respected until a clock reboot has been done.
• The Genus clocks may require a reboot once in a while to load new software. This is accomplished by either physically unplugging the clock from the power source or loading a new App.jar file.
• If a new app.conf file is loaded, the newly changed attributes will not be respected until a clock reboot has been done.
At line 241 changed 3 lines
• The configuration file has had attributes added to help tailor the clocks to get the best performance for users.
• Biometric readers may have the sensitivity settings adjusted to help read difficult finger prints by setting BIO_SENSITIVITY and BIO_QUALITY configuration attributes.
• Mifare card readers may have the poll interval time adjusted using MIFARE_POLL_INTERVAL. This is the time in between card reads. This will speed up or slow down the time the user is required to be holding the card up to the reader.
• The configuration file has had attributes added to help tailor the clocks to get the best performance for users.
• Biometric readers may have the sensitivity settings adjusted to help read difficult finger prints by setting BIO_SENSITIVITY and BIO_QUALITY configuration attributes.
• Mifare card readers may have the poll interval time adjusted using MIFARE_POLL_INTERVAL. This is the time in between card reads. This will speed up or slow down the time the user is required to be holding the card up to the reader.
At line 245 changed 2 lines
• 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)
• 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 249 changed 2 lines
• 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.
• Some functionality will be configurable with the relevant attribute noted in brackets. The configuration attribute will be found in the app.conf file located in ..\config\app.conf \ramdisk\app.conf mentioned in the clock software section of this document.
• 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.
• Some functionality will be configurable with the relevant attribute noted in brackets. The configuration attribute will be found in the app.conf file located in ..\config\app.conf \ramdisk\app.conf mentioned in the clock software section of this document.
At line 253 changed one line
• 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.
• 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.
At line 255 changed one line
• The G2 provides access to the administrators screen and functions using the F1 key(**).
• The G2 provides access to the administrators screen and functions using the F1 key(**).
At line 259 changed 6 lines
• The Genus clocks have designated function buttons enabling the user to identify if they want to punch IN or OUT.
• 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.
• The Genus clocks have designated function buttons enabling the user to identify if they want to punch IN or OUT.
• 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 267 changed one line
• 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.
• 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.
At line 269 changed 3 lines
• 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.
• G2 validation is currently limited to ONLY Biometric and Mifare readers and keyed values if the clock contains one of those readers. (HL note: Development required to allow keying regardless of reader type.)
• G1 validation will accept Biometric, Magnetic cards and keyed badge values.
• 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.
• G2 validation is currently limited to ONLY Biometric and Mifare readers and keyed values if the clock contains one of those readers. (HL note: Development required to allow keying regardless of reader type.)
• G1 validation will accept Biometric, Magnetic cards and keyed badge values.
At line 274 changed 3 lines
• The G2 has a dedicated screen for the administrator holding all functions available. (The G1 admin functions are accessed via the function keys listed in the Idle screen description.) An administrator will be requested to enter the admin pass code as defined in the config file (PASSCODE) loaded into the clock for start up.
• Clocks equipped with biometric readers will have options to Enroll and Remove templates.
• All G2 clocks will have options to Check queue size, Test queue capacity and Clear all.
• The G2 has a dedicated screen for the administrator holding all functions available. (The G1 admin functions are accessed via the function keys listed in the Idle screen description.) An administrator will be requested to enter the admin pass code as defined in the config file (PASSCODE) loaded into the clock for start up.
• Clocks equipped with biometric readers will have options to Enroll and Remove templates.
• All G2 clocks will have options to Check queue size, Test queue capacity and Clear all.
At line 279 changed 2 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; 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.
• 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 285 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 10 "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 288 changed one line
• This option provides the administrator the ability to get a count of punches waiting in memory to be sent to the server. In most cases this option is used when the server has been down(not available) to the clock for communication. This may be for several reasons such as network, web server or database issues. The clock name and the number of live clock punches in memory will be displayed.
• This option provides the administrator the ability to get a count of punches waiting in memory to be sent to the server. In most cases this option is used when the server has been down(not available) to the clock for communication. This may be for several reasons such as network, web server or database issues. The clock name and the number of live clock punches in memory will be displayed.
At line 291 changed one line
• This feature is useful in tuning the clock depending on the use.
• This feature is useful in tuning the clock depending on the use.
At line 294 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.
• 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.
At line 298 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 10 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 301 changed 4 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 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.
• 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.
This page (revision-22) was last changed on 26-Nov-2021 10:22 by lurtanTop