My last article introduced the ChannelAdam SOAP Library to make it as easy as possible to create a SOAP 1.1 or SOAP 1.2 payload.

Also as mentioned in that last article, the .NET library Nancy is an excellent lightweight web framework for building HTTP-based web services. While Nancy will not itself ship support for SOAP it still can be used for hosting SOAP web services, if you can create the SOAP payload - and that is exactly what the ChannelAdam SOAP Library helps you do.

However, even after you use the ChannelAdam SOAP Library to build your SOAP payloads, there are still a few hurdles to jump over in order configure Nancy to work with SOAP HTTP requests… until now!

Announcing the release of the open source ChannelAdam Nancy SOAP Library which provides an adapter that makes it as easy as possible to work with SOAP 1.1 and SOAP 1.2 payloads in Nancy.

For information on how to get started, please see the usage documentation.

Enjoy!

The Simple Object Access Protocol (SOAP) has been around for more than a decade. While HTTP-based API’s and RESTful services are the current trend, SOAP web services are still the rock bed of most businesses and contemporary systems.

On-premises API gateways such as the CA API Gateway has had support for publishing SOAP web services for quite a while.

In fact, there is still such demand in the industry for integration with SOAP services that Microsoft’s newer cloud-based Azure API Management service also now has the capability to publish SOAP API’s.

The .NET library Nancy is an excellent lightweight web framework for building HTTP-based web services. While Nancy will not itself ship support for SOAP it still can be used for hosting SOAP web services, if you can create the SOAP payload.

Libraries such as Nancy or Mock4Net (a tiny mock HTTP server for .NET) can be used in automated Unit Tests to dynamically create mock web services that return the exact response required for each specific test case. In fact, I personally use this specific technique to perform advanced Unit Testing of black-box code artefacts such as BizTalk orchestrations.

However, creating and composing a SOAP envelope, header, and body or fault has always been a tricky undertaking, and unless you have studied the SOAP specifications in detail and use them daily, it is easy to either forget or confuse the differences between SOAP 1.1 and SOAP 1.2 - that is, until now!

Introducing the ChannelAdam SOAP Library – a fluent .NET API to make it as easy as possible to create a SOAP 1.1 or SOAP 1.2 payload.

For information on how to get started, please see the usage documentation.

You might also be interested in the ChannelAdam Nancy SOAP Library which makes using SOAP with Nancy even easier.

Overview

In today’s modern world of software development with continuous integration as a standard industry practice, what do you think would happen if you told a developer that they need to set a special Visual Studio project property in their build configuration in order for their code to “support unit testing”?

They would laugh at you in disbelief! Why does code need to be built in a special way in order to be testable?! This laughing typically would be followed by heart-ache, maybe a little quiet sobbing and an uncontrollable eye twitch as they realise that decade-old standard industry software development practices are crashing down all around them and they start reconsidering their life choices.

Sadly, the only thing that you can do is agree and try to console them by saying it is “just because it’s [technology xyz]".

This is the unfortunate world for a typical BizTalk developer using the out-of-the-box functionality.

And this embarrassing situation has other negative implications:

• As described in Unit Testing with BizTalk Server Projects and Using the Unit Testing Feature with Schemas and Maps, BizTalk developers must set the Visual Studio project property “Enable Unit Testing” (under the Deployment tab) to “True”. This magically changes the base class of each BizTalk Map to “Microsoft.BizTalk.TestTools.Mapper.TestableMapBase” in order to “support unit testing”. Yes, an artefact’s base class is actually changed for that build – so what is being tested is not entirely the actual code that will be deployed into production. The difference between a Debug build and a Release build becomes more significant. (Admittedly for a BizTalk Map, this is less of a concern since the actual mapping is performed via XSLT under the covers and not directly by the base class, but the point is valid nevertheless – this approach is taken for other types of artefacts as well, and you really do not want to deploy Debug builds of any of those into a production environment…)

