Yes, it’s been a while. A long while… I was recently required to import a simple XML file into a set of records in an Oracle table. This sort of integration is pretty simple using BizTalk Orchestrations, but we’re trying to move to an ESB-centric model. I struggled finding an easy-to-follow guide, so am […]
Blog Post by: Brett
As most know a BizTalk Solution has two major parts – its resources in form of dlls, and its configuration in form of bindings.
In an previous post
I described how to build and pack resources into an MSI using Team Foundation Server (TFS) Build Services. Managing the configuration in a similar way is equally important.
So let’s see how we can build environment specific binding files using TFS Build Services and some config transformations syntax goodness!
Let’s start with a simple example of a simple binding with a receive port, receive location and a
send port for two different environments – one called “Test” and one “Production”.
| Port type | Name | Destination path in Test | Destination path in Production |
|---|---|---|---|
| Receive Port | BtsSample_ReceivePort_A | N/A | N/A |
| Receive Location | BtsSample_ReceivePort_A_Location (File) | C:TempIn*.xml | C:TempIn*.xml |
| Send Port | BtsSample_SendPort_A (File) | C:TempTESTOut%MessageID%.xml | C:TempPRODOut%MessageID%.xml |
As one can see there’s a small difference between the send ports destinations paths in Test and Production.
Next we’ll create a binding template. The binding template will hold all information that is shared between the different environments.
This is achieved this by an ordinary export of the application binding from the BizTalk Administration Console – as you’ve probably done many times before.
The Web.config Transformation Syntax is feature that showed up in Visual Studio 2010 and
is often used to transform app.config and web.config files between different versions and environments – but it will of course work on any type
of configuration file. Including BizTalk binding files!
So for each environment we’ll then create an environment specific config file that only contains the values that differs between the template and
the values for that environment. We use the Web.config Transformation Syntax to match the nodes and values that we like to update in the template.
Below is the Test environment specific file matching the send port and replacing the value with the value specific for Test.
The Production specific file also matches the send port but with a different value for the Destination path.
As part of the Visual Studio installation an MSBuild target is installed for executing the transform.
The target is installed into the standard MSBuild Extensions Path
which usally mean something lilke C:Program Files (x86)MSBuildMicrosoftVisualStudiov10.0WebMicrosoft.Web.Publishing.targets
depending a Visual Studio version etc.
Finally we’ll add a small .proj file to pass some parameters to the MSBuild process. We need to tell the process what file to use as
template and what different environment specific files we like to use.
Next we can kick of MSBuild and point it to the cretated proj file. C:WindowsMicrosoft.NETFrameworkv4.0.30319MSBuild build.proj.
Voila! MSBuild has performed our transformation and created two complete environment specific binding file by combining the template with the specific environment files – one of test and one for production.
Start by setting up a TFS build definition as described in previous post on
Generating BizTalk MSI using TFS Build Services.
We then need to add the $(DestinationPath) property to our Destination path to make sure the outputted binding files are written to the same
path as the rest of the resources.
Once we have our build template all that’s needed is to add the build.proj file to the files to compile as shown below.
When finally running the build our two complete binding files are written to the deployment area and ready for installation!
I am excited to be attending and presenting at the 2015 London BizTalk Summit on April 12th and 13th.
Last year I talked about Microsoft Azure Infrastructure as a Service (IaaS) and walked through creating BizTalk environments on the fly using PowerShell. This year I am going back to the basics of core integration and talking about my 14 years of integration experience. I have been focused on integration with BizTalk Server since Tuesday February 27th, 2001. How do I remember that exact date? Simple – I was up in Seattle and just started a new project. The day after the project started Seattle had a 6.8 Earthquake!
My session details are below.
Title: Top 14 Integration Challenges I’ve seen in the Past 14 Years
Abstract: I’ve been working with BizTalk Server and Integration using Microsoft products since Tuesday February 27th, 2001. Since then I have worked on over 21 different client projects all over the world. Clients range in size from small companies to large Fortune 500 powerhouses. This session will take a look at the top 14 client challenges I have run into in the past 14 years of working in the field and how to address them.
If you have not registered yet, tomorrow is the last day to receive a discount on the registration price.
Register now: http://www.biztalk360.com/Events/BizTalk-Summit-2015-London/
Hope to see you in London in two weeks!
Microsoft just released the 1.0 version of their Node.js Tools for Visual Studio. This gives Windows developers a pretty great environment for building clean, feature rich Node.js applications. It’s easy to take an application built in Visual Studio and deploy… Read More ›
Blog Post by: Richard Seroter
One of the questions I saw on Twitter after yesterday’s Azure App Service launch was: how do you do an if-then-else in a Logic App? Or even a For loop?
If you’re coming from a BizTalk Orchestration or Windows Workflow background, you may be surprised by the lack of shapes in a Logic App for performing these operations.
However, you can still do all those things: you just need to look at the problem differently…
Blog Post by: Daniel Probert
If you have been keeping up with cloud based platforms, I am sure that you have realized it has become a very competitive landscape. Some cloud platforms focus on websites ,infrastructure, and database platforms, while others focus on integration or API management. We even have Mobile backend as a service platforms that we can choose from. While organizations can choose to cherry pick from each of these different platforms, they can also get first class capabilities, that encompasses all of these domains, from Microsoft’s Azure platform.
At the Integrate 2014 conference in December, 2014 Microsoft gave us a preview of its next generation ’App’ platform. At the time, the term Microservice was being used to describe the “architecture style” of the applications that can be built using this new platform. While the Microservice name did not make its way into the product, the concepts that were discussed at that event have not changed. The day has finally arrived when this Next Generation has emerged in the form of a Preview Service. The name of this service is called Azure App Service.
For Microsoft this is a PLATFORM PLAY. No longer do we see disparate product lines in the areas of Integration, API Management, Web Development, Mobility and Workflow. In addition to these characteristics, we also have the rest of Azure that we can leverage including Service Bus, Analytic Engines(both Microsoft and 3rd party), Databases and Infrastructure. When you think of all of these different capabilities, using a common platform, common authentication schemes, common tooling, common billing and a global reach for providing these services, Azure is more than just compelling.
Using the Azure App Service we can now create the following types of Apps:
What are some use cases of an API App?
An example of an API app may be a SalesForce connector. Consider a scenario where you have a mobile application that requires data from SalesForce. There may be good reasons to place this request on a messaging bus (and don’t worry you still can!) but there may also be good reasons to plug into a connector directly. Consider a low latency situation where you want to by-pass a monolithic ESB in favor of something lighter. You could use an API Client library that allows you to consume this SalesForce connector without having a complicated auth scenario. If you have ever looked at a Mobile Service client, you will feel very comfortable working with API App Client. When I saw an insider’s demo of this functionality, I was really happy to see the similarities to a paradigm that I am used to.
Similarly, what if you have built an ASP.Net Web API and you want to consume it from a Web Application. While it can be fun constructing a json message using a String Builder (not really), wouldn’t it be nice to leverage a strongly typed API Client instead? Yes it would! So once again much like Azure Mobile Services client we can use something similar in the form of an API App Client.
Another aspect of API apps is that Swagger is a first class citizen of Azure App Service. We have the ability to generate contracts between the client and API Server which aids in having strongly typed client libraries.
A point worth making is that when building or consuming API apps you are in Visual Studio and there is an accompanying Visual Studio SDK to leverage in order to build or call these API Apps.
Another interesting aspect of this platform is the Cross Platform capabilities. You can choose to build your APIs in the language of your choice (Java, PHP, Node.js, Python + .Net) and expose them as an HTTP endpoint which you can then consume from other applications.
What are some use cases of a Logic App?
A Logic App is really a workflow application. Personally, I am not a big fan of Logic App name but it is preview so maybe it will change. One of the first questions that comes to mind is this workflow based upon Windows Workflow and the answer is no. Perhaps this is why Microsoft stayed away from using “Workflow App”.
What is interesting about a Logic App is that this is a Workflow that you would construct in a Web Browser without writing code. While some people have made some references to IFTTT (If This Then That), Microsoft feels that this is a much more robust, Enterprise grade, platform.
Below is a screenshot of a “work in progress” Logic App. In this example we can retrieve records from SQL Server, create contacts in Salesforce and then send a welcome tweet all without writing a line of code.
In order to add a connector we simply drag and drop it onto our Logic App canvas and then configure it.
A question you may be asking is well if I am composing a workflow in the cloud, how can I add some version control around this? Behind the scenes, the Logic App Workflow itself is based upon JSON and we have the ability to save/export this JSON data and subsequently store in TFS/GIT etc.
So where does BizTalk(Integration) fit into this platform?
The BizTalk brand continues to exist both on-premise in its BizTalk Server sku but also in the form of an API App or what is being called a BizTalk API App. Since building integration applications requires more than just connectivity we can expect to still perform valuable functions such as:
We can drag these BizTalk API Apps onto our Logic App Canvas much like any other connector. I have highlighted a few of them.
It is important to remember that this is a Platform play. BizTalk, within Azure, now participates in the broader platform. You can think of the platform as a series of building blocks. As a developer you now have the ability to select the different building blocks that you need in order to build a compelling solution. As an example of the breadth of this platform, you do not see Workflow currently listed in the BizTalk section, but that doesn’t mean that the capability doesn’t exist. This is a capability that is part of Logic Apps. As a BizTalk person we need to start thinking more about Azure and that is a good thing due to the vast amount of capabilities that exist. Let’s be honest, in the past BizTalk seemed to be a distant cousin of Azure, but it clearly has a place at the family table in this new paradigm.
This is good news for developers. In the past BizTalk has been accused of being too bulky of a platform with too much ’lift’ required for developers to be productive. With this new platform Microsoft is democratizing integration and bringing the toolset that BizTalk Developers are used to using to a broader audience. This will enable more use cases that involve BizTalk and as a result we will see more integrated Web and Mobile applications leveraging BizTalk capabilities.
In addition to these core BizTalk API capabilities we will also see Connectors in the form of SaaS Connectors, Premium Connectors and Protocol Connectors.
SaaS Connectors
We will also see Premium Connectors in the form of:
and Protocol Connectors in the form of:
Conclusion
I have heard many people refer to this release as the “Back to BizTalk 2004” release. What I mean by this is that back in 2004, Microsoft released BizTalk which at the time was the most modern Integration platform available. While we are still in preview and there is a lot to learn, there are a lot of expectations about this release. The current version of BizTalk is extremely robust, but it could benefit by having some very modern capabilities and being able to efficiently run in the cloud. What we are seeing today are the initial steps of BizTalk once again becoming the most modern Integration platform available.
One particular pattern that I am going to be interested in exploring is the hybrid connectivity scenarios that exist. As you may have noticed above, we do have an Azure Service Bus Connector. We also have an Azure Service Bus Adapter in BizTalk Server. So suppose you have an async messaging requirement that involves on-premises systems but you want to tap into one of these cloud based systems. Well now you can leverage the Service Bus to ’bridge’ your on-prem envionment with the Azure App Platform Service where we can then leverage one of these fancy new SaaS connectors to talk to SaaS system like Box, Marketo, Dropbox etc without having to do any custom work in BizTalk Server. It allows you to take advantage of robust on-premise messaging while tapping into modern, SaaS base connectivity and allows you to migrate these workflows to the cloud at a cadence that you are comfortable with and that make business sense.
It is also worth mentioning that I am just scratching the surface on these new capabilities and we are still in Preview mode. I think being a Microsoft platform developer is going to get even more exciting than it already is. I think developers will be able to build some compelling, mobile, connected apps using a vast array of building blocks.
Expect much more to come on this blog regarding this release.
Today’s announcement from Scott Guthrie not only brought with it a re-imagined Microsoft Azure platform, but also finally gave BizTalk Server a pure PaaS home right in the center of the stack. To be fair, we’ve had clues that this … Continue reading →
The post Azure App Service: BizTalk Server PaaS Done Right appeared first on QuickLearn Blog.
Blog Post by: Nick Hauenstein
Azure App Service allows developers to create business logic in the cloud that supports their new or existing web and mobile apps.
Building on the MicroServices announcement from last year’s BizTalk Summit (in Redmond), there have been two major new technologies released…
Blog Post by: Daniel Probert
So I finally did what I should have done years ago: I got my own domain and host my own blog on Azure.
You can find it at mikaelsand.se or mikaelsand.com
Blog Post by: Mikael Sand
Last September, I did a series of presentations on “The Future of Integration” and highlighted the popularity of containers and the growing momentum around microservices. Since then, interest in microservices has exploded within the technology industry and containers are seen… Read More ›
Blog Post by: Richard Seroter