BizTalk Server to BizTalk Services, How to move from BizTalk Server to Windows Azure BizTalk Services (WABS) In this talk we’ll look at the challenges and opportunities in moving to BizTalk Services both from BizTalk Server and other platforms. I will show the tools available to assist in this process and methods to ease the effort of migration as well as how to go about testing and validation your migrated solutions.
Jon Fancey -Integration MVP, Author
Jon Fancey is a co-founder of Affinus, a UK-based consultancy specializing in large-scale enterprise problems and solutions. Jon focuses on Microsoft’s server products, in particular BizTalk Server and SharePoint as well as web services and associated technologies. He has written for MSDN Magazine and Web site and talked at various Microsoft-focused conferences including TechEd. Jon is recognized by Microsoft as an MVP for his community contributions. He is co-authoring a book on Windows Azure BizTalk Services along with the Microsoft PM Karthick Bharathy
BizTalk Summit 2014, London March 03-04
Brought to you by BizTalk360
2. 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!
3. 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
4. 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, …
5. 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
6. The Challenge
BizTalk Server architecture
◦ Ports
◦ Pipelines
◦ Maps
◦ Orchestration
◦ Rules
◦ Adapters
◦ EDI TPM
◦ BAM, Tracking
◦ Oh my!
7. Mapping
Mapping 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
9. 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
10. BizTalk pipeline vs WABS bridge
Similar process stages
Custom
processing
via message
inspectors
Custom
processing
via pipeline
components
11. 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
14. 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?
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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