The Azure Cosmos DB Blog

All about Azure Cosmos DB and Azure

Month: December 2017

Unusual activity on one of my API Apps

I use a product from a former MVP, Thomas Ardal to handle logging from my Azure Web and API Apps.

The product is

Every time there is an error I receive an email like the one shown below.


When I click on the link, I am able to view the detail view from my dashboard

The first thing I noticed is the URL. In this case it is a GET operation with /feed/ for the path.  My API App does not have an operation that has feed in the path.

In the upper right corner there is list symbol with a red star on it.  When I click on it,  I am presented with Quick Fixes for the issue, as shown below.

I want to be able to see where the Request originated from.  I click on WHOIS.  This takes me to dpip where I am able to see the Geo location for the IP Address as shown below

The Security rating provides me with additional information.

Clicking on the Proxy type Tor provides  me with more information,

Without I would not know about issues like this

Configuring my API App was easy.

I don’t usually write product reviews.

I highly recommend you take out for a test drive .

Storing Event Grid messages in Cosmos DB

I was working on a project that required a multi-tenant Logging and Notification Service

The solution I came up with was to use the Event Grid trigger for a  Logic App. There would be two Logic Apps; one for receiving the event message and the other for sending notifications as shown in the following figure.

The following are the steps in the workflow.

  1. Receive Event Messages from different publishers
  2. Loop through messages and parse out Errors Events.  Send the Error Events to the Notifications Logic App.
  3. In parallel, insert the Document into Cosmos DB and Data Lake Store.
  4. The Notifications Logic App evaluates the contents and queries Cosmos DB for the notification type (Email and/or SMS) and recipients
  5. The Notification is sent.

Because the Event sources were different, there was possibility that there could be duplicate Id’s in the Event message. In order to solve this issue, I used the Logic App Compose Action to wrap the Event Message and rename the Id to EventId as shown below.


To parse out the Error event type, I added a Decision Action using @equals(toUpper(triggerBody()?['eventType']), 'ERROR').  Additional logic can be added to satisfy any Business Rule.

I used the Cosmos DB Create or Update  document  Action to save the event messages. The Id value is auto generated, The partition key is the eventType.

Data Lake Store was used  for archival.  Because the messages were being saved to both Cosmos DB  and Data Lake Store at the same  time, all I needed to do is set the  TTL Time-To-Live value of 10 days on the Collection.  This eliminated the need to add a another Logic App to archive the Event before the Time-To-Live date.

Because the Notification Logic App uses a Manual Trigger, I needed to return a response back.


  • You can leverage Logic Apps with the Event Grid Trigger to handle Logging of any type of events.
  • You can save the Event message in Cosmos DB and concurrently archiving the message in Data Lake Store.
  • Using simple business logic for  evaluating the Event message
  • Storing Notification Recipient information in a Cosmos DB document.
  • The application follows the Azure  Event Driven Architecture  Architectural Style.
%d bloggers like this:
Skip to toolbar