How to move from BizTalk Server to BizTalk Services (WABS) - BizTalk Summit 2014, London
-
Upload
biztalk360 -
Category
Technology
-
view
1.110 -
download
4
description
Transcript of How to move from BizTalk Server to BizTalk Services (WABS) - BizTalk Summit 2014, London
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 –@[email protected]