CONNECTED Conference 2023 | November 15, 2023 | API Management: Best practices, tips and tricks | Video

CONNECTED Conference 2023 | November 15, 2023 | API Management: Best practices, tips and tricks | Video

Last November 15, 2023, I had the pleasure of delivering a session about Azure API Management at the CONNECTED Conference 2023. This conference is one of the most important events on Microsoft Integration in German-speaking countries, and it has been a great honor for me to be invited to participate in the last few years.

My session was about API Management: Best Practices, Tips and Tricks where I talked about best practices and small tips and tricks that we can apply to our Azure Integration projects when using Azure API Management.

  • Session name: API Management: Best Practices, Tips and Tricks.
  • Abstract: Unleash the full potential of Azure API Management with this session focused on efficient integration building. Discover tips and tricks that empower developers to be more productive while adhering to best practices, resulting in reliable and effective integrations.

Today I have the pleasure of informing you that the session is now available online:

[embedded content]

You can see all the session videos of the conference, most of them in German, here: https://www.quibiq.de/aktuelles/quievents/connected/on-demand/

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

CONNECTED Conference 2023 | November 15, 2023 | API Management: Best practices, tips and tricks

CONNECTED Conference 2023 | November 15, 2023 | API Management: Best practices, tips and tricks

CONNECTED Conference 2023 (formerly called Microsoft Integrate Conference DACH) is one of the most important events on Microsoft Integration in German-speaking countries. I’m honored to be invited again to this event.

As always, I’m super excited about presenting at this event alongside great speakers and well-known Microsoft names like Harold Campos and Kent Weare and my long-time friends Nino Crudele and Matthias Lögdberg.

This will be a two-day virtual event, and I will be there on the second day to present a session about API Management. The title of my session will be API Management: Best Practices, Tips and Tricks.

API Management: Best Practices, Tips and Tricks.

As I mentioned before, my session will be all about best practices and small tips and tricks that we can apply to our Azure Integration projects. For those reasons, I would like to invite you to join me at the CONNECTED Conference 2023 virtual event tomorrow, November 15, 2023.

Session name: API Management: Best Practices, Tips and Tricks.

Abstract:

Unleash the full potential of Azure API Management with this session focused on efficient integration building. Discover tips and tricks that empower developers to be more productive while adhering to best practices, resulting in reliable and effective integrations.

Join us and reserve your presence at the CONNECTED Connected 2023 virtual event!

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

API Management Best Practices, Tips, and Tricks: #4 Include a Cache Response Header

API Management Best Practices, Tips, and Tricks: #4 Include a Cache Response Header

Here we are, ready for another edition of API Management Best Practices, Tips, and Tricks. Until now, I have been addressing some tips to apply to your Azure API Management policies. However, today I will address a good Best practice that you must consider while implementing cache on your operations: Including a Cache Response Header on your API responses.

#2 Include a Cache Response Header

In my previous article, I briefly mentioned this topic, but I think it should have its own individual highlight. Headers are an essential part of REST API design, providing a way to include additional information about the request and response. They are a key peace to allow us to control the behavior of the API. Some typical headers used in REST APIs include Content-Type, Accept, Authorization, and User-Agent.

One good best practice while applying cache responses on our APIs – which has the advantage of significantly reducing latency for API callers – is to inform API users when they are receiving a cached response or not. This way, users or systems know if they are working with live-fresh data or not, and provide actions according. Sometimes we cannot rely on a cached version of the resource, sometimes it doesn’t matter. However, by having this strategy, you will be enriching and improving your APIs.

And once again, this is quite simple to accomplish:


	...
			
			
				
					
						
						
							application/json
						
						
							true
						
						@((string)context.Variables["varTokenValue"])
					
				
			
   ...

...

	...
	
		
		
			text/plain
		
		
			false
		
		@((string)context.Variables["varToken"])
	
   ...

I hope you enjoy this tip and stay tuned for the following Azure API Management Best practices, Tips, and Tricks.

If you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

API Management Best Practices, Tips, and Tricks: #3 How to implement a cache refresh policy