• If you are like me and some teams I work with, you may want to develop and test the code off-premises (perhaps in your favourite cloud) and then deploy the release/deployment package to an on-premises test environment – where we also want to execute all the tests and have the test results recorded in the on-premises test and release management tools for all team members to access. However, a release/deployment package should never have that special project property set – and this prevents unit tests from compiling and executing against it.

• When developing a BizTalk Map that uses a Scripting Functoid configured to execute a specified method of a class in an ‘External Assembly’, then “any assembly that you choose a script from … must also be in the global assembly cache (GAC) for Test Map to function correctly”. You need to GAC your external assemblies before running the unit tests. GAC —> Yuck!

Microsoft’s Integration Roadmap clearly shows a measured commitment to and place for BizTalk in the future, alongside their Azure Platform as a Service (PaaS) technologies. With the pending release of BizTalk 2016 as a drop-in replacement for BizTalk 2013 R2 (with no code recompilation required!), I thought it was time to refresh the practice of unit testing BizTalk Maps.

The Solution

The open source ChannelAdam Test Framework Library for BizTalk addresses all of these issues and provides the following benefits and features:

• Works with BizTalk 2010 / 2013 / 2016
• Never again set the project property “Enable Unit Testing” to “True”!
• BizTalk Map unit tests can be executed against a release build
• The provided map tester classes allow you to easily unit test both XML and flat file BizTalk Maps
• The design of tester classes follow the clean Arrange-Act-Assert (AAA) testing pattern
• Support for arranging the input and expected output from a string, XElement, an XML serialisable object or loading from an embedded resource
• Performs schema validation of both the input and output by default (easily overridable)
• Support for mocking External Assembly class methods
• Support for filtering assertions of the expected output to allow for dynamic data (such as timestamps or GUIDs)
• Detailed information is provided allowing you to see the differences between the expected output and the actual output of the map.

With this library you now have the tools needed to easily unit test you BizTalk Maps using modern testing practices. No excuses!

For information on how to get started, please see the usage documentation.

Overview

This is an open source .NET Framework 4.0, 4.5, 4.6 library providing functionality for the automated testing of BizTalk 2010/2013/2016 artifacts.

It provides you with an enhanced ability to use modern standard industry testing practices to test BizTalk Maps.

This library is compatible with the legacy, full .NET Framework 4.0 ChannelAdam Test Framework Libraries (version 1) only.

Please see the article Modern Testing of BizTalk Maps for background information on the issues with using Microsoft’s out-of-the-box functionality for testing Microsoft BizTalk Maps.

This library provides the following benefits and features:

• Works with BizTalk 2010 / 2013 / 2016
• Never again set the project property “Enable Unit Testing” to “True”!
• BizTalk Map unit tests can be executed against a release build
• The provided map tester classes allow you to easily unit test both XML and flat file BizTalk Maps
• The design of tester classes follow the clean Arrange-Act-Assert (AAA) testing pattern
• Support for arranging the input and expected output from a string, XElement, an XML serialisable object or loading from an embedded resource
• Performs schema validation of both the input and output by default (easily overridable)
• Support for mocking External Assembly class methods
• Support for filtering assertions of the expected output to allow for dynamic data (such as timestamps or GUIDs)
• Detailed information is provided allowing you to see the differences between the expected output and the actual output of the map.

The ChannelAdam Test Framework Libraries are fully compatible with MSTest (v1) and .NET Framework 4.0, 4.5, 4.6.

Note: I highly recommend using Behaviour-Driven Development practices and the usage of SpecFlow in conjunction with this library.

Getting Started

NuGet Package Installation

To install the ChannelAdam.TestFramework.BizTalk NuGet package run the following command in the Package Manager Console:

1PM> Install-Package ChannelAdam.TestFramework.BizTalk

Usage

The Basics

There are 4 map tester classes to be used depending on the type of input and output of your map:

