22
IMPLEMENTING A SERVICE BUS IMPLEMENTING A SERVICE BUS ARCHITECTURE WITH BIZTALK 2009 ARCHITECTURE WITH BIZTALK 2009 AND THE ESB TOOLKIT 2.0 AND THE ESB TOOLKIT 2.0 A Case Study

IMPLEMENTING A SERVICE BUS ARCHITECTURE WITH BIZTALK 2009 AND THE ESB TOOLKIT 2.0 A Case Study

Embed Size (px)

Citation preview

IMPLEMENTING A SERVICE BUS IMPLEMENTING A SERVICE BUS ARCHITECTURE WITH BIZTALK ARCHITECTURE WITH BIZTALK 2009 AND THE ESB TOOLKIT 2.02009 AND THE ESB TOOLKIT 2.0

A Case Study

AGENDAAGENDA

• Business Scenario

• Solution Overview

• Creating the Itineraries

• Implementing Exception Management

• Demo

• Questions?

BUSINESS SCENARIOBUSINESS SCENARIO

Client required a system that would accept incoming shipment data in the form of flat-files in multiple formats, process that data through a series of resolutions, and then output the data in both its raw and processed forms into an ERP system. 

While most data will be processed, some will be ignored. 

Over time it is expected that the various processes may change in size, scope, and sequential order. 

SOLUTION OVERVIEWSOLUTION OVERVIEW

• Custom Pipeline

• Custom Pipeline

• Custom Pipeline

------------------------------------------------------

------------------------------------------------------

------------------------------------------------------

------------------------------------------------------

------------------------------------------------------

------------------------------------------------------

Flat Files

Custom Pipelines & Pipeline Components

Map to Canonical Batch Schema

Validate/Debatch

------------------------------------------------------------------------------------------------------

Debatched Shipment Messages

BRI ResolverBRI Resolver

Service ProvidersService Providers

On RampOn Ramp Off RampOff RampItineraryItinerary

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

Translate Customer Translate Product

Process Shipments

Ignore Shipments

ERP System

File System

Un-translated Data

---------------------------------------------------------------------------

---

------------------------------------------------------------------------------------------------------

Translate Distributor

Type A

Type B

PHASE ONE: INCOMING DATAPHASE ONE: INCOMING DATA

• Data is received in the form of FTP/File Drops by business partners in multiple flat-file formats.– Challenges: some of the incoming files were in

formats that were not easily translated using the standard BizTalk flat-file tools.

– Used Custom Pipeline components to build an Xml Disassembler to manage the problematic formats.

• Data was then mapped to a canonical “Batch” schema

PHASE TWO: DEBATCHINGPHASE TWO: DEBATCHING

• Once received in the canonical format, the batch message is passed through an orchestration which performs two functions:1. Data is validated to ensure completeness.

2. Message is “de-batched” into individual shipment messages

• Shipment messages are dropped to the message box, after which they are assigned an itinerary and processed individually.

PHASE THREE: ASSIGNING AN PHASE THREE: ASSIGNING AN ITINERARYITINERARY

• Messages are assigned their appropriate itinerary based on shipment type and message type.– Type A will be processed and sent to the ERP

system– Type B will not be processed and is written

directly to a file location.

• Itinerary is determined by using the BRI resolver

PHASE FOUR: EXECUTING THE PHASE FOUR: EXECUTING THE ITINERARYITINERARY• Each shipment message is processed through a

number of “Resolutions” which in the end will allow the data to be placed into an ERP system

• The resolutions use a combination of database lookups and Business Rules Engine calls to determine validity and translate the data into a usable ERP format.

• Exception Management is used throughout all phases.

• Users are given, via the ESB portal, the ability to repair and resubmit failed messages. Repaired messages are re-run through their itineraries.

CREATING THE ITINERARYCREATING THE ITINERARY

ESB.CONFIGESB.CONFIG

ASSIGN THE ITINERARYASSIGN THE ITINERARY

• The easiest way is to use the ItinerarySelectReceive Pipelines that come with the ESB Toolkit.

““WIRE UP” THE ITINERARYWIRE UP” THE ITINERARY

Capture and Advance the Itinerary

Promote the necessary properties by creating correlation sets and assigning them to the final send shape.

EXCEPTION MANAGEMENTEXCEPTION MANAGEMENT

• We implemented exception management throughout all processes.

• We captured “Rules” exceptions as well as “System” exceptions.

• All exceptions were routed to the ESB Exception Management database via the “out-of-the-box” messaging solutions.

CREATING FAULT MESSAGESCREATING FAULT MESSAGES

Create a multi-part message type

Create an instance of the fault message, set its properties, and send through a Direct-Bound Port

ESB.PORTALESB.PORTAL• Exception Management Portal allowed us

to view exceptions and repair and resubmit messages.

• Challenges:– There is a bug in which all messages that do

not have an xml declaration are classified as plain text.

– ESB.Portal has limited resubmit capabilities out of the box—you will probably want to make code changes to the ESB.Portal website.

DEMODEMO

THANK YOU!THANK YOU!

Contact info• Email: [email protected]• Web: http://www.rbaconsulting.com• Blog: http://talentedmonkeys.wordpress.com

GO WILD!GO WILD!