Friday Fact: XML to JSON Conversion in API Management and Logic Apps have different behaviors

Friday Fact: XML to JSON Conversion in API Management and Logic Apps have different behaviors

I don’t know the reason why two products from the same family – Azure Integration Services – have completely different behaviors while converting XML to JSON, but that is the current reality. It is a fact! API Management and Logic Apps have different behaviors while applying this conversion, and that is one of the main reasons that I decided to create an Azure Function to convert XML into JSON, to keep the consistency between these two products.

While using API Management, we can use the xml-to-json policy to convert a request or response body from XML to JSON. However, when dealing with XML namespaces and prefixes, which is quite normal when working with XML messages, the policy has, in my opinion, a strange conversion behavior:

  • It converts the prefixes that in XML are represented by prefix:MyField into prefix$MyField. In order words, it replaces the colon character (:) with the dollar character ($).

Let’s take this XML sample in order for you to see the upcome result of that xml-to-json policy:

Book-Signing Event Convert it to JSON

The result will be:

{
    "section": {
        "@xmlns": "http://www.test.com/events",
        "@xmlns$bk": "urn:loc.gov:books",
        "@xmlns$pi": "urn:personalInformation",
        "@xmlns$isbn": "urn:ISBN:0-999-99999-9",
        "title": "Book-Signing Event",
        "signing": {
            "bk$author": {
                "@pi$title": "Mr",
                "@pi$name": "My Name"
            },
            "book": {
                "@bk$title": "How cool is XML",
                "@isbn$number": "9999999999"
            },
            "comment": {
                "@xmlns": "",
                "#text": "Convert it to JSON"
            }
        }
    }
}

I think this behavior is strange and incorrect.

Now, if we take the same XML payload and try to convert it inside Logic Apps using the json() expression that returns the JSON type value or object for a string or XML. In this case, using, for example, the following expression:

  • json(xml(triggerBody()))

The result will be:

{
    "section": {
        "@xmlns": "http://www.test.com/events",
        "@xmlns:bk": "urn:loc.gov:books",
        "@xmlns:pi": "urn:personalInformation",
        "@xmlns:isbn": "urn:ISBN:0-999-99999-9",
        "title": "Book-Signing Event",
        "signing": {
            "bk:author": {
                "@pi:title": "Mr",
                "@pi:name": "My Name"
            },
            "book": {
                "@bk:title": "How cool is XML",
                "@isbn:number": "9999999999"
            },
            "comment": {
                "@xmlns": "",
                "#text": "Convert it to JSON"
            }
        }
    }
}

In this case, the json() expression does not replace the colon character (:) with the dollar character ($) in the prefixes. It’s maintaining, which I think is the correct behavior.

To lazy to read? We’ve got you covered! Check out our video version of this content!

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can help us buy a Star Wars Lego for Sandro’s son! 

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 | 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

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v8.0.1)

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v8.0.1)

In my previous update, I discussed my intention to release a new major version of my stencils. However, I’ve opted for a gradual approach, releasing minor updates along the way. This way, it becomes easier for me because I don’t need to spend long periods allocated to this task, and at the same time, all of you can start enjoying these new icons.

Keeping my promise, I’m presenting another update. I hope it meets your expectations! If you have any specific requests, don’t hesitate to share them with me.

What’s new in this version? (for now)

The main goal of this release was to provide the new icons present in the Azure Portal, on the Power Platform, and new existing Services. In this version, the changes and additions are:

  • New stencil packages: Additional stencil packages were incorporated into this project to enhance the discoverability of shapes:
    • MIS Azure Integration Services: this file contains shapes related to Azure Integration Service and messaging.
    • MIS Microsoft Fabric: this file contains shapes related to Microsoft Fabric – This was actually a request made by a community member. And credits to Sam Debruyn for these Microsoft SVG files. I only had the work to “convert” them into proper Visio stencils.
  • Move some shapes: I reorganized and relocated certain shapes to other files within this package.
  • SVG Files: Add new SVG files;
  • Special Highlights: API Center, Policy fragments, Event Grid, Event Grid: Namespace, Partner namespaces and Partner registrations or APIM Schemas

Microsoft Integration, Azure, Power Platform, Office 365, and much more Stencils Pack

