1. ERP/LOB, ESB and Azure AppFabric Integration
3/31/ :21 PM
ERP/LOB, ESB and Azure AppFabric Integration
Harsha Karunaratne, Jeff Johnson
Integration Specialists
Microsoft
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Agenda A changing landscape Extending ERP/LOB through this landscape
Enterprise Platform and Applications
Extending ERP/LOB through this landscape
ESB – Enabling Business Integration Infrastructure
Reach for the cloud with Azure
Before we get started -
Do you currently have an SOA strategy/vision
If Yes
Where are you on the roadmap
If No
- We would love opportunity to help you get started

3. The Changing Landscape Enterprise Integration Domain
“SPAGHETTI” OF PROPRIETARY INTERFACES
INTEGRATION BROKER (EAI/B2B)
ENTERPRISE SERVICE BUS
E-COMMERCE
CRM HR
ERP
CLOUD SERVICES
ERP HR HR
ERP
E-COMMERCE
CRM
E-COMMERCE
CRM
BUSINESS PARTNER
BUSINESS PARTNER
ERP
CLOUD SERVICES HR
E-COMMERCE
CRM

4. The Changing Landscape Application Domain
3/31/ :21 PM
The Changing Landscape Application Domain
Reach
Agility
Expose
Compose
Consume
Devices
& People
Web 2.0
Trading Partners
& Cloud
Data
CRM
Custom Apps
Legacy
Provision New Hire
Order to Cash
Engineering
Change Request
Portal
ERP
Create Work Order
Ship Product
Create Opportunity
Delete P.O.
Connect biz apps
ECC cycle
Services exposed, composed into higher order services and/or business processes
Consume and blended at the user experience
gsx show & tell
broaden reach
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

5. Extend ERP with BizTalk Demo
BizTalk Server 2009
Goods Receiving into SAP
Time Sheet Entry into SAP

6. Composite Applications
Office
Business
Applications

7. Customer Example – Major Oil & Gas Co
Documents associated with Work Order. Fetched from Documentum
- Major oil and gas
Maximo asset management work items
Project related....
Performance, KPIs etc
Materials order information etc from SAP

8. Customer Example – NHS CUI

9. And now..

10. ESB and AppFabric Service Bus
BizTalk 2009 ESB Feature Highlights
Itineraries
Resolvers
Demo
Extend to the Cloud
AppFabric Service Bus Overview
Connect to Cloud via BizTalk
Contact:
Thanks Harsha
Like to build on what Harsha covered and look in more detail how we can move toward more agile architecture approaches using cloud and ESB

11. The Changing Landscape Application Integration Domain
“SPAGHETTI” OF PROPRIETARY INTERFACES
INTEGRATION BROKER (EAI/B2B)
ENTERPRISE SERVICE BUS
E-COMMERCE
CRM HR
ERP
CLOUD SERVICES
ERP HR HR
ERP
E-COMMERCE
CRM
E-COMMERCE
CRM
BUSINESS PARTNER
Moving on from more traditional approaches to integration and toward service bus –
What differences are – agility, more decisions made at runtime and not design time
Connect to off-premise services and leverage cloud based infrastructure
Build on what we have seen so far and look at the Biztalk 2009 ESB capabilities and then connect to Azure AppFabric Service Bus
BUSINESS PARTNER
ERP
CLOUD SERVICES HR
E-COMMERCE
CRM

12. Enterprise Service Bus
Benefits of ESB
Service Consumer
Service Consumer
Service Consumer
Location & Version
Transparency
Transport Protocol
Conversion
Data
Format Transformation
Enterprise Service Bus
Invocation &
Orchestration
Error Handling
& Repair
Message Interactions
Support
Moving on from more traditional approaches to integration and toward service bus –
What differences are – agility, more decisions made at runtime and not design time
Central point of mediation, security and access control
Dynamically control how services are invoked, messages transformed, allow looser coupling of applications
Client applications don’t need to know physically where the endpoint resides, it can be virtualised
Of course cope with a variety of transport adapters and connecters
Intelligent bus / back bone etc
Service Provider
Service Provider
Service Provider

