brought to you by

BIZTALK SUMMIT 2014, LONDON

MARCH 03-04sessions. discussions. networking and

more

Moving To BizTalk ServicesJon Fancey

Who am I? @jonfancey, jonfancey.com

Microsoft MVP for almost 10 years

Author of new WABS book, numerous integration whitepapers on MSDN, TechEd speaker…

Co-founder of Affinus

NOT a Microsoft employee!

What we’ll cover The book

Specifically, Chapter 8 – moving to BizTalk Services from BizTalk Server

Only 45 mins, lots of material, demos

Probably easier to ask questions at the end

Why move? Cloud economics

Lower cost

Less management, server patching, etc

Modern development, faster delivery

Flexible scale – provision in minutes not weeks/months

New capabilities – web-based management, new mapper, …

Migration Challenges 80/20 rule

◦ WABS is very different, but many capabilities are similar◦ We’ll focus here on what’s the same or similar◦ Look at options and strategies for when things are different◦ We’ll look at how to get 80% of the way there using tooling and the remaining manual effort◦ In the medium/long term this may be a good bet

The Challenge BizTalk Server architecture

◦ Ports◦ Pipelines◦ Maps◦ Orchestration◦ Rules◦ Adapters◦ EDI TPM◦ BAM, Tracking◦ Oh my!

MappingMapping is fundamental to integration

But mapping has been rewritten in WABS

Still schema based and XML schema fully supported in WABS

Two approaches

Maps in BizTalk Server are ‘just’ XSLT most of the time – i.e. no code

Maps can be converted to transforms in WABS

WABS transforms can support XSLT (1.0)

WABS provides command line map conversion tool

Demo Converting a BizTalk map

Pipelines Bridges in WABS are a funky combination of pipeline and processing

◦ Bridges are stateless◦ Bridges are not transactional (because they are stateless)◦ Bridges have predefined processing stages◦ Bridges allow custom code◦ Bridges can call other bridges◦ Bridge templates are not extensible

So bridges are pretty fundamental too

BizTalk pipeline vs WABS bridge Similar process stages

Custom processing via message inspectors

Custom processing via pipeline components

Trading partner management WABS TPM is compatible with BizTalk Server

Tooling provided to move trading partners and agreements to WABS

WABS now supports EDIFACT as well as X12 and AS2

Demo Moving trading partners to the cloud

Now for the tough stuff

Orchestration migration Hard problem to solve

But often used, often unnecessarily

WABS architecture fundamentally different to BizTalk Server

Workflow is planned in service but not yet and not compatible

Wouldn’t it be nice if someone was working on it?

Demo Migrating orchestration to WABS

Messaging patterns Content-based routing

Subscriptions

Convoys

Scatter/Gather, ….

…

“Receive” Bridge “Transmit” BridgeOrchestration

BAM / Tracking It’s unlikely lack of BAM will stop your solution from working

◦ Rare to take dependencies on data in BAM as part of a solution – but possible of course

WABS provides tracking infrastructure, SQL Azure database that is very useful for monitoring

If you’re a BizTalk customer don’t forget that ◦ BAM is really just an API and set of tables◦ Can interact with API remotely simply with web services

Business activity monitoring is planned

BRE No support currently in WABS for business rules engine

Support is planned, aim is to be compatible with BizTalk rules

For now, workflow and workflow rules provides an alternative◦ Conversion from BRE to WF rules is possible with some limitations

Also, could call BizTalk rules engine remotely as a service, depending on licensing

Where are we?

BizTalk Feature WABS Feature/Alternative Effort

Map Transform Tooling

Schema Schema Low

Pipeline Bridge Some

Adapter Source/Destination Depends

Orchestration Workflow High

BRE Workflow rules High

BAM / Tracking Tracking Medium

Trading partner mgmt. Trading partner mgmt. Low

• Unfortunately, the devil is also in the details

Service Bus + WABS + Workflow Service Bus glues everything together

◦ Receive and send bridges◦ Provides durability and ordering – WABS is stateless◦ Enables subscription

Bridges either side of workflow provide◦ Property promotion◦ Mapping on the ‘ports’◦ Custom components◦ Extensibility of adapter framework will plug gaps in current sources/destinations

Composes with other Azure services◦ E.g. Scheduler provides time-based processing

What makes sense to move? Not everything

◦ May depends on data classification◦ Where data is coming from/going to◦ Not for On-prem <> on-prem EAI◦ But very useful for cloud <> cloud

It’s not all or nothing◦ Consider moving part of a solution to the cloud, keeping the rest on prem◦ Hybrid integration patterns are important

Summary Migrating BizTalk solutions to WABS is possible

◦ Many areas require little effort – particularly straight messaging solutions◦ Others are more challenging

◦ Tooling helps, roadmap will plug gaps◦ Thinking outside the box can help, achieve same requirement in a different

way, e.g. bridge chaining◦ Talk to us , planning on releasing our tools later this year

The Book http://www.packtpub.com/getting-started-with-biztalk-services/book

• First book in market on BizTalk Services• Written by me (!) and Karthik from the product group• Technically reviewed by other MVPs and Microsoft employees

• Published March 2014• Forewords by Scott Guthrie CVP Windows Azure, Vivek Dalvi,

Principal GPM, BizTalk

Thankyou

Any questions, follow up –@jonfanceyjonfancey.comJon.fancey@Affinus.com