LibraryLink ToToggle FramesPrintFeedback

The Major Widgets Use Case

Throughout this and the other Fuse Product Introduction guides, we use an imaginary business scenario—Major Widgets, an auto parts supplier for several local auto repair shops—to demonstrate how each Fuse product can work with the others to solve an integration problem.

When Major Widgets, a single Mom and Pop operation that ran an auto parts supply store, decided to buy three more auto part supply stores, they knew they'd have to change their business model and integrate the systems located in all four stores.

Major Widgets, and each of the three stores it bought, routinely supply a number of auto repair shops that are located near them. Each store delivers parts to customers free-of-charge, as long as the customer is located within twenty-five miles of the store. Each store has its own databases for storing auto repair customer accounts, store inventory, and part suppliers.

Business was done over the phone, but now Major Widgets has implemented an online Web order service to coordinate orders and deliveries, bill customers, track and update each store's inventory, and order parts from suppliers.

All four stores also sell parts over-the-counter to walk-in customers, for whom they do not establish customer accounts.

Figure 1.2 shows a high-level view of how Fuse Mediation Router might fit together with Fuse ESB, Fuse Message Broker, and Fuse Service Framework to provide an integration solution for Major Widgets.


According to this plan, the order entry frontend, consisting of Fuse Mediation Router and Fuse Message Broker running within Fuse ESB, will run on the local computer system at Major Widgets main store (A). At each of the four stores (A-D), the order entry backend, consisting of Fuse Mediation Router and the store's order processing engine, will run on the local computer system.

Online orders entering the order entry frontend will be routed to the store nearest the submitted zip code. From there they will enter the order entry backend, which will determine whether the item is available and process the order accordingly.

Figure 1.3 shows how the Major Widgets integration plan might be implemented. Specifically, it details how Fuse Mediation Router (FMR) could be configured to route orders received from regular auto repair shop customers over the internet and from walk-in customers who purchase parts over-the-counter at any of the four stores.


[Note]Note

The encircled numbers in Figure 1.3 serve as reference points for concepts presented throughout this guide.

For example, (1) in the text references encircled number in this figure.

At Major Widgets main store (A), the order entry frontend (FMR and FMB running within FESB) is running on that store's computer system. At each of the four stores (A-D), an instance of the order entry backend (FMR and backend processing) is running on the local computer system.

When the frontend web service (3) receives an online order, Fuse Mediation Router passes it to a content-based router (4) to determine which store to route the part order for further processing. The order then enters the target store's queue (7), where it waits until the target store retrieves it (8).

In the case of auto repair shops (1), the content-based router routes order requests to the store nearest the customer, based on the submitted zip code. In the case of walk-in customers (2), the auto supply store submits its own zip code to the frontend, so the order is always routed to the local store.

When the backend receives the submitted part order (8), Fuse Mediation Router employs a dynamic router (9) to look up the parts in the store's database to see if they are in stock. Results depend on whether the customer is an auto repair shop or a walk-in:

  • Auto repair shop customers

    If the parts are available, the order is submitted (10) to the store's backend processing software (11), which informs and bills the customer (1), schedules delivery, updates inventory, and reorders parts accordingly.

    If the parts are unavailable, the order is submitted to a processor (12) that generates an error message, which is emailed (13) to the customer (1).

  • Walk-in customers

    If the parts are available, the order is submitted (10) to the store's backend processing software (11), which informs the store clerk (2), updates inventory, and orders parts accordingly. The store clerk retrieves the parts from stock and sells them to the customer over-the-counter.

    If the parts are unavailable, the order is submitted to a processor (12) that generates an error message, which is emailed (13) to the local store's email account (2). The store clerk informs the customer, who can then decide whether he wants the store clerk to search the other stores for his parts.

[Tip]Tip

Both the content-based router and the dynamic router are EIP patterns supported by Fuse Mediation Router.