API Management Best Practices, Tips, and Tricks: #3 How to implement a cache refresh policy

Here we are, ready for another edition of API Management Best Practices, Tips, and Tricks. Today, we will address another helpful Best practice, Tips, and Tricks that you must consider while implementing your API policies: How to implement a cache refresh policy.

#2 How to implement a cache refresh policy?

As Microsoft documentation references, APIs and operations in API Management (APIM) can be configured with response caching. Response caching can significantly reduce latency for API callers and backend load for API providers. APIM provides an out-of-the-box Internal cache, but this built-in cache is volatile and is shared by all units in the same region in the same API Management service. However, if you desire more robustness and additional capabilities, you can use an external Azure Cache for Redis, for example.

An excellent example of using cache capabilities is to store access tokens. Usually, API tokens have a “time-to-live” (TTL), which is the maximum time that the access token will be valid for use within the application. That means we don’t need to regenerate a token each time we call our API. Instead, we can cache that value in APIM, specifying the cache duration.

When working with cache inside APIM, there are at least two policies you need to know:

  • cache-store-value: The cache-store-value performs cache storage by key. The key can have an arbitrary string value and is typically provided using a policy expression.
  • cache-lookup-value: Use the cache-lookup-value policy to perform cache lookup by key and return a cached value. The key can have an arbitrary string value and is typically provided using a policy expression.

cache-store-value

Policy statement:


This is a practical sample of this policy:


cache-lookup-value

Policy statement:


This is a practical sample of this policy:


Cache is quite simple to implement and use inside APIM. However, and this is the reason for this blog post, in many situations, we have the need to refresh or force a refresh on our cache or in our cache value. Let’s say that while developing our operation policy, we made a mistake, like caching an incorrect value or setting the duration incorrectly. Now we need to refresh the value that is cached, but we don’t want to wait for the cache duration to expire – that can be 30 min – or modify the operation policy to add a cache removed statement and then modify that policy again to remove that “workaround”.

So, how can we easily handle these requirements or capabilities?

Well, the best way is to always address this requirement by design and implement a cache refresh mechanism.

Taking the token example, this can easily be implemented by:

  • Adding an optional header on your API methods, let’s say:
    • skip-cache header that “allows” a true or false value
      • If it is true, you need to force to refresh the value that is cached.
      • Otherwise – if the value is false – you use the cached value.
  • In the inbound policy of your operation, add the following statements:
    • Read the value of the skip-cache header. If it doesn’t exist, the default value is false.
    • Check if the skip-cache header value is false:
      • If the condition is true:
        • Try to read the value from the cache:
          • If it is present in the cache, return the cached value.
          • If it is not present, call the token renewal API.
    • Otherwise, perform a call to the token renewal API.

	
	
		
			
			
				
					
						
						
							application/json
						
						
							true
						
						@((string)context.Variables["varTokenValue"])
					
				
			
		
	
    ... implement the call to the token renewal API

Note: It is a good practice to add a response header stating the response is cached.

  • In the outbound policy of your operation, add the following statements:
    • Read the token renewal API response.
    • Store the value in the cache for next time.
    • And return the response back to the caller.

	<set-variable name="bodyResponse" value="@(context.Response.Body.As())" />
	
	
	
	
		
		
			text/plain
		
		
			false
		
		@((string)context.Variables["varToken"])
	

I hope you enjoy this tip and stay tuned for the following Azure API Management Best practices, Tips, and Tricks.

If you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

API Management Best Practices, Tips, and Tricks: #2 How to access a context variable on body transformation using liquid

API Management Best Practices, Tips, and Tricks: #2 How to access a context variable on body transformation using liquid

Here we are, ready for another edition of API Management Best Practices, Tips, and Tricks. In my prior blog post, I inaugurated this series by addressing the first best practices, tips, and tricks—How to validate if a Header is an empty string. Today, I will speak about another helpful Best practice, Tips, and Tricks that you must consider while implementing your policies: How to access a context variable on body transformation using liquid.

#2 How to access a context variable on body transformation using liquid

