Integration Account

In this page we will look at the Azure Logic Apps Integration account and how its use will affect the cost of your solution.

In practice an integration account is a relatively expensive resource, it will cost approximately $300 - $1000 per month.

Factors that affect cost

• Do you need EDI Trading partners?

• How many maps & schemas do you need?

• How many instances of an integration account do you need?

Things to Think about

Do you really need an integration account?

The first important question is if you actually need an integration account or not?  In my opinion if you are building an EDI solution and need to manage EDI trading partner settings then the integration account is required but if you are only doing mapping and schema validation then there are other ways you can do this now which are much more cost effective.

Environment Considerations

While an individual integration account may not seem overly expensive, in the real world, sometimes customers dont think through their environment planning from a cost perspective and miss an opportunity.  While a single integration account might not be so bad, its likely you may need to have multiple integration accounts for different environments such as Dev/Test/Prod.

Can you use Logic App Standard Inline Maps

The benefit of an integration account is that you can have a central hub for maps and schemas.  This is particularly useful if you need to do validation and transformation for data in multiple interfaces.  

In Logic App Consumption and ISE (now deprecated), if you wanted to execute a Liquid Transform, XSLT or a number of other schema or transform functions you had to use the integration account.  When Logic Apps Standard was introduced there was now the option to host maps and schemas as part of the solution and execute them inline.  This would remove the need for the external call to the integration account to execute the map or schema.  

If you are using Logic App Standard then it is much more feasible to build your platform without an integration account.  While you do trade off that you dont have the central hub of schemas and maps, you can workaround that problem with Azure DevOps or Github and have a central schema/map repo which you can deploy into your apps.

Common Optimizations

Sharing an Integration Account across environments

One of the common cost savings if you need an integration account is to share a single integration account across multiple environments to reduce cost.  If you are just using schemas and maps then you may be able to inject a naming convention on your map or schema so you can correctly resolve the appropriate resource.

If you are using EDI then I think there may be other problems in using this approach for party resolution and you might not be able to do this if you want to evolve a good approach for change management across environments.

Logic App Standard Inline Maps

If you are just doing maps and schemas then you should definitely consider if you can use inline maps and schemas.  You can even consider moving some Logic App Consumption to Standard if you want to reduce costs by removing the integration account.

Using a Function

One of the options if you do want to have a centralized maps/schema hub could be to build your own.  Sandro wrote a good blog post about this where you can write an Azure Function which executes a map or schema which is loaded from a storage account.  Your Logic Apps just execute the function and pass in the input data and get back the response.  In reality this is pretty much how the integration account works under the hood.

In the below diagram you can see how the Logic Apps could execute the function.  The xsl file for the transform was loaded from the storage account where it is deployed to by your DevOps process.

In this pattern you are building a mapping API and then using it from Logic Apps.

Remove Resources during long periods where it is not used

If you have an integration account where your team goes long periods without using it then one option you could look at would be to delete the resource and recreate it on demand.

In this scenario, let's imagine you have a 3-month window where you will not be doing any development or testing on your integration platform.  In this case you could use a DevOps pipeline to delete the integration account in your Dev & Test environment.  When you have a new project that comes along that needs to use interfaces that use the integration account, then you could use your DevOps process to spin up the integration account again and deploy all of the resources to it.

How can Turbo360 help

Azure does not really offer any ways that you can optimize an Integration Account.  Even swapping it between sizes would not work well in many cases because of the differences in thresholds for schema/partners etc would probably cause a resize to fail.

The main areas that Turbo360 would help you here would be for transparency and monitoring of your costs for the integration account.  Customers using Turbo360 usually have a tree node for the costs for their integration teams Azure resources.  As a child of this they might create a node for keeping an eye on Integration Account costs.  You can see below what this might look like.

From here you could setup monitoring of the cost.  While the costs would tend to be very static for the integration account, this will help to make it easy to see how much your spending on integration accounts within your platform.

Useful Resources

• Azure Integration Account Cost Savings