ERP/LOB, ESB and Azure AppFabric Integration 3/31/2017 10: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.

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

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

The Changing Landscape Application Domain 3/31/2017 10: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.

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

Composite Applications Office Business Applications

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

Customer Example – NHS CUI

And now..

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: jejohns@microsoft.com 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

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

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

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

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

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

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

Introduction Itinerary, Routing and Transformation Demo Introduction Itinerary, Routing and Transformation

On-Ramp – Selects itinerary

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

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

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)

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

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

BizTalk Service Bus Send Port BizTalk send port WCF Custom Binding

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 

3/31/2017 10: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.