Almost a year ago I had the opportunity to face a new challenge: joining a sub-team exclusively dedicated to the development of an employees management system. Our main objective was to systematize and substantially improve the management of information about the personnel, apart from allowing all employees to check in and out of the system, access the information immediately and at any time.

For that reason, 4 anti-vandal totems were purchased to grant all employees access to the system at any time through a secure fingerprint check in and out.

In this article I’ll share my experiences in the development of this new module, the challenges of adapting a completely new technology to the one already in use, the problems we faced and the solutions we managed to find.

System

In general terms, the management system we had to couple to consisted of two parts:

  • Back-end RESTful developed in Java, with Hibernate, Spring and Springboot, among others. SQL Server Data base
  • Front-end developed with Angular Material 6

As for Back-end architecture, we started with the endpoints provided by the controllers for the Frontend to communicate. These, in turn, use a validation layer to later execute the necessary function of the corresponding service. The services injected to the controllers are composed of an Interface and its implementation. Each service is created for a specific entity and extended from a Base Interface and Implementation, both templatized, which implement the basic CRUD functions.

Finally, each function implemented communicates with a Repository, which executes the actions required to SQL Server database.

Anti-vandal totem

The totems were at first expected to make the system accesible for all employees, for them to see what they needed to see without a personal computer. Then it was added the fingerprint check in and out, a secure option for both employee and employer. Finally, a ticket printer was included in case printing was necessary, All this connected and presented in the shape of highly resistant totems, since they would be set in public circulation places and manipulated by many people.

When the Hardware is not the one you expected

Within the suitable parameters, a series of 4 pre-prepared Totems were tendered for and purchased to a state company.

The fingerprints device needed to provide an SDK to connect it to the application.

Problems arose when receiving the totems. We immediately noticed the fingerprints device was not connected to the monitor. The monitor had its own operating system. It was a touchscreen monitor, Windows 10, whilst the fingerprints device had its own Linux operating system and could only be accessed through the TCP/IP.

The only thing working together with the totem PC was the ticket printer, whose functionality was not defined.

To sum up, we were in the presence of just a lot of separate pieces bolted to an anti-vandal structure.

The biometric device

The biometric device is UA760 by ZKTeco, which has the following specifications:

And the following features:

  • Wi-Fi: WIFI module is integrated. It is working on the 2.4G radio band, and meet the IEE 802.1 1b/g standards.
  • USB: Support USB host connection to archive data backup and management while the device is standalone.
  • WDMS: Optional for devices worldwide using. Solve the device’s capacity limitation through networking via HTTP server. Mondial devices can be connected and upload & backup data automatically. This is helpful for devices managing and monitoring.
  • BioID: Using BioID Fingerprint Collector for excellent recognition rate. Dry, moist, or rought fingerprints can work well.

Summing up, it can be used through TCP/IP or WiFi connection. The USB port could only be used for storing data as backup, but we couldn’t use it because the Totem anti-vandal cover made it impossible to reach it.

The requirements

The Totem must be used as a source of access to the application by approximately the 100 people that conforms the Company. It provides all the personnel with direct access to a computer that has the app installed. In fact, a big part of the implementation requires the Totem PC to give access only to the application.

Among the main requirements for the use of the devices are the following:

  • Biometric data can be assigned […]. This data can also be modified, checked and erased. For the captures, the suitable devices for that purpose will be used. Data are:
  • […] fingerprints: captured by a fingerprints reader
  • […] It can be indicated if the employee is or not exempt from checking in and out through the biometric system […].
  • […] The system will take data from the online registers from the check in and out device and will link the data with the central database.
  • […] The system will determine people who are absent according to what the biometric device marks. In case of technical difficulties (no connectivity of self-service terminal, failure in performance, etc.), users who have permits assigned can manually check in or out.

The problems

Regarding the totems, it was obvious that the intention was to have a set of tools interconnected. Since that was not the case, we had to find a way for the biometric device to communicate with the touchscreen monitor operating system.

When you see the features and specifications of the UA760, it seems to be a good choice. But this wasn’t the case for us.

The biometric device has several unnecesary features. We won’t blame it for that. But the attendance control, check in/out times and general information about the employer had to be administered by the Central System. Thus, most of the functionalities provided by the SDK wouldn’t be used.

What probably affected us the most was the intended purpose manufacturers had for this product and its lack of flexibility. ZKTeco sells the hardware with a full SDK for you to develop an app for its devices, but it offers the software at the same time and that is the problem. The Company wants you to consume all its services, not to buy the device and develop a new app. They want to sell you their own system. Although they offer you an SDK, it does not do anything different from what you have in the Example App or in ZKTime and ZKAccess. In general, using their pre-prepared products is more economical than developing an application with their tools, though this may sound obvious. The SDK has no complex characteristics. It’s all covered by its software and you would end up cloning one of theirs.

Another problem is that you are tied to a language. Our Back-end is developed in Java, and the SDK in C#, so they are incompatible and we cannot access the functionalities provided, as we would do if we had another Library.

So as to finish, when inspecting the Demos of the SDK that came with the device we noticed some interesting things. There was a lot of commented code. The main reason was that there is a single demo for several devices. We had to search for all the functionalities available for our version.

From what we could see in the documentation, several functions (not all) had this note attached:

That meant that the devices could use a specific function, and because of the name of the Platform of our devices, we assumed that we had to find functions applicable to “TFT”. Those that didn’t specify that couldn’t be used. We also noticed we were working within a pretty old firmware, but that’s a different story.

All in all, we managed to find all the functions we were looking for, except for SSR_EnableUser().

As the image shows, the functionality consisting of enabling or disabling users was essential for us and we needed it.

