Beyond the POC: Adopting NServiceBus
Download as PPTX, PDF0 likes863 views
The document discusses a case study of a regional grocery retailer's adoption of NServiceBus (NSB) to optimize order management and supply chain processes, addressing challenges such as batch job limitations and high throughput demands. The solution involved decomposing orders and enhancing mobile and backend integration through a robust asynchronous messaging architecture. Key takeaways emphasize the importance of leveraging existing business processes and the efficiency achieved by implementing NSB.
Beyond the POC: Adopting NServiceBus
- 1. Beyond the POC Adopting NServiceBus
- 2. Introduction Adam Fyles Solution Architect Using NSB since v1.9 NServiceBus Champ Upstate NY, US Contact Info adamfyles.blogspot.com afyles@gmail.com
- 3. The tablescape Regional Grocery Retailer - Wine & Spirits - Restaurants 90+ Stores in 6 states Millions of customers Medium to large IT department (~250) Extremely high volume stores
- 4. Let me in! Lots of competitive products, why do we need another one? Batch jobs work just fine! Lack of SOA understanding Operations used to FTP
- 5. The progression Pub/Sub Sagas Point to Point Load Balancing
- 6. Load Balancing: OMS Determines how to best source product in the supply chain based on demand Inherently batch based due to wave planning in either WMS or MFG Requires massive throughput (by order line item) in a tight window No commercial system could do it without heavy custom configuration and a ridiculous amount of hardware Team was experienced PowerBuilder developers
- 7. Solution Solution was to decompose orders and optimize by distribution “network” Run aggregate demand through with the Distributor Distributor Worker 1 Worker 2 DB WMS Transportation Publish Orders Order Entry Order Entry Order Entry
- 9. Master Data Forecasted Orders Store Supply Chain Proliferation Corporate Purchased WMS Integration Endpoint HTTP DataBus Purchased CAO Other Systems
- 11. Takeaways… Replaying messages!! Required more DevOps MSDTC Tricks Stay inside the stack
- 12. Point 2 Point: Mobile Built an entire REST API around all of our Marketing tools Products Recipes Shopping Lists Online Ordering Search Ratings and Reviews It must be fast and durable!
- 13. Request/Response is not an option
- 14. Mobile Solution Solution was point to point integration to backend systems of record Flaky DB Mobile API View Model Reads Writes Web 3rd Party Writes NSB
- 15. Customer Facing Proliferation API Reads RX Portal Offisite Vendor RX System Writes NSB Writes Customer Care RX Service Desk
- 16. Custom Fault Manager Demo
- 17. Takeaways… Asynchronous performs well Messaging trumps fragile backends Leverage local resources
- 18. Pub/Sub: Pricing Legacy Mainframe System Lots of price changes Wide Distribution Network All Stores – POS, Scales, Signs Online – Web, mobile, email
- 19. Legacy Integration Find the weak point where you can enter the host
- 20. Solution DB Publisher Mobile Email Web Signs Scales POS Mainframe CDC
- 21. Workflow: Benefits Registration Series of questions Plan selection Open window of opportunity
- 22. Solution Step 1 Step 2 Step 3 SharePoint Site NServiceBus Saga Storage Reporting Metrics
- 23. Takeaways… Don’t reinvent the wheel Focus on business process
- 24. Sum it up!
- 25. Efficiency
- 26. Focus
Editor's Notes
- #5: Talk about how we had to unexpectedly sell the concept of an ESB (an open source one at that) all the way to the CIO What did it? Simplicity, standards. Development first - .NET. Very batch, procedural mindset had to be overcome Painful integration .NET Shop Training
- #6: We’ve had a somewhat “backwards” progression through the platform My guess it would be typical to start with P2P -> Workflow -> Pub/Sub -> Load Balancing -> Workflow + Pub/Sub
- #8: Talk about any tweaks we made like clustering services, where MSDTC was positioned We reached a cap on the number of workers due to database constraints
- #13: We have very unstable storage for shopping lists
- #14: If we had done Request/Response everything would have come to a halt with load We also would not have done well with the flaky system of record
- #15: Having local resources allowed us to separate reads from writes (NOT FULL CQRS)
- #20: Expose endpoint as web service Detect database changes Wire tap existing messaging infrastructure
- #21: Email Marketing Web Site Mobile Apps Consumer Affairs
- #26: Platform allows for the logical division of work Cleans up monolithic code
- #27: Platform takes care of the mechanics so you can focus on business process