Some weeks ago we got the requirement to integrate our punch in/out door device with our main business system. When our people come to work, they would hold their ID cards in front of the machine, and the machine would create records who arrived to work and at what time. Now the task is to read out data from the door machine and display it in the main system.

Sounds easy? Well, in theory, it is.

In practice, the first problem is to choose an appropriate time attendance model. Given the requirement that we want to read out the data by our own software, the ideal model would be one which has some kind of web service (HTTP) API. We could then regularly call this API to import the door punches into our system.

Unfortunately, we were not able to find any single product supporting a HTTP API. All of the products we checked come with their own kind of time management software, typically some standalone application running on Windows, where you can create your users, setup working shifts, holidays etc. This software can connect to the device and calculate the working times.

When it comes down to APIs, about half of the products we’ve checked would be kicked out directly. They just didn’t offer any. The only way to read data out would be to used the software shipped with the device. Those which do offer an API would all ship with a SDK for C#/.NET.

Although we are a Ruby and not a .NET shop, we decided for a Fingertec Timeline 100. They have a fairly comprehensive website, offer a lot of different software to use with their devices, and claim their SDK being “well documented”. When you check their support sites and their documentation, you’ll find that quality is not that high. However, compared with the other manufacturers we examined, they looked best.

Checking Fingertec’s SDK and API documentation, it looked like using it would be days of pain. Fortunately, they offer some software which we could use instead of the SDK. The FTDP (Fingertec Data Processor) can be installed as a Windows service, reading the punch data regularly and writing it to a database (SQL Server or Oracle). Our software could then connect to that database, and we’re done.

So we setup FTDP and SQL Server as described in their guide. Sadly, the Windows service always failed to connect to the database. We’ve checked this problem with Fingertec’s support (they were really nice and responsive) and they confirmed that it’s a bug in the current FTDP version (1.7).

Finally, we came up with a hacky solution: Running FTDP as a Windows service is totally fine when using the local Access database (which is the default setup). You can then access the data by converting the Access .mdb file into CSV. We copy the FTDP.mdb file to our Linux server and use mdb-tools for conversion. mdb-tools provides the mdb-export command, so you could dump the data like

$ mdb-export /path/to/file.mdb Transaction -D "%Y-%m-%d %H:%M:%S"

To copy the file, we setup the FTDP data directory as a network share and mount it on the Linux server via Samba. (Update: In the meantime, we use AWS S3 to transfer the data.)