Nov 222019


In our development process e believe a lot in microservices and the CICD philosophy. To achieve that we have introduced feature toggles to control the features that are already delivered to the customers. So when the feature is stable enough we enable the feature on the next update and the new features is usable in the product.

With the passage of time and maturity in the product we moved to tenant based solution. The biggest challenge that we faced in that was to toggle functionality based on customer. We had our toggles loaded in the start up of the application. After the start up the objects were registered based on the toggle and the application was started. Now in case of single Tenant installation that was not a problem as we could easily restart the customer to load the latest token. With a multi tenant installation it’s a bit hard to do that as we have to restart all the tenants in order to load the tenants.

So in this post I am going to address this problem and also discuss the solution that we implement. So our old system had the following architecture.

There are my reference classes

So I have a two services service class On and service class Off. The service class On will be called if the toggle is set to ON the service class Off should be called if the toggle is set to OFF

Here is where I am using the toggle and the service so the following steps are performed in this class

  1. Load the toggle
  2. Initialize the service collection
  3. Register based on toggle
  4. Initialize the service
  5. Access the Serve method
  6. Ask user if he wants to continue and if yes continue to step 5

Now when I run this code I will see the following output

Now in this output even if I change the content of the toggles.txt the new toggles will not be effected until I restart the application.

So our solution was to handle it with some changes in the way we load and register the application. so instead of loading the toggle in the beginning we added that part in out interceptor. Before I got into details let me talk a bit about the interceptor.

In the old solution we had toggle information loaded before we access the object. So we already know what type of object it was. In the new solution we will write an interceptor that will be called every time we initialize that service object. Which will give us the opportunity to figure out the toggle before assigning the type of the object lets see the code for better understanding.

So the most important thing to note here is on line 17,18 and 19. We register both the On and off service and then we register the service interface using the Register Capability Components. The register combability is added via extension method to the service collection.  

Every time we access the “Serve” method this capability interceptor is called and the toggle is loaded to see load the type of the object. This type if based on the provided toggles. So the toggles are accessed and the type is determined before the method invocation. Lets run the program again to see the output.

As mentioned above the toggles are updated with stopping the application and the latest change was impacted. This is how we solved the multi feature multi-tenant dynamic invocation problem. I know that this could be done in million ways and we could also optimize the code to be more efficient. This code example is just to highlight the problem and a potential solution.

The code is available at

 Posted by at 10:34 am
Nov 222019

Step 1: Register an app in active directory app registration

You need to do a new application registration

Once that application is registered you need the application Id which is also called the client id. The other thing that you need to configure the permission.

In permission you need to give access to log analytics data as user that should be given

Step2: then we should have a secret id from the azure

That you can get from the key configure that in the app that you just register and make a new key you need o save that

Once you have that lets switch to log analytics

Step3: you need to the workspace id from the log analytics

Step4: to access control

Add a new role assignment

Role: Contributor

Select: the app that you created


Now you have set the framework and the two way communication between the app and log analytics. Now comes the code part so we need the following code

Lets walkthrough the code a bit.

So the first thing that we do in GetMetricBeat is to get the access token. Before we move forward we can see how that is made. So to get the token we are contracting the URL. To access the long analytics the URL is  ‘’tenantID. Once that is constructed we need to create the client credential for the app that that we have created by providing the clientappID and clientAppSecret to acquire the access token.

After that we are constructing a very basic log analytics query which is in Json format.

To access the log we have to create a HTTP request to ‘{workspaceId}/query’ by providing the workspace if. The http client must be given the access token for a valid request. Once we post the request a json will be returned as a return string value that we can parse for our result.

 Posted by at 10:28 am