Enterprise Integration in Azure offers Integration Accounts that can be associated with Logic Apps and supports maps via xslt of liqid templates.
The pricing options of Integration accounts is not that friendly yet as there is a running cost per hour irrespective of the usage.
This will however be changing soon with usage billing as announced by Microsoft in Integrate 2018 event in london. This is a great move towards this feature.
The region dependency of Logic Apps and Integration Account is still there and will continue to be there.
Checkout the backlog for product features in plan. Its great.
Using Azure functions to run maps is a good viable options from pricing perspective till per usage price of Integration Account comes. Or to be independent of the region or to have a reusable component across many other Azure services or any other cloud/on-premise application.
You can have a HTTP triggered function that accepts your input, runs xslt and returns back the transformed data.
The XSLT can be uploaded to your function from the Azure portal easily.
Hope this helps.
Its still not very staright forward to set upgraded TLS for BizTalk 2013R2 and below for outgoing sevice requests.
A Wcf behaviour can be very simple and elegant way to handle that without disturbing the system settings, application settings or the registry settings.
The behaviour is simply about setting SecurityProtocol to a higher TLS version for outgoing messages.(As .Net already supports it)
Below code helps you get the same.
A SecurityBindingManager.cs that holds the property of the behaviour
SecurityBindingBehavior.cs that is setting the SecurityProtol for you.
And extension .config that you can import under BizTalk admin console adapter configuration. There is no need to add this in machine configs or application configs in you BizTalk server farm.
And when you try to add the extension you can set the property as below so that you are covered for all as the handshake takes care to use the correct TLS as is supported by the end point.
Hope this helps.
Flat file dissassemblers in BizTalk exposes the document schema property differently than XmlDissassmbler.
Flat file dissassmblers do not allow for multiple schema selections. You can only select 1 flat file schema.
The next option to go for is to use multiple flat file dissassemblers as you can have 0-255 components and it works with first match execution. However in practise this does not work like this and the given input only tries to match the first configured schema and hence can’t be used in scenarios where you want to have multiple schemas.
The second way is to separate out your receive locations and use separate pipelines but this can be an issue if the sending system generates the files for you as a single process and would like to send different files at the same locaion for the middlerware to handle.
To solve this need, the SDK comes with a SchemaResolver component that works on reading the content [First few characters] and determining what schema to use.
For a similar scenario, I wanted to have this based on the received file name.
We can read the file name and use the specified messagetype for schema resolving.
The DocumentSpec is retrieved use the messgaetype and written to context for dissassmbler to probe the related schema.
This is a very handly solution to have single receive for multiple flat files.
BizTalk 2013 R2 has CU5 up for grab 🙂
Quite a few important fixes.
One of the fixes that we reported/found was around the WSS adapter and it has been fixed here.
Get a copy and try out the fixes.
One of the major news in BizTalk Server 2016 is the full support for SQL AlwaysOn Availability Groups (AGs). When Microsoft announced this, the crowd cheered, and they moved on to the next slide. There are, however, some bits you should be aware of before deciding on your High Availability (HA) architecture for BizTalk.
SQL Server 2016 is the first (and only) edition to support AlwaysOn for BizTalk Server 2016. The reason is lack of support for MSDTC between BizTalk’s SQL Server databases and other transactional resources. For this reason, High Availability for the database layer in BizTalk scenarios has traditionally been solved by using Windows Server Failover Clusters (WSFC), typically with an active-passive configuration.
First of all, you need to run BizTalk Server 2016 Enterprise, SQL Server 2016 Enterprise, and Windows Server 2016 (or 2012 R2 with KB3090973).
As you may be aware of…
View original post 450 more words
For couple of weeks I am trying to have support for BTDF built msi’s deployment across servers using BADT.
I have a beta version for this feature implemented in V2.1 of the BADT. The latest tool can be downloaded from codeplex.
The UI looks as below where one can select the : (Beta) Deploy BTDF msi on farm.
Once the msi is loaded the tool populates the required actions and some configuration details.
The configuration tab has the list of Install Wizard configurations from BTDF and you can enter these details at one place and those will be used across all the servers in the environment. No need to enter same details again and again across servers.
Environment is populated from the SettingsFileGenerator.xml bundled within msi.
I have tested the tool with Sample Applications that are with BTDF (Helloworld and Advanced).
With limited use on BTDF, I am not sure if more actions are needed here and I don’t have more cases to test the tool too. I would request the community to try the feature and suggest issues/ideas to make this robust.
One of the few discussions and wishes around BizTalk application deployment has been around tackling dependent application deployment.
Consider a simple dependency scenario –>
Application A–>Dependent on Application B
Application B–>Dependent on Application C
If I want to deploy any changes to application A, I need to cleanup B and C ..then deploy A and re deploy application C and B in that order.
This is very scary scenario and poses a lot of challenges. Such situations should be avoided at the very first place while designing the solutions but nonetheless BADT would come with dependency resolver that should take care of organizing the deployment activities for you.
I created a vague not so frequent occurring dependency projects.
Now if there is any change in MyApplication.ApplicationA I need to resolve all the applications interdependent on each other to make sure the environment is up again after deployment of MyApplication.ApplicationA
The tool now comes with a tab page related to Dependent Applications and options to resolve the dependency from there.
You can right click on the application node and select the Msi for this. This Msi would be the package that will be used during deployment process to re-deploy dependent applications after resolving.
Once all the dependent application’s Msis are selected, the actions can be loaded. The load action resolves the dependency order and lists the actions in required order for deployment.
At this point you will notice that the order of deployment/ redeployment is resolved and listed. Select the actions and Run the tool.
Recommendations and ideas are most welcome. Type in your comments on how you see the feature and also the user interface/interaction shown above.