Microsoft Integration, Azure, Power Platform, Office 365, and much more Stencils Pack it’s a Visio package that contains fully resizable Visio shapes (symbols/icons) that will help you to visually represent On-premise, Cloud or Hybrid Integration and Enterprise architectures scenarios (BizTalk Server, API Management, Logic Apps, Service Bus, Event Hub…), solutions diagrams and features or systems that use Microsoft Azure and related cloud and on-premises technologies in Visio 2016/2013:

  • BizTalk Server
  • Microsoft Azure
    • Integration
      • Integration Service Environments (ISE)
      • Logic Apps and Azure App Service in general (API Apps, Web Apps, and Mobile Apps)
      • Azure API Management
      • Messaging: Event Hubs, Event Grid, Service Bus, …
    • Azure IoT and Docker
    • AI, Machine Learning, Stream Analytics, Data Factory, Data Pipelines
    • SQL Server, DocumentDB, CosmosDB, MySQL, …
    • and so on
  • Microsoft Power Platform
    • Microsoft Flow
    • PowerApps
    • Power BI
  • Office365, SharePoint,…
  • DevOps and PowerShell
  • Security and Governance
  • And much more…
  • … and now non-related Microsoft technologies like:
    • SAP Stencils
Microsoft Integration (Azure and much more) Stencils Pack

The Microsoft Integration Stencils Pack is composed of 29 files:

  • Microsoft Integration Stencils
  • MIS Additional or Support Stencils
  • MIS AI and Machine Learning Stencils
  • MIS Apps and Systems Logo Stencils  
  • MIS Azure Additional or Support Stencils
  • MIS Azure Integration Services
  • MIS Azure Mono Color
  • MIS Azure Old Versions
  • MIS Azure Others Stencils
  • MIS Azure Stencils
  • MIS Buildings Stencils
  • MIS Databases and Analytics Stencils
  • MIS Deprecated Stencils
  • MIS Developer Stencils
  • MIS Devices Stencils
  • MIS Files Stencils
  • MIS Generic Stencils
  • MIS Infrastructure Stencils
  • MIS Integration Fun
  • MIS Integration Patterns Stencils
  • MIS IoT Devices Stencils
  • MIS Microsoft Fabric
  • MIS Office365
  • MIS Power BI Stencils
  • MIS PowerApps and Flows Stencils
  • MIS SAP Stencils
  • MIS Security and Governance
  • MIS Servers (HEX) Stencils
  • MIS Users and Roles Stencils

You can use and resize without losing quality.

Download

You can download Microsoft Integration, Azure, BAPI, Office 365, and much more Stencils Pack for Visio from GitHub here:

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

Join me at BizTalk to Azure -The Migration Journey event | September 28, 2023 | Gothenburg, Sweden

Join me at BizTalk to Azure -The Migration Journey event | September 28, 2023 | Gothenburg, Sweden

I’m thrilled to be back doing a presential event after INTEGRATE 2023! And I’m excited to return to Gothenburg and Sweden after seven years! It has been so long! The last time I was in Sweden was in 2016 when I presented at BizTalk User Group Sweden in Stockholm and Gothenburg.

This time, I was invited by Contica to present at their event: BizTalk to Azure -The Migration Journey. In fact, my presence should have happened last year, but for personal reasons, I had to cancel my trip. But I promised that I would come back, and here it is! And to make up for it, in double dose! I will be delivering not one but two talks:

  • 1: Elevating Integration – The Roadmap from BizTalk Server: If you are embracing the journey to move your current BizTalk Server environment to the cloud, in this session, we’ll guide you through the steps, strategies, and best practices needed to successfully transition your integration solutions to the cloud. What phases in your migration journey are crucial? Which tools and technologies should you use? After this session, you’ll know about the dos and don’ts, as well as the key considerations that will empower the agility and scalability of Azure Integration Services. Join us to unlock the potential of Azure’s cloud-native services and streamline your integration landscape.
  • 2: Azure Integration in Action – BizTalk to Azure Transition Case Studies: Join us for an engaging session where we bring Azure Integration Services to life through simple real-world case samples. Through these exercises, you’ll gain practical insights, strategies, and tips to ensure a smooth BizTalk Server migration while embracing Azure’s agility, scalability, and cost-efficiency. Take advantage of this opportunity to see Azure Integration Services in action, guiding your path toward a seamless and future-ready integration landscape.

The event will take place on September 28, 2023, between 5 PM – 9 PM (local time) at Contica, floor 9
Masthamnsgatan 1, Göteborg, Sweden.

Simon Stender will join me at this event to deliver a session about Design and Infrastructure in Azure: Shaping Robust Infrastructure.

Link for the registration

See more about the event and sign up now to secure your seat at the event page: https://www.eventcreate.com/e/themigrationjourney

The event is free! See you there!

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