In 2024, I have challenged my team to publish an Enterprise Integration fact every Friday. A fact about the technologies we work on every day: Azure Integration Services and/or BizTalk Server. I can proudly say that we, my team, and I did it! We have delivered an astounding amount of 52 Friday Facts in 2024!
Here is the list of all the facts:
- Integration Account doesn’t support XML Nested Schemas for Schema Validation. If you need to perform an XML Schema validation using the Integration Account, please remember that the Integration Account doesn’t support nested schemas.
- Settings present on the local.settings.json file inside the Azure Functions project are not deployed with Visual Studio. The local.settings.json file doesn’t get deployed directly with Visual Studio (manual deployment) in a way that carries along your connection strings and other critical information.
- Is the BizTalk Server dead? Hell, no! We already live in a world of too much fake news! Let’s try to avoid a new “old” one. While there has been a shift towards cloud-based integration solutions, such as Azure Logic Apps and Azure Service Bus, BizTalk Server continues to be actively used and maintained by organizations worldwide.
- Trigger conditions can help you optimize Workflows and conserve resources. Implementing trigger conditions isn’t just about adding complexity to your Logic Apps; it’s about bringing precision and efficiency to your workflows. By defining specific criteria, you gain control over when your Logic App should execute, avoiding unnecessary runs and conserving resources.
- Implementing error handling in essential business processes is vital. Logic App is not an exception. In Logic App development, implementing try-catch scopes is more than just a best practice. It’s a powerful strategy for building a reliable and user-friendly workflow that elevates the Logic Apps’ robustness, fault tolerance, and overall performance.
- XML to JSON Conversion in API Management and Logic Apps have different behaviors. 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 that is not equivalent to what’s happening inside Logic Apps.
- Parallel branching in Logic Apps enables asynchronous execution of multiple tasks simultaneously. When tasks are executed in parallel branches, they do not wait for each other to complete before proceeding. Instead, they run concurrently, allowing for asynchronous execution. This means that while one branch processes a task, another can simultaneously execute a different task.
- When a HTTP Request is Received trigger can accept more HTTP methods other than POST. Diving into Logic Apps, it’s a common oversight to assume that only POST requests can be used when using the “When an HTTP request is received” trigger. However, the beauty of this feature is its support for the full spectrum of HTTP methods, nudging us towards adopting REST API best practices in our Logic Apps designs. Remember, your Logic App’s action should align with the HTTP request method you opt for—whether that’s GET to fetch data, POST to add new info, PUT or PATCH to update existing data or DELETE to remove it.
- Logic Apps don’t interpret escaped characters as plain text, even inside a string. In the realm of Logic Apps, the treatment of escaped characters differs from handling plain text. You must be very careful while trying to escape special characters inside Logic Apps workflows.
- There is no size limit for the Logic App parameter name. Logic App parameter name is unlimited! To be honest, I think this is crazy, but that is the reality.
- Existing Logic Apps with Service Bus triggers using peek lock cannot be changed from topic to queue or vice versa. Peek Locks play a vital role in ensuring message reliability and processing integrity. However, you must be aware of limitations when attempting to deploy Logic Apps (at least Consumption) that Service Bus triggers with a peek lock. Once you deploy it, you cannot modify that trigger.
- Azure Logic Apps supports both Dot and Bracket notations. It is a fact. It is a reality. Azure Logic Apps offers a flexible and first-class experience in accessing data within JSON structures, and users can use Dot and Bracket notations to accomplish that task. While both notations are valid and can be used interchangeably in many cases, bracket notation has the upper hand when it comes to accessing properties with dynamic names or names that include special characters, which dot notation can’t handle.
- Workflow and Trigger expressions can help monitor your Logic Apps. Indeed, simplicity often proves to be the most effective approach. This holds true, particularly in the context of using the workflow expression alongside the trigger expression. These expressions facilitate the monitoring of your Logic Apps, providing crucial details such as the name of the failed Logic App, its corresponding run identifier, and the timestamp of the occurrence.
- It is possible to create a first-class XML experience inside Logic Apps. By default, Logic Apps provides a good first-class experience for JSON, which means when we receive a JSON message, we can tokenize the elements by using a JSON schema inside, for example, a Parse JSON action. Unfortunately, many people complain that we don’t have the same capabilities for XML messages. And that’s true. By default, XML messages don’t have this first-class experience to access the fields since the message, but that doesn’t mean we cannot have that experience, either!
- Response Connector does not perform a Schema validation at runtime: Workaround! Contrast with the trigger When a HTTP request is received that can perform a schema validation while the Logic App executes, the Response action unfortunately does not do the same.
- Logic Apps decode all sorts of Base64 files, but sometimes, not how you expect! When you need to decode a Base64 file, you can rely on Logic Apps to do it; in concrete, you can lean on an expression to help you achieve that. But sometimes it doesn’t work as expected.
- Logic App Consumption and Standard name have different size limits and restrictions. Depending on the Logic App type you are using, Logic App Standard or Logic App Consumption, you will notice that each has different name size limits.
- Parse JSON action input parameter (Content) supports the use of functions. When working with Logic Apps, it’s often necessary to employ conversion functions in the form of expressions. For example, you might need to convert XML to JSON and then parse that JSON.
- Logic App Consumption and Standard have different Action name restrictions. One thing that Logic App Standard or Logic App Consumption have in common is the action name size limit! No matter which type you use action names must have one character and be fewer than or equal to 80 characters.
- Removing API Management Name Values sometimes causes conflicts. When managing APIs, name values (often called key-value pairs) are used for various configurations, such as setting API keys, configuring endpoints, or defining parameters. Sometimes, these name values become obsolete and must be removed to maintain a clean and efficient system. However, you might encounter an error preventing the removal of these unused name values, especially when they are linked to existing backend configurations.
- Visual Studio 2019 successfully deployed Logic App Consumption with invalid JSON payloads inside Compose actions. If we are constructing a JSON payload inside a Compose action, notice that the Compose action inside Visual Studio sometimes doesn’t validate if the JSON payload is valid or not!
- You can implement advanced routing scenarios by using conditional split actions inside Logic Apps. In Azure Integration Services, you can implement routing scenarios in many different ways. Each approach has advantages and disadvantages. The most common way to accomplish that is by using Azure Service Bus, but there are other ways. For example, in Azure Logic Apps, you can implement advanced routing scenarios by using conditional split actions combined with custom expressions.
- Consistency in Logic App Trigger names ensures successful resubmissions. If you change the Trigger name inside a Logic App, you may get an error while trying to reprocess old runs. You can change your entire Logic App design; as long as you keep the trigger name intact, you can resubmit an old run without encountering any issues.
- Managing rate-limiting errors is crucial for maintaining the reliability of your applications. One common challenge when working with external APIs is rate limiting. This occurs when the API imposes a limit on the number of requests that can be made within a specific time frame. Exceeding these limits can lead to errors and disruptions in your application.
- New Logic App Designer (in GA) Enables Copy and Paste actions. When working with Logic Apps Consumption, you can choose between the Legacy Designer and the Generally Available Designer, aka the new Logic App Designer. The Generally Available Designer offers some great features, such as the ability to copy and paste actions, which the Legacy Designer lacks.
- Migrating BizTalk Server to Azure Integration Services will be expensive… but cheaper than other competitor. Azure Integration Service is the simple and most cost-effective path to migrating a BizTalk Server environment. However, if you take into consideration the total cost of ownership when moving from BizTalk to AIS, you will realize that migrating any solution from BizTalk to any other platform will not be cheap.
- You can expose a Function on API Management directly from your Function App. This is a cool new Azure Portal feature. You can easily expose a Function as an API directly through your Function App!
- You can debatch XML messages with Logic Apps. You can debatch XML content in Logic Apps similarly to how you handle JSON inputs. This guide will walk you through the process using a sample XML structure.
- You Can Protect Your Logic Apps from accidental changes with Read-Only locks. Did you know you can make your Logic Apps read-only, preventing unintentional modifications or deletions, by using locks?
- Starting September 2024, the legacy Logic App designer will retire and become unavailable. It is nothing new. You may see this every day on the Azure Portal. However, it’s still important to mention because it’s a fact: Logic App designer will be retired and become unavailable starting September 2024!
- Logic App Connectors outlast HTTP Connectors in default Retry Policies Timeouts. An interesting fact about default retry policies on logic app connectors is the fact that these default retry policies vary depending on the connector, for example on HTTP connectors, if we use them to send a request to a service, in this example, a Logic App, and if that service suffers a Delay, the connection is established for approximately 11 to 12 minutes, where 4 retries are made before abandoning the request, and fail.
- The New Logic App Designer (GA) doesn’t allow direct access to Code View. One key consideration with the new Logic App Designer is that it no longer allows direct access to the Code View, which limits flexibility. In the Legacy Designer, you can easily access and edit the code by clicking the Code View icon. Once you’ve made your changes, you can switch back to the visual designer, verify the updates, and save your progress when you’re confident everything is working as expected.
- Two AI Assistants are now available on Azure: Copilot and Workflow Assistant. We’ve previously shared the exciting news about Copilot’s arrival on Azure, signaling a bright future for AI-powered integration work. Copilot is a versatile tool available across Azure, allowing you to get answers to your questions through a convenient chat interface, no matter where you are on the platform. But did you know that Logic App Standard takes this a step further? It features a dedicated AI chat, the Workflow Assistant, designed specifically for the workflows you’re working on.
- Logic App Standard Workflows can be configured to run in both stateful and stateless modes. Unlike Logic App Consumption, which is stateful by default, Logic App Standard Workflows can be configured to run in both stateful and stateless modes. These workflows cater to different use cases depending on whether you need to maintain state and history or optimize for speed and reduced resource usage.
- Azure Service Bus naming size limits and restrictions. Azure Service Bus has various naming size limits and restrictions that developers need to consider when creating queues, topics, subscriptions, and other entities.
- Now you can pin actions on the Globally Available (GA) Designer! Another cool feature related to the Globally Available (GA) Designer is the ability to pin actions, allowing you to keep a specific action of your choice easily accessible on the screen. This straightforward yet practical feature helps developers pin a specific selected action without needing to scroll or search through more complex workflows.
- You can unlock Consumption connectors in Logic App Standard for Visual Studio Code. Did you know that you can access the consumption connectors in Visual Studio Code? In the Azure Portal, when designing a Logic App Standard, you get access to both in-app and consumption connectors. However, in Visual Studio Code, only in-app connectors are available by default. This is because in-app connectors offer better isolation and performance since they run within the same environment as your Logic App instance, minimizing network latency and improving control. But you can change this behavior!
- You can use the BizTalk Server Logic App adapter to call a Logic App Standard Workflow. BizTalk Server 2016 and 2020 are empowered with multiple mechanisms/functionalities to build hybrid integrations. One of those functionalities is the BizTalk Server Logic App adapter, which you can use to receive messages from or send to an Azure Logic App.
- Missing Environment Variables can break your Logic App Standard Workflows. Just like in Azure Functions, where environment variables need to be correctly set, the same applies when working with Logic App Standard in Visual Studio Code.
- When a HTTP request is received trigger has different behaviors depending on the designer you use. While creating a Logic App Consumption with When a HTTP request is received trigger, this trigger will have different behaviors with regards to the HTTP URL generated when we save the Logic App depending on if you are using the Legacy Design or the Generally Available Designer. And that will directly impact the BizTalk Logic App Adapter in BizTalk Server.
- You can now send a 100 MB message to a Service Bus Queue or Topic. Until recently, the maximum limit of a message that we could send to a Queue or Topic on a Service Bus was 1MB, and we had to use the Service Bus premium tier. Now, we can send a message up to a maximum of 100MB on the same premium tier.
- Logic App GA designer now offers a seamless transition from designer view to Code View and vice versa. Good news for Logic Apps developers! Remember when the new Logic App Designer’s GA version didn’t allow you to directly jump to the code view?
- VS Code does not allow Logic Apps Standard incremental Workflow deployment. When working with Logic Apps Standard in Visual Studio Code, it’s important to note that deploying a workflow from one project can overwrite existing workflows in a Logic App. For instance, if you have Project A with a workflow already deployed on the Azure Portal, and then you deploy a workflow from Project B to the same Logic App, the workflow from Project A will be replaced by that from Project B—and not incremented!
- I’m a BizTalk developer planning to learn Azure Integration Services. Which tools should I use? It doesn’t matter if you are a BizTalk developer or an Azure Integration Services developer; that means you are an Enterprise Integration developer, which is a fact! In my personal opinion, you will be a better Enterprise Integration developer if you know both of these technologies.
- You can automate Blob Storage with Lifecycle Management Rules for smarter Data Handling. Did you know Azure’s Lifecycle Management can streamline how you manage data in Blob Storage?
- You can seamlessly switch between Branches with simple Git Commands. When working with repositories in DevOps, managing branches effectively is crucial. If you’re not working in the main branch and have set up other branches for your repository, you’ll likely need to switch between them while working on your cloned repository.
- You can manually fix AzureRM Cmdlet Errors in Logic Apps Deployment by using Az Module Commands. If you’re working with Logic Apps in Visual Studio 2019, you may have encountered an issue when deploying Azure resources using the Deploy-AzureResourceGroup.ps1 script. The reason for that is that this script might be using commands from the now-deprecated AzureRM module, causing errors when running your deployment.
- You need to be logged in to open a workflow in Logic App Standard Designer inside Visual Studio Code. Have you ever faced yourself trying to open the Logic App Standard Workflow inside Visual Studio Code and get stuck in a blank canvas? The designer doesn’t work? In order words, it opens a tab inside Visual Studio code but doesn’t present the trigger and actions that compose the workflow.
- You can resubmit your Logic App using a specific action. If you do not know it already, here is a cool feature available in the globally available designer. You can resubmit your Logic App From a specific action, this can help you in cases where you have large workflows and only need a portion of the Logic App to run again, that can save you time and effort, especially when debugging or testing workflows.
- Visual Studio Code struggles with canceling runs (Here’s the Workaround). Visual Studio Code can be pretty lacking when it comes to features that could save you from a challenging situation, like being able to cancel a massive amount of runs.
- Self-Chained APIM request is possible even if your APIM is configured to use a virtual network. By default, your API Management instance is accessed from the internet at a public endpoint and acts as a gateway to public backends. However, APIM allows you to use an Azure virtual network to secure access to your API Management instance and to backend APIs. Nevertheless, no matter if you use the virtual network or not, you can implement a Self-Chained APIM request.
To lazy to read? We’ve got you covered! Check out our video version of this content!
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!
