We are proud to donate $10,000 to Great Ormond Street Hospital Charity

BizTalk360 was released as a commercial product back in 2011 and since then at end of every year we donate to GOSH (Great Ormond Street Hospital charity) regularly. In 2012 we had given $1,625, in 2013 we raised this to $2,125 , in 2014 we donated $5,000 and this year we are increasing it to […]

The post We are proud to donate $10,000 to Great Ormond Street Hospital Charity appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

Year 2015

Time flies when your having fun. I did have fun this year working with
Microsoft Azure and Integration at a utility company. Did an IoT project,
bridged on premise applications to the outside world (Service Bus Relays and
Queues) and some old skool integration. What else did I do? Well you might have
guessed: speaking, travelling, and have an occasional beer. Pictures tell more than a

My Point of View: Microsoft Releases Integration Roadmap

My Point of View: Microsoft Releases Integration Roadmap

On December 24th, 2015 Microsoft provided a Christmas gift to its customers, partners and broader eco-system in the form of a highly sought after roadmap.  For several years, customers and partners have been awaiting an “official” statement from Microsoft with clear direction on where they are headed.  Competitors have used the lack of a roadmap against them in compete situations. That has all changed as of this writing.

You can find the roadmap here and BizTalk360 founder and Microsoft MVP Saravana Kumar has provided his thoughts here.

My POV:

BizTalk is not dead

The BizTalk ’franchise’ will continue to exist.  We will see a BizTalk Server 2016 next year that will include the following features:

    • Platform Alignment (Windows Server, SQL Server, Visual Studio)
    • SQL Server 2016 support and  Always-On Availability groups which will simplify BizTalk Disaster Recovery.
    • Full support for High Availability in Azure IaaS
    • Better support for cloud based integration and SaaS connectivity.  Today we have a lot of SaaS connectivity through API Apps.  I suspect we will see BizTalk Server to tap into these API Apps rather seamlessly.
    • Bug fixes and Adapter enhancements.

We will also continue to see ’BizTalk’ capabilities being leveraged in Logic Apps in the form of API Apps such as BizTalk Transformations, encoding/decoding, Business Rules etc.

A unified vision from Microsoft

For some outsiders this may not be abundantly clear, but the BizTalk team lives within the Azure App Service team.  Subsequently, both the Logic App and BizTalk teams are the same team. This roadmap accounts for this and represents a single vision for Integration at Microsoft. 

For people familiar with both BizTalk and Logic Apps, it is probably evident that BizTalk and Logic Apps tend to operate at different ends of the integration spectrum. With BizTalk, customers get a solid on-premises integration broker that is very robust.  It is also very feature rich with support for BAM, Business Rules, EDI, ESB, Exception Portal, Pub/Sub messaging and much more.  However, all of these capabilities, there is a price to pay in terms of complexity and technical dependencies for it all to work.  As a result agility can become a concern for some customers.  For teams with concerns about BizTalk’s agility, their concerns can often times be resolved in Logic Apps.  In Logic Apps we have IPaaS capabilities with loads of SaaS connectivity and (soon)direct integration with API Management.

I think the following image (from roadmap) does a great job of illustrating where Microsoft is headed.  The goal is clearly symmetric capabilities, but provided in a modern platform. This modern platform is not BizTalk Server, but rather building out Logic Apps to address outstanding enterprise features and deliver them in the cloud and on-premises.  A key enabler of this story is Azure Stack.  Without it we will not see the new Logic App assets running in your own data center.  Microsoft is targeting an “IPaaS” preview in Q2 2016 and GA by end of the 2016.

image_thumb[1]

Bringing more people to the party

Let’s be honest, BizTalk developers have a very niche skill set.  I have been working with BizTalk since 2004 at several different organizations.  I have seen some amazing BizTalk solutions being built that literally run a company and have enabled many business opportunities for organizations.  I have also seen what happens when you don’t have good BizTalk people working in BizTalk.  It gets messy quickly.  This especially a problem in the BizTalk 2004 and 2006 days when there was little documentation and guidance out there.  Today, there are so many resources out there provided by MVPs and the community this is becoming less of an issue. (What other ecosystem can brag about a weekly international user group meeting run by the community). However, and I am confident in saying this, there are not a lot of BizTalk experts out there and it is a steep learning curve in getting people to a place where they will be productive and not ’paint an organization into a corner’.

While this may not be a popular statement with people who have invested a significant amount of time in BizTalk, it needs to get simpler.  Microsoft has around 10 000 BizTalk customers (give or take).  With the introduction of SaaS and mobile, and subsequently more demand for integration, how can you scale both a technology and a resource pool to meet that demand?  In my opinion, you can’t do that with BizTalk nor is it designed to excel in these ’new’ use cases.