• BizTalkXmlToXmlMapTester - for testing a map that maps from XML to XML
• BizTalkXmlToFlatFileMapTester - for testing a map that maps from XML to a flat file
• BizTalkFlatFileToFlatFileMapTester - for testing a map that maps from a flat file to a flat file
• BizTalkFlatFileToXmlMapTester - for testing a map that maps from a flat file to XML

Below is some sample MSTest test method code (in a very raw form) for testing a map that maps from XML to XML.

 1// ==================
 2// Variables
 3// ==================
 4
 5// Define some helpful variables for our testing artifacts
 6static Assembly thisAssembly = this.GetType().Assembly;
 7static string inputXmlTestDataEmbeddedResourceName          = thisAssembly.GetName().Name + ".InputXmlTestDataEmbeddedResource.xml"
 8static string expectedOutputXmlTestDataEmbeddedResourceName = thisAssembly.GetName().Name + ".ExpectedOutputXmlTestDataEmbeddedResource.xml"
 9
10// Create the MSTest compatible logging assertion class
11var logAssert = new ChannelAdam.TestFramework.MSTest.LogAssert();
12
13// Create the map tester - in this case for a map from XML to XML
14var xmlToXmlMapTester = new BizTalkXmlToXmlMapTester(logAssert);
15
16// ==================
17// Arrange
18// ==================
19
20// Arrange the input XML and expected output XML from embedded resources
21xmlToXmlMapTester.ArrangeInputXml(thisAssembly, inputXmlTestDataEmbeddedResourceName);
22xmlToXmlMapTester.ArrangeExpectedOutputXml(thisAssembly, expectedOutputXmlTestDataEmbeddedResourceName);
23
24// ==================
25// Act
26// ==================
27xmlToXmlMapTester.TestMap(new MySpiffyMapFromXmlToXml());
28
29// ==================
30// Assert
31// ==================
32xmlToXmlMapTester.AssertActualOutputXmlEqualsExpectedOutputXml();

Note: I highly recommend using the MoqTestFixture as a base class to your test class as it removes the need for you to be concerned with instantiating the LogAssert class and provdes a number of base methods to make testing easier. Please see the ChannelAdam Test Framework Libraries documentation for more information.

The test code above results in the following test output.

 110/10/16 10:00:00 PM - The input XML for the map is: 
 2<ns0:Request xmlns:ns0="http://SampleBizTalkMaps.Schemas.XmlRequest">
 3  <Key>Key_0</Key>
 4  <StringValue>StringValue_0</StringValue>
 5  <DateTimeValue>1999-05-31T13:20:00.000-05:00</DateTimeValue>
 6  <IntegerValue>100</IntegerValue>
 7  <DecimalValue>10.4</DecimalValue>
 8</ns0:Request>
 9
1010/10/16 10:00:00 PM - The expected output XML of the map is: 
11<ns0:Response xmlns:ns0="http://SampleBizTalkMaps.Schemas.XmlResponse">
12  <Key>Key_0</Key>
13  <StringValue>StringValue_0FAKE_GUID</StringValue>
14  <DateTimeValue>1999-05-31T13:20:00.000-05:00</DateTimeValue>
15  <IntegerValue>100</IntegerValue>
16  <DecimalValue>10.4</DecimalValue>
17</ns0:Response>
18
1910/10/16 10:00:00 PM - Validating the input XML for the BizTalk map
2010/10/16 10:00:00 PM - Executing the BizTalk map (XML to XML) MySpiffyMapFromXmlToXml
2110/10/16 10:00:00 PM - Asserting XML output from the BizTalk map exists is True
22
2310/10/16 10:00:00 PM - BizTalk map (XML to XML) execution completed
24
2510/10/16 10:00:00 PM - The actual output XML from the map is: 
26<ns0:Response xmlns:ns0="http://SampleBizTalkMaps.Schemas.XmlResponse">
27  <Key>Key_0</Key>
28  <StringValue>StringValue_0FAKE_GUID</StringValue>
29  <DateTimeValue>1999-05-31T13:20:00.000-05:00</DateTimeValue>
30  <IntegerValue>100</IntegerValue>
31  <DecimalValue>10.4</DecimalValue>
32</ns0:Response>
3310/10/16 10:00:00 PM - Validating the output XML from the BizTalk map
34
3510/10/16 10:00:00 PM - Asserting actual and expected XML are equal
3610/10/16 10:00:00 PM - Asserting The XML is as expected is True
3710/10/16 10:00:00 PM - The XML is as expected

