How does it work?
Users can also debug their code locally using Visual Studio Code. This is especially beneficial for BizTalk customers transitioning to Azure Integration Services (AIS) while keeping their custom code for integrations. With this feature now in General Availability, it’s an ideal time to explore its potential.
Now, let’s dive into the mechanics of incorporating this feature into your Logic Apps workflows. Two essential steps come into play.
- Firstly, it’s important to implement the WorkflowActionTrigger extension and decorate the method that your Logic App executes with a FunctionName.
- Secondly, you need to ensure that in the buildtasks, the dll’s generated by your build are copied into the lib/custom/net742 folder of your Logic App. This ensures that when deploying your workflows, the associated code is seamlessly deployed as well.
With your code wrapped in this manner, invoking it initiates a .NET process, executing your .NET code, and naturally consuming a portion of your App Plan’s memory and CPU resources in the process. So for me, this actually behaves like an Azure Function inside your App Plan.
BizTalk Pipeline Migration
While employing Custom Code for BizTalk pipeline migration is an obvious use case, its implementation can prove intricate. Not all custom pipeline components can be seamlessly migrated. This complexity is especially apparent in scenarios involving data streaming. A straightforward copy-paste-and-rebuild strategy won’t suffice, considering that custom pipeline components often handle streaming data.
However, the fact that the code is written in C# offers flexibility. It can handle a wide range of data formats, such as JSON and XML, by utilizing serialization. It’s essential to note that complex batching/debatching scenarios are not supported, but Logic Apps’ splitOn functionality can effectively address this requirement.
Mapping Migration
Another valuable use case for Custom Code is data transformation. If your integration involves minor but complex data transformations beyond the capabilities of built-in data transformation actions like Compose and Select, Custom Code can come to the rescue. This is particularly advantageous in JSON-heavy integrations. For XML transformations, you can seamlessly import XSLT mapping files directly into your Logic App, utilizing the Transform XML shape.
Same AppPlan Benefits
Custom Code brings significant advantages:
- Custom code components scale harmoniously with your workflow plan, ensuring that scaling operations occur without delay.
- Authentication concerns become a thing of the past as the function runs within your app plan, functioning seamlessly as a built-in action. This eliminates the need for setting up function keys or Managed Identity, simplifying the deployment process. Of course, as mentioned before, the custom code will use some of your App Plan’s resources, so you should think about that when choosing the right SKU.
Resource Organization
Efficient resource management involves thoughtful grouping. Generic components find no place within your Logic App. Only the workflows explicitly defined in your Logic App can access the custom code you’ve crafted. Generic code is best placed within a separate function in a distinct app plan. While it’s possible to output custom code DLLs inside the lib/custom/net472 folder of other Logic Apps, doing so requires developer discipline and governance.
.NET Version Considerations
Microsoft’s initial focus was around achieving General Availability with .NET 4.7.2, a version suitable for most BizTalk migration scenarios.
However, the good news is that Microsoft is actively working on adding support for .NET 6. How this will work and what this entails is still to be seen, but this will open up new possibilities for migration and potential upgrades during BizTalk migration projects, along with the opportunity to leverage the features of newer .NET versions.
Conclusion
In conclusion, Custom Code in Azure Logic Apps Standard is a valuable addition, particularly when migrating from BizTalk to Azure Integration Services (AIS). It serves as a helpful tool, especially for those smaller helper functions that don’t necessarily warrant a separate app plan.
Looking ahead, as support for higher .NET versions becomes available, I anticipate this feature will become even more indispensable, making it an excellent choice for building new platforms. However, there’s no need to wait for the future – you can start making the most of its capabilities for your integration needs right now.
For more information, check out the product documentation of Microsoft.
Thanks for reading!
Subscribe to our RSS feed