An integration layer for my Digital Office Assistant
As the number of projects in our innovation practice is growing, we are in need of a solution that makes it much easier to exchange data between different data sources – like IoT sensors - and various digital touchpoints. During my graduation project I designed and developed an integration layer to access the different data sources through a single entry point. To proof the added value of this integration layer I also created a Digital Office Assistant application that makes use of the abstraction layer.
Hey google.. What is the status of Lamar?
Our innovation practice is responsible for some cool projects like the AI Garden, our Smart Office and the Meeting Room Dashboard. These projects are generating - and using - all kinds of data, stored in different databases and only accessible through their own unique endpoints.
Let’s take the Meeting Room Dashboard as an example: the application gets data from the sensors placed in the meeting rooms and needs to call the Microsoft Outlook API to get information about current meetings as well. This logic is hidden away in the back-end of the application, not accessible for any other projects, while a lot of these features can be reused for other purposes. So why not create a unison solution for this challenge?
Let's fix it!
To create a flexible integration layer I first did some research on different architectural styles like monoliths and microservices. After this I made the decision to go with a microservices architecture in combination with the gateway pattern. Why? A microservices architecture offers the freedom to build independent working services, which can be written in any preferred language and can easily scale independently from each other.
The gateway pattern makes sure the different services are hidden from the clients and creates a single point of entry to get access to the available services. The following illustration shows a high-level overview of the current architecture.
Figure 1: Architectural overview
By implementing a microservices architecture new challenges arise. For example: How does the gateway find the independent services and how do those services find each other when necessary? That’s where service discovery is your friend. Service discovery is the automatic detection of services offered on a given network and it aims to reduce the configuration efforts for developers.
By using a service discovery provider, Consul in this case, the gateway queries the service registry to get the IP-address of a given service. Therefore, the independent services have to register themselves with Consul. To make this process dynamic as well, I used a handy tool called Registrator which automatically registers services for any Docker container by inspecting containers as they come online.
My Digital Office Assistant
As a result of building the gateway we can now use it to get data more easily in other projects. As mentioned before, my project consisted of creating a Digital Office Assistant using the Google Home Hub.
When it comes to digitalizing an office assistant, what kind of questions can we ask? Thanks to the available sensor data, questions like “What is the temperature in Bell?” or “Can you give me the current status of Lamar?” are fun questions to ask and it gives some nice visual feedback as shown in the photo above.
It really becomes interesting when Outlook comes into play, simply ask for an overview of the meetings in the 'Bell' room or ask for example which meeting rooms are available between a given time period.
Hey Google... What are the available meeting rooms between 9 and 10 am?
How cool would it be to book a meeting room through the Google Home Hub? As it’s already possible to get an overview of available meeting rooms between a given time period, it would be the next step to actually schedule a meeting in one of the available rooms. Using the new integration layer deploying new features like this example is now a lot easier!
Looking for a great internship? please drop us a line