And the test passed successfully!

Advanced Usage

More advanced functionality can be performed with the overloads on the methods used in the above test code.

Arrange - Input and Expected Output

The BizTalkXmlToXmlMapTester has the following method overrides for arranging the input XML.

• void ArrangeInputXml(Assembly assembly, string resourceName) - to arrange the input XML from an embedded resource in the given assembly
• void ArrangeInputXml(XElement xmlElement) - to arrange the input XML from a given XElement
• void ArrangeInputXml(object valueToSerialise) - to arrange the input XML by serialising the given object
• void ArrangeInputXml(object valueToSerialise, XmlRootAttribute xmlRootAttribute) - to arrange the input XML by serialising the given object and applying the given XmlRootAttribute during the serialisation
• void ArrangeInputXml(object valueToSerialise, XmlAttributeOverrides xmlAttributeOverrides) - to arrange the input XML by serialising the given object and applying the given XmlAttributeOverrides during the serialisation
• void ArrangeInputXml(string xmlValue) - to arrange the input XML from the given XML string

Input can be arranged from an embedded resource, XElement, object that is XML serialisable (for which you can also override the root XML namespace when serialised) or simply a string.

This same pattern is followed for arranging the expected output of the map, and for arranging the contents of flat files with the other map tester classes.

Act - Test the Map

The BizTalkXmlToXmlMapTester has the following method overrides for testing your BizTalk Map.

• void TestMap(TransformBase map)
• void TestMap(TransformBase map, IEnumerable<XsltExtensionObjectDescriptor> xsltExtensionObjectOverrides) (see below - Mocking External Assemblies)
• void TestMap(TransformBase map, bool validateInputXml, bool validateOutputXml)
• void TestMap(TransformBase map, IEnumerable<XsltExtensionObjectDescriptor> xsltExtensionObjectOverrides, bool validateInput, bool validateOutputXml)

The validateInputXml and validateOutputXml parameters are self-explanatory.

Mocking External Assemblies

The xsltExtensionObjectOverrides enumerable is the secret to mocking External Assembly class methods. To mock a class, create an Interface that define the method used in the map, and then create and set up a mock object from the Interface. Then use the following code to create the xsltExtensionObjectOverrides, populated with the mock object.

1// Mock the external assembly 'MyExternalAssemblyClassUsedInTheMap' class used in the map ;)
2var mocksOfExternalAssemblyClassesUsedInMap = new List<XsltExtensionObjectDescriptor>
3{
4    new XsltExtensionObjectDescriptor(typeof(MyExternalAssemblyClassUsedInTheMap), myMoqMockForThatClass.Object)
5};  

And test the map, providing the xsltExtensionObjectOverrides parameter.

1// Test the map which will execute methods on the mock objects
2xmlToXmlMapTester.TestMap(new MySpiffyMapFromXmlToXml(), mocksOfExternalAssemblyClassesUsedInMap);

For Other examples, including how to mock an External Assembly, please refer to this example BDD feature file and the implementation of the scenario steps.

Assert - Compare the Actual Output Against the Expected Output

The BizTalkXmlToXmlMapTester has the following method overrides for asserting the actual output from the map against the expected output that was arranged.

• void AssertActualOutputXmlEqualsExpectedOutputXml()
• AssertActualOutputXmlEqualsExpectedOutputXml(IXmlFilter xmlFilter)

All the comparison and logging and formatting of any differences is done for you. Easy!

