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

IMPLEMENTING A SERVICE BUS ARCHITECTURE WITH BIZTALK 2009 AND THE ESB TOOLKIT 2.0 Presenter: Ed Jones, RBA Consulting CHS Team: Management: Darin Hawley Anoop Abraham Tom Green Technical: Jeffrey Dreke Steve Krueger

AGENDA Business Scenario Solution Overview Creating the Itineraries Implementing Exception Management Demo Questions?

BUSINESS SCENARIO CHS 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 OVERVIEW Custom Pipeline Flat Files Custom Pipelines & Pipeline Components Map to Canonical Batch Schema Validate/Debatch Debatched Shipment Messages BRI Resolver Service Providers On Ramp Off Ramp Itinerary

Translate Customer Translate Product Process Shipments Ignore Shipments ERP System File System Un-translated Data Translate Distributor Type A Type B

PHASE 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: 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 ITINERARY 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 ITINERARY 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 ITINERARY

ESB.CONFIG

ASSIGN THE ITINERARY The easiest way is to use the ItinerarySelectReceive Pipelines that come with the ESB Toolkit.

“WIRE 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 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 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.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.

DEMO

THANK YOU! Contact info Web: Blog:

GO WILD!