TrackTik Data Replication Service

TrackTik’s Data Replication/Warehouse helps security organizations make smart business decisions.

With Data Replication you can host your own database service that receives replicated data from TrackTik's source to yours. This empowers you to control and own the data and service environment it's hosted in. With access to all that production data within your own architectural domain you then become empowered to analyze, create reports and dashboards, and unlock key insights using your favourite tools like Tableau, Microsoft Power BI, or Looker Studio. 

Key Benefits

• Store : historical and current data all in one place
• Integrate : critical data from multiple sources
• Access : data sets and present detailed intelligence
• Analyze : data over time to spot trends
• Generate : reports to share across the organization
• Transform : data into actionable insights
• Perform : configure and control the CPU, RAM and indexes of your data and data services
• Flex : add schemas, users, tables, views
• Connect : manage connections and access for any number of users

Synchronization Methods

In most cases the solution should be configured for a MySQL native replication service, but we can also accommodate the creation of credentials for a snowflake service that fetches its own schema and data. With either solution you should plan to do your BI work from your own hosted solution and copy of the data, and not direct on the source data warehouse server.

Table Definition Example

Data Warehouse Tables are constructed from calls made to TrackTik’s API (within limits, see next section). They contain the main data of responses to dedicated entities like /rest/v1/employees . 

E.g. that references checkpoint-scans

Here’s an example of a table definition for data obtained from the API's /employees endpoint:

CREATE TABLE `dwh_employees` (
 `id` int NOT NULL,
 `customId` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
 `firstName` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
 `lastName` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
 `jobTitle` varchar(255) DEFAULT NULL,
 `email` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
 `status` enum('INACTIVE','ACTIVE','TERMINATED','BANNED') CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
 `region` int DEFAULT NULL,
 `password` varchar(255) DEFAULT NULL,
 `employmentProfile` int DEFAULT NULL,
 `gender` enum('M','F','B') DEFAULT NULL,
 `age` int DEFAULT NULL,
 `birthday` datetime DEFAULT NULL,
 `ageGroup` varchar(255) DEFAULT NULL,
 `address` int DEFAULT NULL,
 `tags` varchar(255) DEFAULT NULL,
 `notificationSettings` int DEFAULT NULL,
 `language` enum('EN_US','FR','RO','ES','DE','NL','PT','SV','ZH-HANS','TH') DEFAULT NULL,
 `name` varchar(255) DEFAULT NULL,
 `primaryPhone` varchar(255) DEFAULT NULL,
 `secondaryPhone` varchar(255) DEFAULT NULL,
 `username` varchar(255) DEFAULT NULL,
 `lastLoggedInOn` datetime DEFAULT NULL,
 `avatar` text,
 `createdBy` int DEFAULT NULL,
 `createdOn` datetime DEFAULT NULL,
 `updatedBy` int DEFAULT NULL,
 `updatedOn` datetime DEFAULT NULL,
 `_update_time` int DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `region` (`region`),
 KEY `employmentProfile` (`employmentProfile`),
 KEY `gender` (`gender`),
 KEY `address` (`address`),
 KEY `notificationSettings` (`notificationSettings`),
 KEY `language` (`language`),
 KEY `status` (`status`),
 KEY `createdBy` (`createdBy`),
 KEY `updatedBy` (`updatedBy`),
 KEY `updateTime` (`_update_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

You’ll notice that for some columns, like address, the value is an integer. That’s because this is the id number of the address that would be available in a different table. The TrackTik API can follow and pull records from an id like that via its relation lists mechanism. The DWH solution however can only show main entities, so you'll have to perform INNER JOINs.