Ignoring / Filtering XML Elements

The override allows you to specify an IXmlFilter which allows you to specify a list of the local names of XML elements to ignore in comparisons, and/or a list of XPath expressions to ignore in comparisons.

Two constructor methods on XmlFilter allow you to easily specify these lists.

• XmlFilter(IList<string> elementLocalNamesToIgnore)
• XmlFilter(IList<string> elementLocalNamesToIgnore, IList<string> xpathsToIgnore)

Ignoring / Filtering Flat File Differences

Ignoring differences in flat files is a little more tricky, but not too difficult. The ChannelAdam library uses the DiffPlex library for performing text differences.

3 mechanisms on the flat file tester classes are provided for hooking into the DiffPaneModel difference result and manipulating it before a final decision is made as to whether or not the actual output is similar enough to the expected output.

• An event that is raised with the differences

1    /// <summary>
2    /// Occurs when a text difference is detected, allowing a listener to filter the differences and
3    /// change the Line[x].Type to ChangeType.UnChanged so that the difference is no longer treated as a difference.
4    /// </summary>
5    /// <remarks>
6    /// This event or the TextDifferenceFilter property can be used for this purpose.
7    /// </remarks>
8    public event EventHandler<TextDifferenceDetectedEventArgs> TextDifferenceDetectedEvent;

• An action delegate method that is called with the differences

1    /// <summary>
2    /// Gets or sets the Action delegate to be invoked when a text difference is detected, allowing differences to be filtered out by
3    /// changing the Line[x].Type to ChangeType.UnChanged - so that a difference is no longer treated as a difference.
4    /// </summary>
5    /// <value>The Action delegate.</value>
6    /// <remarks>
7    /// This property or TextDifferenceDetectedEvent can be used for this purpose.
8    /// </remarks>
9    public Action<DiffPaneModel> TextDifferenceFilter { get; set; }

• A virtual method that allows you to inherit from the tester class and override the differences when they are detected.

1    protected virtual void OnTextDifferenceDetected(DiffPaneModel differences)

In the previous article, BizTalk Summit 2015 in London - Part 1 - Microsoft’s Roadmap for Integration, we recapped how App Service is key in Microsoft’s roadmap and strategy for Integration and that Microsoft announced App Service will be available on-premises as part of the Microsoft Azure Pack. Microsoft also confirmed that the BizTalk brand is important and is here to stay.

Microsoft’s vision is to democratise integration (simplify so that developers not require specialist expert skills), be the iPaaS leader for enterprise, and build a rich ecosystem for the community and business partners.

This article shines light on various other jigsaw puzzle pieces that were presented at the BizTalk Summit 2015, to further help you understand the wider picture of where “Modern Integration” appears to be heading.

Enterprise Focus - Connecting with IBM Systems

In line with Microsoft’s vision for the enterprise and integrating with existing line of business systems, Paul Larsen, Principle Program Manager at Microsoft, presented the IBM MQ, DB2 and Informix Connectors. These connectors have been developed to allow Azure solutions to communicate with on-premises IBM systems.

An integration solution connecting to an IBM system could be deployed as a hybrid solution when using Azure in the cloud, or deployed completely on-premises solution using App Service on-premises with the Microsoft Azure Pack.

The MQ Connector currently only supports MQ version 8. In contrast, MQ version 8 is actually not supported by BizTalk Server 2013 R2. There was no information on whether version 8 would be supported in BizTalk Server 2016.

The DB2 Connector communicates to DB2 using the Distributed Relational Database Architecture (DRDA) database interoperability standard that DB2 supports. This connector also has support for custom SQL and the Open Data Protocol (OData). To achieve all of this, Microsoft have developed a new ADO.NET provider for DRDA - which also is utilised by the Informix Connector.

Democratisation Focus - The Durable Task Framework

Dan Rosanova, Senior Program Manager at Microsoft, presented a recently open-sourced library for durable, scalable, reliable, traceable and manageable .NET code-based workflows with eventual consistency.