13. All decisions are made and locked in at Design Time or at Deployment!
Static Receive Port
Static Send Port
Hard Coded Map Name
Static Schema
Static Receive Port
Static Send Port
Hard Coded Map Name
Static Schema
Static Receive Port
Static Send Port
Hard Coded Map Name
Static Schema
Static Receive Port
Static Send Port
Hard Coded Map Name
Static Schema
Static Schema
All decisions are made and locked in at Design Time or at Deployment!
Change is often a re-development or a system re-configuration!
We’ve allowed the easy to use tools to define how we leverage the BizTalk features!
Static Receive Port
BizTalk Server
Hard Coded Map Name
Make reference back to Harsha’s demo – whilst it was great etc.....
As we move towards move – intelligent hub/bus, decisions around particular interface definitions (schemas, mappings, services invoked etc)
Traditional if you have built BizTalk or other enterprise integration solutions you might have taken an approach where decisions are made at design or deployment
Essentially in BizTalk 2009 ESB we are providing new capabilities to enable ‘injection’ of this type of information and meta-data to enable more dynamic scenarios
Static Schema
Static Send Port
WSDL Schema
WSDL Schema
WSDL Schema
WSDL Schema
WSDL Schema

14. Process Orchestration
BizTalk ESB – Example Scenario Declarative, Meta-data, Policy and Configuration –Driven.
Message arrives on-ramp
Itinerary resolution
Transformation determined at runtime
Routing determined at runtime
Process the message
Resolve mapping
External Services: Transform my message
Routing
Transform Service
Process Orchestration
Service Providers
On Ramp
Off Ramp
BizTalk ESB
Protocol
Adaptation
Pub/Sub Service
End Point Resolution
So rather than thinking of BizTalk in the sense of creating a procedural application, where you might think of developing sequential pathways of code or orchestrations
ESB and the patterns enabled encourage you to break-down functionality into modular units which can be driven by meta-data routing slips such as itineraries
To enable this we needed to ensure that BizTalk’s underlying capabilities themselves could also be used in a modular fashion
Routing, transformation, endpoint resolution, etc
Service Consumers
Itinerary injection
External Services: Resolve a service end point address
Resolve endpoint
Key concepts: Itineraries, Resolvers

15. Itinerary – Transform & Route
Transform using rules resolver
Runtime lookup of map
Runtime lookup of endpoint
Route using static resolver

16. BizTalk ESB Toolkit Architecture
ESB Management Portal
Provisioning Framework
Reports
Alerts
Core Web Services
Resolver Web Service
Transformation Web Service
UDDI Web Service
Exception Web Service
Operations Web Service
ESB Toolkit Core
Itinerary Services
Transform Service
Route Service
Custom Service
Exception
Management Store
Resolver-Adapter Provider Framework
Resolvers (…)
Adapter Providers(…)
BizTalk Receive Ports
Exception Management Framework
BizTalk Send Ports
Exception Logger
Fault Processor
Exception Handler
On-Ramps
Off-Ramps
Generic SOAP
Receive
Generic WCF
Generic JMS
Custom
Pipeline
Custom Pipeline
UDDI 3.0
BAM
Generic SOAP
Send
Generic WCF
Generic JMS
Custom
Pipeline
Custom Pipeline
Itinerary
Store
On-Ramps. These receive external messages, attach the appropriate itinerary for each message, and perform itinerary processing; they use the BizTalk ESB Toolkit Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
ESB Pipeline Interop Components. These provide BizTalk Server pipeline components that facilitate interoperability with external systems.
Off-ramps. These implement send ports for the delivery of messages using formats and transports such as WCF, JMS, WMQ, FTP, HTTP, Flat File, XML, or any other custom formats. They are typical BizTalk Server dynamic send ports that are direct-bound to the Message Box and optionally use the BizTalk ESB Toolkit interop pipeline components and the BizTalk ESB Toolkit Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
Itinerary-Based Routing and Processing. The Itinerary Processing mechanism provides a lightweight capability for dynamically describing, submitting, and executing multiple service invocations or routing/transformation requests. The Microsoft BizTalk ESB Toolkit implements a routing slip pattern through the use of custom pipeline components. Message metadata and other factors are used to determine the appropriate routing slip, also known as an itinerary, to be used for each message. This routing slip can perform message transformation, invoke orchestration services, and define message routing steps that Microsoft BizTalk Server will execute, effectively decoupling message processing instructions from the core BizTalk Server engine. they use the BizTalk ESB Toolkit Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
ESB Resolver and Adapter Provider Framework. This implements a pluggable and configurable architecture for dynamically resolving endpoints and transform requirements and for routing messages.
Exception Management Framework. This captures and consolidates exceptions from both BizTalk Messaging and Orchestration subsystems and provides a single mechanism for handling fault messages. It includes the exception Web service, the exception management API, and components that enrich, process, and pass exception details to the ESB Management Portal.
Core Web Services. These expose key capabilities to ESB consumers, such as itinerary-based routing, exception management, dynamic resolution of endpoints and maps, BizTalk operations, Universal Description, Discovery, and Integration (UDDI) interoperability, and transformation of message content.
ESB Management Portal. This provides support for exception and fault tracking, message resubmission, alerts and notifications, UDDI integration, reporting and analytics, and configuration capabilities.
BizTalk ESB Toolkit Message Life Cycle
An on-ramp receives the message. Depending on the submitting party or client, the message may or may not contain an itinerary that defines the processing instructions for the message.
ESB pipeline components copy the itinerary (if present in the SOAP header) into the context of the message as promoted properties. If the message is received without an itinerary, a specific pipeline component can be configured to select the appropriate itinerary from a database, depending on message content or context, and then copy the itinerary into the context of the message. For the duration of the lifetime of the message, the itinerary is maintained within the message context.
While still in the pipeline, the itinerary is evaluated and message-based itinerary services can process the message. These itinerary services may transform the message or configure routing endpoints.
The message is published to the Microsoft BizTalk Server Message Box database.
BizTalk Server evaluates the promoted properties of the message and queues the message for one or more subscribers.
The subscriber(s) process the message using typical BizTalk Server mechanisms. A subscriber can be either of the following:
A BizTalk Server orchestration with a filter configured on a direct-bound receive port
A dynamic BizTalk Server send port, which is also referred to as an ESB off-ramp. The itinerary determines how the port will be configured to continue processing the message.
As an alternative to a message arriving through an itinerary on-ramp, BizTalk Server orchestrations can also publish messages to the Message Box for ESB processing:
A message is created within a BizTalk Server orchestration.
The message's context is populated with the ESB itinerary.
The message is published through a direct-bound port
The ESB Toolkit make the use of UDDI 3.0 easier via the UDDI Resolver and ESB.UDDI.Service service.
The BRE, BRI and UDDI resolvers “encourage“ the development of dynamic solutions where services and maps are configured on BRE and UDDI repository. This increase the flexibility and manageability of the solution.
The Itinerary BAM tracking allows in a transparent manner to investigate the progress state of individual flows or collect statistics on completed itineraries.
Business Rules Engine
Transformation Engine
Orchestration Engine
BizTalk Pub/Sub Engine

