1 / 22

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

IMPLEMENTING A SERVICE BUS ARCHITECTURE WITH BIZTALK 2009 AND THE ESB TOOLKIT 2.0. A Case Study. Agenda. Business Scenario Solution Overview Creating the Itineraries Implementing Exception Management Demo Questions?. Business scenario.

freya
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Business Scenario • Solution Overview • Creating the Itineraries • Implementing Exception Management • Demo • Questions?

  3. Business 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. 

  4. Solution overview Map to Canonical Batch Schema Custom Pipelines & Pipeline Components • MAPPING Flat Files Validate/Debatch • ------------------------------------------------------ • ------------------------------------------------------ Debatched Shipment Messages • Orchestration • MAPPING • ------------------------------------------------------------------------------------------------------ • ------------------------------------------------------------------------------------------------------ • Custom Pipeline • ------------------------------------------------------------------------------------------------------ • ------------------------------------------------------ • ------------------------------------------------------ • MAPPING • Custom Pipeline • ------------------------------------------------------ • ------------------------------------------------------ Service Providers On Ramp Off Ramp Itinerary BRI Resolver • Custom Pipeline

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

  6. 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

  7. Phase two: Debatching • Once received in the canonical format, the batch message is passed through an orchestration which performs two functions: • Data is validated to ensure completeness. • 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.

  8. 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

  9. 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.

  10. Creating the itinerary

  11. Esb.config

  12. Assign the itinerary The easiest way is to use the ItinerarySelectReceive Pipelines that come with the ESB Toolkit.

  13. “Wire up” the itinerary

  14. Capture and Advance the Itinerary

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

  16. 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.

  17. Creating fault messages Create a multi-part message type

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

  19. 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.

  20. demo

  21. Thank you! Contact info Email: ed.jones@rbaconsulting.com Web: http://www.rbaconsulting.com Blog: http://talentedmonkeys.wordpress.com

  22. Go wild!

More Related