The Durable Task Framework allows developers to write long-running persistent workflows in code using the async/await capabilities.

Interestingly, this framework originally was released as a preview in June 2013 - apparently without much fan-fare or wide reach in the community, because many people thought it was brand new.

The framework provides automatic persistence and check-pointing of program state, versioning of orchestrations and activities, error handling, compensation, automatic retries, asynchronous timers, and diagnostics.

Microsoft internally uses it to reliably orchestrate long-running provisioning, monitoring and management operations. The orchestrations can scale out horizontally by adding more worker machines.

The concepts of logic, state and the runtime are separated. State management currently happens in Azure Service Bus, optionally with an Azure Storage account. Your custom code is the orchestration logic.

Please refer to the Durable Task Framework Wiki for usage documentation.

One example use case for the use of this framework is the situation where distributed transactions or two-phase commit protocols typically would be required - and where the services being consumed do not support locking or transactions.

In the above scenario, it is common for a developer to create a BizTalk orchestration to robustly orchestrate the calling of those multiple services. Now however, there is another viable, reliable, durable and robust implementation option. Depending on the full scope of requirements, this scenario can be implemented in .NET with the Durable Task Framework and Service Bus - instead of within a BizTalk orchestration.

Imagine that part of your custom solution for a customer might be starting an orchestration task from within a Web App or an API App.

To summarise - robust, durable, traceable and manageable orchestration logic in pure .NET without the need for specialist, expert developer skills.

Democratisation Focus - Logic Apps

Stephen Siciliano, Senior Program Manager at Microsoft, presented an in-depth look at Logic Apps.

Stephen first demonstrated how to develop an application that archives Twitter tweets to a DropBox account.

The barrier of entry for developing Logic Apps is low, which means that specialised expert developer skills (such as those required for BizTalk development) are not required.

Some notable features of Logic Apps are that they are resilient against failure with an “at least once” guarantee, and they can directly call any REST endpoint without the need for an API App. There is also the ability to use parameters to separate configuration from the definitions (a good story for deployments to different environments), the support for large messages (less than 100mb), and support for binary blobs by externalising the state to storage or Base64 encoding it into the JSON message.

Enterprise Focus - Microsoft Azure BizTalk Services (MABS) 1.0 Features in App Service

Back to the enterprise vision, Stephen Siciliano also demonstrated an Enterprise Application Integration scenario with the usage of the BizTalk XML Validator, BizTalk Transform API App and BizTalk XPath Extractor in a Logic App.

Prashant Kumar, Senior Program Manager at Microsoft, discussed how the functionality of the Microsoft Azure BizTalk Services (MABS) 1.0 is available in App Service, including the XML Validator, Transform Service, and the Flat File Encoder etc.

Enterprise Focus - BizTalk B2B in App Service

Prashant Kumar also discussed and demonstrated some of the BizTalk B2B API Apps - TPM (for managing trading partners, agreements and artefacts), AS2, EDIFACT and X12.

Of note, there was discussion about how the features within the BizTalk platform are bit-by-bit being “broken out” into individual apps. One could almost describe that as a re-architecture.

Many more BizTalk features also now are becoming available in App Service, including: OAuth, JSON support, monetisation in the marketplace, pre-baked integration Logic App recipes, long running workflows and the BizTalk Rules API App.

Enterprise Focus - BizTalk Rules API App

The new BizTalk Rules API App can be used to help decouple business logic from application code. It retains many of the familiar concepts from the BizTalk Rules Engine (BRE) - such as Vocabulary, Policies and of course the Rules.

It was interesting and concerning to hear Microsoft talking in terms of enabling business users to make changes to business rules - for instance, on the fly, in production. It would be helpful if Microsoft addressed more real world concerns about a change workflow or lifecycle and the testing of business rule changes before they are deployed into production.

Enterprise Focus - API Management

