t Sponsors Jon Fancey Integration MVP, Author Migrating to Microservices BizTalk Summit 2015 – London ExCeL London | April 13th & 14th Dan Probert AffinusLabs

Who are ◦10-time Microsoft MVP ◦Wrote ‘THE’ book on MABS – but we won’t talk about ◦15-years of crazy BizTalk projects ◦BizBert

What we’ll cover Recap on last year Mapping from BizTalk Server to the new world Practicalities of migration Tooling

Recap - Why move? Cloud economics ◦Lower cost ◦Flexibility – PAYG, scale up/down – provision in minutes - not weeks/months iPaaS ◦Less management, server patching, etc ◦Auto-update of API Apps (if you want it) Integration is changing ◦New targets, services ◦Modern development, faster delivery ◦Citizen integrator ◦(Enterprise) integration is too hard – many problems are not central to what you need to do Why not? ◦For B2* integration is externally facing anyway – so move compute to cloud ◦And for EAI platform is coming to you via Azure Pack

Recap – So what changed? Replatform of BizTalk Services ◦Broken out into API apps ◦Mapping ◦Rules ◦Validation ◦Flat file processing ◦Adapters ◦.. ◦No longer Windows workflow based ◦Workflow now implemented as Logic App We are going to need a new book

The Challenge BizTalk Server architecture ◦Ports ◦Pipelines ◦Maps ◦Orchestration ◦Rules ◦Adapters ◦EDI TPM ◦BAM, Tracking ◦Oh my!

Mapping Mapping is fundamental to integration BizTalk Server maps != BizTalk API Apps Transforms ◦But Still schema based and XML schema fully supported Three approaches ◦Maps in BizTalk Server are ‘just’ XSLT much of the time (trfm supports this) ◦Maps can be converted to transform trfm files using Microsoft-provided tool ◦Maps can be hosted as-is using Api App – could even use XSLT 2.0 Download the MABS SDK ◦Command line map conversion tool ◦VS designer – upload trfm files (same with schema validation)

BRE Rules API App ◦Portal-based designer Similar concepts as BizTalk Server ◦RETE engine ◦Vocabularies and Policies Facts - currently support for: ◦XML and literals

Trading partner management Important for EDI – nobody wants to re-key config for 5000 trading partners Need the ability to move definitions of trading partners and agreements to cloud We’re working with the product group to provide for similar migration experience as MABS ◦E.g. BizTalk Server > TPM conversion > Azure DB > TPM App

BizTalk pipeline vs Logic App Process stages map to API Apps Custom processing via APIs Custom processing via pipeline components

Pipelines Execution model for Logic Apps maps nicely to pipelines ◦Sequence of operations ◦Conditional execution ◦Ability to spin over previous step output – (dis)assembly ◦Hooking up to Service Bus queue/topic semantic provides persistence, pub-sub, load- levelling, etc. Custom pipeline components are converted to logic apps ◦Logic apps have “at least once” semantics Some things are different ◦No transactions ◦Message type must be specified not determined

Wouldn’t it be great… IF A COMPANY WAS ALREADY WORKING ON THIS PROBLEM?

Introducing… The Migration Factory In exclusive partnership with Microsoft Fully-automated approach to migration With help if you need it

The migration workflow Export ◦MSI from BTS Upload ◦MSI to The Migration Factory Parse ◦Generated report Pay/Collect ◦Convert, package and deploy Export MSI UploadParse Generate Report Accept Payment Convert Deploy You Us

Demo Migrating pipelines to Logic Apps

Product Scope Everything But we know that some things are harder than others ◦Gaps & Differences So it won’t be ‘everything’ – but as close as we can get Some BizTalk ‘features’ are more popular than others Importance of the parse/report stage is to provide a “to do” list of actions ◦We currently understand the syntax and some semantics ◦Structural conversion of ◦Maps (and bring schema along), Rules, Pipelines (and pipeline components) ◦Orchestration to our target* (more in a moment)

Orchestration migration Hard problem to solve – either way Often used, often unnecessarily  Logic Apps architecture fundamentally different to BizTalk Server ◦Execution is partly explicit / partly inferred – e.g. parallelization ◦Many orchestration features are there but different e.g. IF/THEN/ELSE, retries, etc Plans ◦We already parse out ODX files ◦We are able to target multiple formats depending on complexity ◦ODX > Logic App ◦Expression shapes become API apps (Simple Expression shapes become built-in function calls) ◦‘as a service’

But BizTalk is more than this Support for many messaging patterns ◦Request-Reply / Solicit-Response ◦Correlation ◦Content/Context-based routing ◦Convoys, Scatter/Gather, Fork/Join flows Logic / API Apps have different characteristics ◦Not transactional – provides ‘at least once’ ◦Latency profile different Many messaging patterns are easily identifiable through parsing analysis ◦And we will provide solutions for as many as we can as well as with the product group as well

Finally… BAM / Tracking Ok there’s no BAM But 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 Logic Apps provides tracking infrastructure ◦REST APIs to access tracking and archived content Don’t forget that ◦BAM is an API and set of tables (with some smart time sequencing etc) ◦You can interact with API remotely simply with web services ◦So you could continue to use BAM as licensed BizTalk customer

Where are we? BizTalk FeatureMABS Feature/AlternativeSupport MapsTransformGood Schema Good PipelinesLogic AppGood* AdaptersSource/DestinationOK OrchestrationLogic AppOK/Tough BREAPI AppGood/OK # BAM / TrackingTrackingOK Trading partner mgmt. Good *unless Tx # db / custom

We want your feedback Register your interest at Pricing models ◦T-shirt sizes: S/M/L ◦Fraction of cost of manual conversion ◦Do if for / with me Automated self-service ◦Billed to subscription? Priorities ◦What kind of integration applications do you have?

Summary Migrating BizTalk solutions to Logic Apps is possible ◦Many areas are straightforward ◦Others are more challenging ◦But we will do as much as we can, roadmap will plug gaps ◦Thinking outside the box can help ◦You can achieve same requirement in a different way, e.g. conditions, parameters ◦Talk to us, planning on releasing our tools later this year

Thanks! Any questions, follow up

The logic in Logic Apps Conditions support logical expressions e.g. IF/THEN/ELSE Can be joined and nested (IF this AND this) OR this Parameters provide for contextual state Passing and persistence