Liquid is an open-source template language created by Shopify and written in Ruby. It is the backbone of Shopify themes and is used to load dynamic content on storefronts.

Azure API Management uses the Liquid templating language (DotLiquid) to transform the body of a request or response. This can be effective if you need to reshape the format of your message completely. That can be accomplished using the set-body policy inside inbound, backend, outbound, or on-error policies. For example:


	
	…
	
		{
			"Header": {
				"OrigSystem": "API Management",
				"DateRequest": "{{body.MsgDate}}"
			},
			"InputParameters": {
				"MyObject": {
					"Reference": "{{body.ExtId}}",
					"Type": "{{body.ObjType}}",
					"Id": "{{body.Id}}"
				}
			}
		}
	

On the other side, inside API Management policies, users will always have the availability to create context variables or, in this particular case, User-Defined Variables or Policy Variables (whatever you want to call them) to store and manipulate data specific to your API’s needs. These variables are often used in policies to make decisions or modify requests and responses.

Creating or reading a value of a context variable inside an APIM policy is a straightforward operation. Once again, Microsoft documentation will explain that simple operation very well. To declare a context variable and assign it a value, we utilize the set-variable policy, specifying the value through an expression or a string literal. For example:


Or


To read a context variable and assign it a value, we utilize the following expression:

(string)context.Variables["myVar"]

Or using the GetValueOrDefault function:

context.Variables.GetValueOrDefault("myVAr", "This is the default value")

What is more difficult is to find a good documentation that explains how to read the value of a context variable on body transformation (set-body policy) using the liquid template. I won’t be wrong to say that 98% of the information I looked up online was wrong because most of them say that is using the same way(string)context.Variables[“myVar”]what is incorrect. We should use a dot (.) notation inside the liquid to access the variables, similar to many programming languages used to access properties deep within the structure. So, in this case, we should use the following:


	
		
		
			
				Sandro Pereira
				{{context.Variables.myVar}}
			
		
	

I hope you enjoy this tip and stay tuned for the following Azure API Management Best practices, Tips, and Tricks.

If you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

API Management Best Practices, Tips, and Tricks: #1 How to validate if a Header is an empty string

API Management Best Practices, Tips, and Tricks: #1 How to validate if a Header is an empty string

If you follow my blog posts, you will not be surprised that I love to speak about Best Practices, Tips, and Tricks. I wrote in the past Power Automate Best Practices, BizTalk Server, and often about Logic Apps Best Practices, Tips, and Tricks. So it’s not surprising that I would address other Azure Integration Services sooner or later, this time Azure API Management!

Let’s embark on a new journey as we begin a series of blog posts dedicated to API Management Best Practices, Tips, and Tricks. To start this series, I chose a topic that I found very useful in many situations: How to validate if a Header is an empty string?

#1 How to validate if a Header is an empty string?

Verifying whether the header contains a specific value(s) is straightforward. In fact, Microsoft’s documentation covers this as the very first topic on their page. To accomplish that, we can use the check-header policy to enforce that a request has a specified HTTP header.


	application/json
	plain/text

In this case, our request needs to have the Content-Type header, and the accepted values are:

  • application/json
  • or plain/text

If you exclude this header or opt for an alternative value for it, you’ll trigger a 401 error due to the missing Content-Type header:

{
	"statusCode": 401,
	"message": "Missing Content-Type header"
}

Now, checking only if it exists without any value restriction is poorly explained in MSFT documentation. However, it is still very simple to implement since values are options on the check-header policy. To accomplish that, we just need a simple instruction line:


What you may find less commonplace is the technique for confirming the existence of a Header that isn’t empty. To clarify:

  • The header needs to exist;
  • The header can contain any value except being null, an empty string, or a string containing only blank spaces.

Well, of course, you may find multiple ways to accomplish this task, even using the check-header policy to validate the existence of the header and another strategy to validate if the value was not empty. I decided in my approach to suppress the use of the check-header policy, and instead, I will use the following approach:

  • Read the Header using the context.Request.Headers.GetValueOrDefault(“my-header”) expression.
  • And then using a condition to see if the value is empty or not