Sameer Chabungbam, Principal Program Manager at Microsoft, presented how the API Apps are a powerful platform for building and managing API’s - something that is increasingly more important in the enterprise.

“Connector” API Apps let you build functionality to communicate with other systems - similar to the role of an adapter to another system.

Sameer demonstrated how to configure an API App with Swagger and optimise the API App for usage within a Logic App.

Migration of BizTalk Artefacts to App Service

Jon Fancey, Integration MVP, and Dan Probert, introduced a new company, The Migration Factory that in the near future, for a fee, aims to automate the migration of BizTalk artefacts to App Service for cloud deployment or on-premises hosting with the Azure Pack.

Due to technical complexities with some orchestration implementations, all solutions may not be 100% automated, but a very high percentage automated conversion rate is possible.

This is a rather a telling tale about the direction of Modern Integration implementations.

BizTalk Server Is Here to Stay

General consensus though is that BizTalk Server still has a niche in the market and will be around for many more years than some people can imagine. There are many on-premises systems that for various business reasons will never be deployed to the cloud.

BizTalk Server’s features are rich and powerful. As Michael Stephenson, Integration MVP coined it, BizTalk Server is the “Integration Swiss Army Knife” - it can do it all.

Steef-Jan Wiggers, Integration MVP, presented some strong cases for BizTalk Server playing a role in data enrichment and distribution, from deep integration with line of business systems such as SAP to consumer applications. Mission critical applications also are likely to remain on-premises and could be too difficult or not cost effective to redesign.

Further emphasising BizTalk Server’s relevance and interoperability in Modern Integration world, Steef-Jan also demonstrated BizTalk Server 2013 R2’s capability to communicate with REST endpoints and also convert between SOAP and REST payloads with JSON encoding and decoding.

Kent Weare, Integration MVP, also demonstrated how Azure API Management can be used to create a REST API endpoint that acts as a facade to an existing SOAP endpoint on an on-premises BizTalk Server.

Business Activity Monitoring (BAM) in Power BI

Todd Glad Nordahl, Technology Solution Professional at Microsoft, presented the Power BI Designer and Dashboard, and discussed how it can be used on top of BizTalk Server to connect to BizTalk’s Business Activity Monitoring (BAM) data and augment that with other data sources to help make business decisions.

Windows Communication Foundation (WCF)

There was little discussion about the future of WCF, which appears at odds with Modern Integration and the Web and API Apps. WCF seems to be fading into the background and becoming a Legacy Integration technology.

It would be interesting to see an official statement from Microsoft about the future of WCF.

Reflections

Reading between all these lines, the BizTalk platform is being re-architected for the Modern Integration world, into App Service, which can be used in the cloud or on-premises.

The deployment, versioning and dependency issues that plague many BizTalk Server solutions due to its dependency on the Global Assembly Cache (GAC) will finally be resolved by moving to the App Service architecture.

There however are still many unanswered questions and many unknowns.

1. Within the world of Microservices and new container technologies, there will need to be a brand new set of guidelines and better practices to understand and apply.
2. Of course, there may be a bunch of new challenges waiting to be discovered and solved, and avoiding deployment issues in a Microservice world is one of them.
3. Logic Apps have tracking and archiving of content (does anyone have concerns about privacy with this?), and Azure API Management provides analytics. I am not sure how this will translate into equivalent and improved functionality of BAM.

All the pieces on the chess board are being lined up, and Microsoft now appears to have a solid architecture for Modern Integration. We now may be witnessing the start of the turning of the tide.

Architects and enterprises now will have the choice to use App Service functionality (in the cloud or on-premises) in addition to the option of implementing a solution using the equivalent functionality in BizTalk Server.

I think everyone agrees that the BizTalk Summit 2015 in London was a smashing success. Saravana Kumar’s BizTalk360 team have once again done a fantastic job at uniting the world of Integration. This year saw 330 people from 20 countries, with all the speakers being either Microsoft employees or Integration MVP’s.

