How to manage feature flags in ASP.NET Core apps with Azure?
No matter how simple or complex an application is, choosing the right configuration provider right at the start will mak...
Time tracking a project is often one of the key KPIs and yet it can be difficult to report it accurately. Here at Predica, we have developed our own solution which is easy to use, doesn’t require much time on the part of the users and is even possible offline. We have also learned a few valuable lessons along the way. Here is a story of our in-house time tracking solution, LeanTS.
For consultants, one of the most important KPIs is reporting billable/project hours. Back when many of us at Predica today worked at Microsoft Services, we had to use a tool called Change Point. This application was not very user-friendly, and reporting rules made it worse.
Predica has a similar profile to Microsoft Services – we deliver technology consulting, and many business rules are the same, including tracking billable hours. At Predica, we knew that it could be done simpler – that is how LeanTS was born. It is the easiest time tracking application I‘ve ever used. Greg, our CEO, wrote a nice business article about how important time really is to a company and how LeanTS can make better use of it.
I would like to give you a technical overview of our tool, and it’s history – how it evolved from the on-premise application to Azure App, to end as a Multi-Tenant Cloud system.
As I mentioned, our experience taught us about time-tracking application bad practices. Here at Predica, we had simple and clear requirements:
We decided to use the personal user calendar as a way of entering data. Using Outlook you can even do this offline. Now you can manage and plan your work using a single application.
Here’s how it works:
It’s hard to believe, but a long time ago we used Google Apps. Then our LeanTS was simple. We had a virtual machine with console application and database. For reports, we used a simple Excel with a pivot table.
Take a look at the diagram below.
Our goal is to focus on Microsoft technologies so we migrated from Google Apps to Office 365. We rebuilt LeanTS and migrate to Azure. This is the version we use at Predica.
As our company grew, we needed to change reporting and flexibility. We added analytics database to the architecture to quickly generate standard reports and aggregate data.
For calendar sync, we used EWS Managed API. There was no other option at that time, and a lot of complications with the configuration are the result of using this API. For example, we must set permission for each mailbox that is read by the sync component.
Along the way, we added some features that required write access to calendars. If we find an entry that doesn’t match the rules, we mark it with the proper category.
From a deployment and maintenance perspective, this architecture is still a typical Enterprise Application. You need to configure the specific account, set up security and calendar access, set up all the infrastructure, etc. This is, of course, only part of our environment landscape. I plan to write more about our systems so stay tuned!
We believe our approach to time reporting is unique and adds value for other organizations. That’s why we created a Software as a Service (SaaS) version.
SaaS is a model of delivering software to customers. A great example is Office 365. Microsoft charges a monthly fee for each user and gives them access to their software and services. You can ask for 100, 1,000 or 100,000 mailboxes for your employees. It’s up to the provider to scale and manage the service. This allows for greater flexibility for the organization.
We had to redesign the whole architecture of LeanTS to make it a product and make deployment and onboarding as easy as possible.
The first step in changing the solution was designing new architecture. We had to plan for multitenancy and data separation.
Originally we had only one database. When designing Multi-Tenancy you must ensure that each customer can access only his data. You can achieve this in a few ways:
We opted for the Separate Databases approach to ensure the greatest level of separation. The customer can also get read-only permission directly to his DB. For now, we allow it, but we will decide in future if we require a proxy API.
To simplify the sync and configuration process, we had to rewrite the whole backend. As I mentioned, we used EWS Managed API, but Microsoft provided us with Microsoft Graph.
You can use Microsoft Graph to build apps for organizations and consumers that connect to a wealth of resources, relationships, and intelligence, all through a single endpoint.
Graph solved many problems compared to EWS Managed API:
When creating multi-tenant apps, other parties need to trust your application. For example, when you install/trust LeanTS to read data from your calendars.
Following Microsoft documentation:
Azure AD’s consent framework makes it easy to develop multi-tenant web and native client applications that need to access web APIs secured by an Azure AD tenant, different from the one where the client application is registered. These web APIs include the Microsoft Graph API (to access Azure Active Directory, Intune, and services in Office 365) and other Microsoft services APIs, in addition to your own web APIs. The framework is based on a user or an administrator giving consent to an application that asks to be registered in their directory, which may involve accessing directory data.
For example, if a web client application needs to read calendar information about the user from Office 365, that user will be required to consent to the client application. After consent is given, the client application will be able to call the Microsoft Graph API on behalf of the user and use the calendar information as needed. The Microsoft Graph API provides access to data in Office 365 (like calendars and messages from Exchange, sites and lists from SharePoint, documents from OneDrive, notebooks from OneNote, tasks from Planner, workbooks from Excel, etc.), as well as users and groups from Azure AD and other data objects from more Microsoft cloud services.
This allowed us get rid of a service account and complicated permission setup. Now you have a simple window with permission settings for the whole application. You can also easily change the setup.
I believe this gives you a nice high-level architecture overview of the most important application at Predica. Our journey taught us a lot about Azure and application optimization. From a technical perspective, if you are making Azure or Office 365 applications look to Microsoft Graph and Consent Framework.
If you want to know more about LeanTS or any other component in our environment just contact us!
You can also try LeanTS yourself!
Read other similar articles