17. Introduction Itinerary, Routing and Transformation
Demo
Introduction Itinerary, Routing and Transformation

18. On-Ramp – Selects itinerary

19. BizTalk ESB connected to Azure AppFabric Service Bus
Demo
BizTalk ESB connected to Azure AppFabric Service Bus

20. AppFabric Service Bus Challenges in connectivity Service Bus
Integrate on-premise ESB, apps via cloud
Bidirectional communication at Internet scope not trivial
Security
Service Bus
Federated Identity and access control
Federated Naming
Dynamic Service Registry
Robust Messaging Fabric
Bidi challenges – shortage of Ipv4 addresses. Most corporations use dynamic IPs and NAT
Security – most useful on premise apps shielded by layers of firewalls and protection
Most orgs allow variety of outbound ports, but highly constrained inbound – often 80, 443 only
Most deal with by – open inbound firewall ports, dynamic DNS, NAT port mappings, UpnP (Univ Plug & Play) – all of which are brittle, difficult to manage, open to security threats
Most popular Internet apps are bi-di eg. BitTorrent, written low-level networking logic to travers firewalls etc
Receiver connects to relay service through OB port, creates a bidi socket at a particular address
Sender sends messages to relay, the message is relayed to Receiver through bidi socket
Full access via SOAP, REST, WS-* negotiate p2p where possible

21. BizTalk Cloud - Demo Architecture
sb://biztalk-uk-conf.servicebus.windows.net/EchoService
Backend Naming, Routing Fabric
Subscribe
App Fabric
Service Bus
Route
Frontend Nodes
Msg
TCP/SSL 828
Outbound connect bi-directional socket
Outbound connect one-way net-tcp
TCP/SSL 808/828
Create a service, programmatically register endpoint with Azure AppFabric
this will create an outbound connect bidi socket
At this stage we see the endpoint registered (grey circle) essentially subscribing to messages
See endpoint in service registry, based on DNS like naming convention <project>.servicebus.windows.net/<service-name>
Create a client to connect to the service, one-way ob connection
Connect via BizTalk WCF Adapter
Echo Client
(Sender)
BizTalk ESB
Itinerary Routing, dynamically transforms and resolves endpoint
Receiver (EchoService)

22. Start the service, visible in registry
Outbound bidi connection established
Service visible in Azure Service Registry

23. Connect via Client Application
Connect via BizTalk
Transform lookup using Business rules engine
Resolve on-ramp and route
Send message to cloud

24. BizTalk Service Bus Send Port
BizTalk send port
WCF Custom Binding

25. Summary
Extend the reach of ERP and LOB applications – composite applications
More agility and flexible infrastructure with ESB approaches and patterns
Extend to cloud and off-premises with BizTalk and Azure AppFabric Service Bus
Download & enjoy 

26. 3/31/ :21 PM
© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.