The first day primarily was filled with the presentations from Microsoft on their new App Service functionality, and in the second day the Integration MVP’s were allowed to shine.

This first article concentrates on the roadmap and strategy that Microsoft has for Integration.

Important On-Premises Announcements

Before we dive into the roadmap, there were two important announcements for the community in the area of on-premises integration.

Firstly, there will be a new major version of BizTalk Server released in 2016 to align with and provide support for the new releases of Windows platform products - such as the next version of Windows Server, SQL Server and Visual Studio.

Secondly, the App Service functionality will be available on-premises with the next release of the Windows Azure Pack. The release date however was not specified, but from a few discussions I have the impression that it will be months away, not weeks.

Microsoft’s Roadmap and Strategy for Integration

Josh Twist, Principal Program Manager on the Microsoft Azure team, originally was the keynote speaker but unfortunately was unable to attend. The audience nevertheless warmly received the keynote presentation by Karandeep Anand, Partner Director of Program Management at Microsoft.

Karandeep’s keynote articulately explained Microsoft’s roadmap and strategy for integration. He spoke of Microsoft’s journey to the cloud so far and the many learnings they have gained.

Learnings from Azure Websites

Azure Websites (now Web Apps) is by far, significantly the largest service currently used in Azure. The explanation, according to Karandeep, is the simple, low-complexity barrier of entry, with rich features and tooling, automatic load balancing, scaling and geo-redundancy.

The identified gaps with Websites however are a lack of integration with business logic, rules, triggers or workflow.

Learnings from BizTalk Services

There were many learnings from Microsoft’s BizTalk Services offering as well. Importantly for many customers, BizTalk as a brand name has been recognised officially by Microsoft as being important. Karandeep confirmed that the BizTalk name is here to stay. The BizTalk Services offering also validated various cloud design patterns, and hybrid connectivity was identified as critical and one of their differentiators in the market.

The identified gaps with BizTalk Services include the need for more out-of-the-box sources and destinations, pipeline templates, custom code support, long-running workflows and parallel execution.

All in all, Microsoft identified the need to significantly invest in this space to approach the same value and functionality as BizTalk Server.

Learnings from BizTalk Server

The learnings from BizTalk Server also were quite interesting. It was no surprise however when Karandeep mentioned that there is a high-complexity barrier of entry into the world of BizTalk. This unfortunately encourages a proliferation of the “hack zone” where developers hack together applications in an effort to develop a quick solution, but these applications or scripts don’t necessarily have the robustness, scalability or desired level of support and maintainability.

Microsoft’s Vision

Microsoft’s subsequent vision that addresses all of these learnings is three-fold.

1. Firstly, Microsoft wants to fill the gap between the high-complexity barrier of entry of BizTalk Server and the low-complexity barrier of entry of Web Apps (Azure Websites). The idea is to democratise integration - by making it simple, easy, and approachable by the masses of developers, not just specialised experts.
2. Next, Microsoft importantly will complement this ease of use with a heavy focus on the enterprise, aiming to be the Integration Platform-as-a-Service (iPaaS) leader, providing 24/7, robust, resilient services with all the solid functionality of BizTalk Server.
3. Lastly, Microsoft realise that their offering should provide an extensible foundation that the community and partners can enrich, by creating a public marketplace that supports plugins and monetisation.

Microsoft’s Roadmap

Microsoft has a holistic roadmap that aims to:

• Empower business employees with insights (analytics and statistics) to help make solid decisions,
• Enable the transformation of businesses with the agility to develop solutions faster; and
• Enable businesses to engage their customers by connecting with any device at Internet scale. Hence, the App Service cometh.

The App Service

App Service is the resulting integrated offering from Microsoft that enables the development of rich, engaging and intelligent applications that scale as your business grows.

For more information about App Service, please see http://azure.microsoft.com/en-us/services/app-service/.

Continued in Part 2 » BizTalk Summit 2015 in London - Part 2 - Turning of the Tide?