As a result, we will continue to hear  messages of ’democratization of integration’ or ’citizen developers’.  While many will scoff, the need is real.  If I need to connect a SaaS application, such as Salesforce, with an on-premises application this should take hours and not days(if you need to setup BizTalk environments).  For organizations with an existing broker or ESB, they can turn this around quicker than an organization without, but not as quick as an IPaaS platform.  At the end of the day, organization don’t do integration for the sake of integration but rather for a business opportunity and the old adage of ’time is money’ could not be truer in today’s economy.

The biggest challenge, and common rebuttal,  in a simplification scenario is that integration can be complex.  This is true and this will not go away.  Recently, my team has been involved in a complex energy trading implementation with many complex, large interfaces with critical data.  I am very confident in saying that this was not a good use case for IPaaS, at least not at this time. 

However, I also run into scenarios such as SaaS connectivity where I don’t need the heavy broker.  So clearly I can relate to both points of the integration spectrum.  For customers, lowering the barrier of entry for building interfaces is a good thing.  Expert integrators will continue to be required to address more complex scenarios and develop the right patterns and architectures, but we will also see integration tools being made available to mobile and web developers to build interfaces in a timely and cost efficient manner.  Ultimately this will allow Microsoft to grow both the platform and the ecosystem.  A healthy ecosystem is good for all parties.

image_thumb[3]

Conclusion

I am sure everyone reading the roadmap would love a magical, cohesive platform that combines both BizTalk Server with Azure App Service yesterday.  BizTalk was not built overnight, and similarly it will take time for the convergence of these two platforms to happen.  The good news is that we have official confirmation from Microsoft on where they are headed which is a great step while we await the bits to arrive.

Take this for what it is worth, but here is how I am acting on this roadmap.

  • Continue to use BizTalk for its strengths.  If you have complex integration needs that deal with on-premises systems, or complex messaging patterns,  continue to use BizTalk for those purposes. 
  • The SQL Server Always On feature may be worth the price of an upgrade alone from a Disaster Recovery perspective.  Let’s be honest, DR with the current BizTalk version is not ideal
  • Where you have trading partner, that can leverage APIs, mobility or SaaS connectivity requirements look to the modern IpaaS platform.  I am a big fan of keeping this type of integration on the edge of my enterprise.  I don’t want to open up firewalls and manage those configurations using legacy approaches.  Very easy to do so using Azure API management and API Apps. 
  • Azure Service Bus is a great way to bridge on-premise workloads with IPaaS connectivity.  It also enables Pub-Sub for Logic Apps.
  • Vote early and vote often! The Azure App Service team is very interested in feedback.  If you think something is missing, add it on User Voice here. Back in May I created topic for allowing BizTalk to talk to API Apps in order to allow for SaaS connectivity in BizTalk.  While I cannot take credit for this featuring being included in BizTalk 2016, it does show that the team is listening.

What is the Microsoft Integration roadmap?

For a very long time there was lot of debate and frustration within the Microsoft BizTalk Server community, what is going to be Microsoft Roadmap with BizTalk + some of the new cloud integration offering like MABS (Microsoft Azure BizTalk Services), Azure App Services (LogicApps and API apps), to some extend with Service Bus (Queues […]

The post What is the Microsoft Integration roadmap? appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

REST JSON Christmas Puzzle

REST JSON Christmas Puzzle

If I use the BizTalk 2013 R2 JSON Encoder pipeline component to convert the following XML <ns0:ASCIISchema xmlns:ns0="http://RestASCIICharTest.ASCIISchema"><TAB>    </TAB><LF> </LF><CR> </CR><SPACE> </SPACE><ExtendedASCII255></ExtendedASCII255></ns0:ASCIISchema> to JSON I get all null elements { "TAB": null, "LF": null, "CR": null, "SPACE": null, "ExtendedASCII255": null } I wanted to get TAB, LF, CR or a space not null. For a […]
Blog Post by: mbrimble

Migration from BizTalk 2006 to 2013R2: lessons learned

What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:

1. You need an intermediate step

Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)

2. Install the latest BizTalk CU on your development machine

The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.

We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.

When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:

That last error lead us in the right direction: BizTalk Server 2010 CU2:

This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.

After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!

So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.

Migration from BizTalk 2006 to 2013R2: lessons learned

What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:

1. You need an intermediate step

Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)

2. Install the latest BizTalk CU on your development machine

The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.

We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.

When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:

That last error lead us in the right direction: BizTalk Server 2010 CU2:

This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.

After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!

So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.