In a previous blog post I already briefly touched on the validate-content policy. However, that wasn't the main topic at the time; the focus was more on the performance and capacity impact of using this specific policy.
Recently I was tasked with setting up policy fragments to apply content validation on incoming messages in API Management. The policy itself seems quite straight forward, but I did run into something unexpected which I think is worth a blog post.
In every scenario where you store data, you need to make sure your data is as clean and relevant as possible. Especially when storing data in the cloud, where every byte stored and transferred costs money. Not only storing data has it's price tag, also having irrelevant/old/obsolete data will impact the overall performance so you might need to buy more capacity to keep the performance you need.
So for several reasons it's important to keep your data clean and tidy.
Sometimes you need to receive and process messages from a 3rd party supplier, but:
the supplier expects an HTTP endpoint to send the messages to you want to decouple receiving from processing, because you want asynchronous processing In this scenario the standard approach would be to use a queue, that can be either an Azure Service bus queue or an Azure Storage Account queue. For this use case I'm using a Storage account queue.
When you work with Azure API Management on a regular basis, you probably are familiar with policies. Policies allow you to perform actions or adjustments on the incoming request before it's sent to the backend API, or adjust the response before returning to the caller.
Policies can be applied on various levels, so called scopes, and each lower level can inherit the policy of a higher level.
Global level => executed for all APIs Product level => executed for all APIs under a product API level => executed for all operations under an API Operation level => executed for this single operation Maintenance and reuse issues The main problems with policies always have been maintenance and reuse.
Azure service bus is one of the services Microsoft has identified as part of the Integration Services and is an important component in messaging solutions. It can be interacted with using a variety of methods, like via the SDK or a REST endpoint. One of the other key integration services is Azure API management (APIM), and its used for centralizing endpoint management. In an integration landscape, also service bus endpoints should be exposed via API management so we can provide a consistent way of accessing endpoints to clients.
Azure API Management (APIM) is one of the main integration components in the API driven world today. It's a plaform for abstracting API details from client applications, making them more resilient to change.
APIM in it's most basic form is just passing on the request from client to API, but in many cases something needs to be done on APIM level to validate, handle, adjust or fix something in the flow.
I've been working with Azure Cosmos Db since it still was called Document Db. However, being an integration consultant it never was a real focus area, but on my current contract it's one of the main components of the backend. Starting from scratch, all the way to go-live, I've learned a lot and also found out a few decisions will make or break your solution.
In this blog post I'd like to share what I've learned.