You can accomplish that by using the following policy:



	<when condition="@(context.Variables.GetValueOrDefault("myHeaderValue") == null 
			|| string.IsNullOrEmpty(context.Variables.GetValueOrDefault("myHeaderValue")) 
			|| context.Variables.GetValueOrDefault("myHeaderValue").Contains("undefined"))"> 
		
			
			
				application/json
			
			{
				"error": {
					"code": "401",
					"message": "My-Header header is missing or empty"
				}
			}
		
	

I hope you enjoy this tip and stay tuned for the following Azure API Management Best practices, Tips, and Tricks.

If you liked the content or found it helpful and want to help me write more content, you can buy (or help buying) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

Unleash your API Management skills: how to read Query and URI parameters

Unleash your API Management skills: how to read Query and URI parameters

Before we focus on the goal of this blog post topic, let’s first understand the distinction between Query Parameters and URI Parameters in API Design, this is crucial for you to know. URI Parameters, also known as Path Parameters, are primarily used to identify specific resources, while Query Parameters are utilized for the sorting and filtering of these resources.

For instance, imagine a scenario where you need to identify a book by its ISBN (also known as the book ID); in this case, you’d make use of the URI parameter, something like:

GET /books/{book_id}

An example of this call should be GET /books/978-1-3999-0861-0

However, if your aim is to retrieve all the books categorized by genre, such as novels, then we should use a Query parameter, something like:

GET /books?gender={type}

An example of this call should be GET /books?gender=novels

Now that we know the key difference between Query Parameters and URI Parameters, let’s see how we can read these parameters inside Azure API Management policies.

How to read URI parameters inside Azure API Management policies

Taking the sample above, for us to read the URI parameter, we have to use the following expression:

context.Request.MatchedParameters["parameter-name"]

Using the previous sample GET /books/{book_id} the expression should be:

context.Request.MatchedParameters["book_id"]

We can also make use of the GetValueOrDefault function to retrieve the URI parameter:

context.Request.MatchedParameters.GetValueOrDefault("parameter-name","optional-default-value")

And, of course, we can apply this expression to several operations like:

  • Check URI parameter existence:
    • context.Request.MatchedParameters.ContainsKey(“book_id”) == true
  • Check if the URI parameter has the expected value:
    • context.Request.MatchedParameters.GetValueOrDefault(“book_id”, “”).Equals(“978-1-3999-0861-0”, StringComparison.OrdinalIgnoreCase) == true

How to read Query parameters inside Azure API Management policies

Once again, taking the sample above, for us to read the URI parameter, we have to use the following expression:

ccontext.Request.Url.Query["parameter-name"]

We can also make use of the GetValueOrDefault function to retrieve the URI parameter:

context.Request.Url.Query.GetValueOrDefault("parameter-name", "optional-default-value")

Using the previous sample GET /books?gender={type} the expression should be:

context.Request.Url.Query.GetValueOrDefault("type")]

And, of course, we can apply this expression to several operations like:

  • Check Query parameter existence:
    • context.Request.Url.Query.ContainsKey(“type”) == true
  • Check if the Query parameter has the expected value:
    • context.Request.Url.Query.GetValueOrDefault(“type”, “”).Equals(“Novels”, StringComparison.OrdinalIgnoreCase) == true

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

Using Liquid filters in APIManagement to transform messages whitepaper

Using Liquid filters in APIManagement to transform messages whitepaper

Those who know me and follow me are used to seeing me publishing several resources, including whitepapers. But this one is different! Typically, when it comes to whitepapers or books, I usually release them in BizTalk360 or Serveless360, a partnership that I have since many years, and you should expect to find it more in the future. However, this is the first whitepaper I have published under the DevScope umbrella, and I could be so proud of the result.

Note: not only I’m proud of the end result of this whitepaper, which I personally find this information very useful, but I’m also in love with my new corporate photo!

I typically write about “stuff” I work on daily bases, and for the past months, I have been working a lot with Liquid Template to perform transformations on API Management. Liquid is an open-source template language created by Shopify and written in Ruby. It is the backbone of Shopify themes and is used to load dynamic content on storefronts. However, Azure API Management uses a subset of Liquid templating language to transform the body of a request or response: DotLiquid