When searching for this in the Demo, we couldn’t find it. First thing we did was to verify if it was being used in the code, and its last mention was in the commented code.

After running individual tests executing only this functionality, and after many attempts, we got disappointing news: this functionality didn’t work and that’s why it was commented.

The solutions

Taking these things into account and further Project demands, such as documentation and later training of the client’s developers,the following solutions were applied:

Python Microservice:

It was decided to create a microservice that could perform actions on the biometric devices. Considering the size of the Project, the documentation and the training, it was chosen an Open Source alternative to the SDK written in Python called  PyZK. In this way, a REST APÍ could be created using Flask.

So as to cover the documentation, Swagger was added, which is a simple and fast way to document and test the API without major inconveniences.

Rest Client on the Central System side

After creating the REST API, we still needed a way for the Central System to communicate with the biometric devices. The endpoints to execute actions such as check-in reading or creation of users were already available, and to be consistent with the current Back-end architecture, the system would have a Controller for each entity, with its validators and services, but with a small difference from the rest. These would extend from a Base Interface and Implementation that instead of communicating with a Repository, would create a Rest Client to communicate with the API in Flask. In this way, we managed to communicate both Back-ends.

Summing up, communication between the tool and the biometric devices would be this way:

Synchronicity of the 4 biometric devices

So far we have discussed the way the Central System communicates with the biometric devices, but it is important to say that the 4 devices must be in sync simultaneously.

Thus, the Software provided by ZKTeco has functionalities to synchronize several devices with a single list of users, but that is not provided by the SDK. The way they synchronize the information is by means of manually merging all registered users in each device.

Our solution was to do something similar, using as main database the one of the Central System. A single users list would serve as a reference for all the biometric devices, and through the execution of a Cron, or manually, the enabled users list would be passed to all biometric devices.

In this way, we were also able to solve the SRR_EnableUser() problem. When we  store the users in our database, we can assign them a state: “enabled” or “blocked”. Then, during the execution of the synchronization, all the users blocked would be removed from the updated list, what “simulates” a user without check in permission.

Electron for the Totems

As for the Front-end,everything stays the same. Components and Services are created using the same practices the entire tool uses. Nothing has changed for the Front-end.

There is still one problem to be solved. Each Totem must be configured with the app for users to have immediate access to the information and at any time. For that reason, ElectronJs was chosen, since it allows us to turn the system into a desktop app and has some other essential characteristics.

For the creation of the window of the application in Electron, a BrowseWindow instance is created, using new BrowseWindow() with the following configuration:

  • fullscreen: true -> open the application in full screen mode
  • resizable: false -> size of the application cannot be modified
  • frame: false -> to avoid the menu at all cost
  • skiptaskbar: true -> don’t show task bar
  • alwaysOnTop: always on top of other applications and screens
  • webpreferences: {
    devTools: false -> developer tools cannot be opened
    }

Apart from that, the following Listener is added to avoid the user closing the application at all cost

win.on('close', function (event) {
 event.preventDefault();
 event.returnValue = false;
});

And a new special window is created to shut down the application with a password:

ipcMain.on('close-manually', () => {
 prompt({
   title: 'Close application',
   label: 'Password:',
   value: '',
   inputAttrs: {
     type: 'password',
     required: true
   },
   type: 'input'
 }, win).then((r) => {
   if (validatePassword(r)) {
     win.destroy();
     win = null;
   }
 }).catch(...);
});

With this configuration, the Totem has an application running 24 hs in Full screen mode, which can only be closed with a password known by authorized personnel.

ngx-electron

Since the desktop application has non visible characteristics  from the web application, the keyboard or mouse are not used and the screen is vertical. It was necessary to create differentiated sceens with bigger buttons and less details, what made it necessary to install ngx-electron, a module for Angular that not only enables us to communicate and use Electron functions from any component, but also to detect when it is executing so as to choose which ones to show in real time without having to resort to complex logics and duplicated code.

replace-in-file

If you want to use Electron with Angular 6, you may find the same error within your files, in particular  main.js:

“Failed to load resource: net::ERR_FILE_NOT_FOUND”

This error is related to base path defined in the configuration of Angular, generally in the index.html

The base defined for the Angular application build is incompatible with the configuration that Electron accepts, which takes as valid path “./”.

The solution to this error was to use replace-in-file library while building the application, by creating a new script in package.json:

"build-electron": "node ./replace.build.js --mode=electron && ng build --prod",

Where replace.build.js has the logic necessary to replace the path by the correct one, based on the parameter – mode sent.

It is worth mentioning that this method was already being used to control certain environment variables. Thus it was only necessary to add the path based editor and the new parameter to have it working.

node-regedit

The last of the problems to solve is how to link the Totem Operating System with the Biometric Device.

To do so, the node-regedit library was installed, which offers basic functionalities for the creation of  Keys and Sub Keys in Windows Registry editor .

First, on the Electron side, a Listener was added to a special Event that, when activated, takes the arguments sent and stores them as Windows Registers. After that, while using ngx-electron, we check if the Application is executing in Desktop mode to show an action in the Totems administration dashboard. Such action emits the event, passing the data (IP and Port) as arguments of the Biometric Device selected to be linked.

Finally, node-regedit offers another functionality to obtain the inserted values to be used when executing actions on the Biometric Device in the Totem.

Conclusion

Broadly speaking, the implementation and setting-up of the Totems became a challenge bigger than expected, mainly for things that were beyond our control, but we were to tackle these problems and find concrete solutions.

While looking for solutions, the development time and the learning curve of new technologies played an important role in decision making. Besides, we also have to bear in mind that we won’t be the last developers to work on the system, so it is very important to study what was already done so as not to end up with something completely different from the general architecture and, as a consequence, with a code impossible to maintain for the future developers.