Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

Understanding the Logical Data Flow

The previous sections introduced each of the parts of the Mule ESB instance from a conceptual view point. Now, using the invoice example again, let’s take a look at how data flows logically through each part of a Mule instance. Throughout the process, Mule uses the Mule configuration file to determine which components, routers, transports, and transformers to use along the way. The diagram that follows illustrates these steps.

Understanding+the+Logical+Data+Flow

  1. The customer places an order on the company web site, and an invoice is created as an XML form and submitted to http://myfirm.com/orders.

  2. The HTTP transport receives the XML invoice and wraps it in a Mule message. The Customer Data flow’s inbound endpoint is set to http://myfirm.com/orders,  so the HTTP transport dispatches the message to the service.

  3. The XML to Object transformer converts the XML invoice into a Java object.

  4. The flow passes the message with its transformed payload to the Customer Data component.

  5. The Customer Data component queries the master customer database to pull additional data about the customer and updates the invoice with the data.

  6. What follows in the flow is an HTTP outbound endpoint, so the HTTP transport determines that it must now dispatch the message to its address, http://myfirm.com/verify.

  7. The HTTP transport uses the configuration of the Inventory Verification flow to receive the message and pass it to the Inventory Verification component.

  8. This component updates the invoice with an ID code of the warehouse that has all the items on the invoice in stock.

  9. The outbound endpoint specifies a JMS address, so the JMS transport dispatches the message to the order fulfillment application, which picks up orders on that address.