If it is true that we can find excellent Shopify documentation, the same may not be that simple for DotLiquid, and I struggle a little to get decent examples of how to use Liquid Filters in API Management, and that was the main reason why I decided to write this whitepaper.

What is DotLiquid?

DotLiquid is a deviation from Shopify’s original liquid template language. It is a .Net port of the popular Shopify’s Liquid templating language. It is a separate project that aims to retain the same template syntax as the original while using .NET coding conventions where possible. However, they are not entirely the same. In some cases, they have different behaviors.

Liquid uses a combination of objects, tags, and filters inside template files to display dynamic content.

Where:

  • Objects contain the content that Liquid displays on a page. Objects and variables are displayed when enclosed in double curly braces: {{ and }}.
Hi my name is {{ author.name }}
  • Tags create the logic and control flow for templates. The curly brace percentage delimiters {% and %} and the text that they surround do not produce any visible output when the template is rendered. This lets you assign variables and create conditions or loops without showing any of the Liquid logic on the page.
{% if author %}
 Hi my name is {{ author.name }}!
{% endif %}
  • Filters change the output of a Liquid object or variable. They are used within double curly braces {{ }} and variable assignment and are separated by a pipe character |.
{{ "Sandro" | Append: " Pereira" }}

In this whitepaper, I’m going to focus on the DotLiquid Filters you can use on API Management to transform the body of a request or response.

What is a liquid filter?

As mentioned above, Filters change the output of a Liquid object or variable. They are used within double curly braces {{ }} and variable assignment and are separated by a pipe character |. They are like functions in C# code or Functoids in BizTalk Server maps.

If we apply, for example, the Append filter like:                                                              

{% assign myvariable = "Sandro" %}
{{ myvariable | Append: " Pereira" }}   

The end result will be: Sandro Pereira

We can also apply multiple filters on one output which are applied from left to right. Like a PowerShell pipeline. A PowerShell pipeline is a series of commands connected by pipeline operators (|). Each pipeline operator sends the results of the preceding command to the next command. Filters use the same concept. For example:

"Name": "{{ "Sandro Pereira" | Split: " " | Last }}"

The end result here will be: “Name”: “Pereira”

Download

You can see the official release announcement here: Download Sandro Pereira’s whitepaper on Liquid Filters.

You can download, for free, the Using Liquid filters in APIManagement to transform messages whitepaper here:

Hope you find this useful! So, if you liked the content or found it useful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! ?

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

April 19, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

April 19, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly updates can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

Microsoft Announcements and Updates

Community Blog Posts

Videos

Podcasts

How to get started with iPaaS design & development in Azure?

  • Robust Cloud Integration with Azure
  • Microsoft Azure for Developers: What to Use When
  • Serverless Computing: The Big Picture
  • Azure Logic Apps: Getting Started
  • Azure Logic Apps: Fundamentals
  • Microsoft Azure Developer: Creating Enterprise Logic Apps
  • Microsoft Azure API Management Essentials
  • Azure Functions Fundamentals
  • Cloud Design Patterns for Azure: Availability and Resilience
  • Architecting for High Availability in Microsoft Azure

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

The post April 19, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS appeared first on Hooking Stuff Together.

April 12, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

April 12, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly updates can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

Microsoft Announcements and Updates

Community Blog Posts

Videos

Podcasts

How to get started with iPaaS design & development in Azure?

  • Robust Cloud Integration with Azure
  • Microsoft Azure for Developers: What to Use When
  • Serverless Computing: The Big Picture
  • Azure Logic Apps: Getting Started
  • Azure Logic Apps: Fundamentals
  • Microsoft Azure Developer: Creating Enterprise Logic Apps
  • Microsoft Azure API Management Essentials
  • Azure Functions Fundamentals
  • Cloud Design Patterns for Azure: Availability and Resilience
  • Architecting for High Availability in Microsoft Azure

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

The post April 12, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS appeared first on Hooking Stuff Together.