Business Events Use Cases
| Note to reviewers: This is a new page that will appear in the Management Console Documentation as a child page below the Analyzing Business Events topic. |
The Business Events tab on the management console gives you visibility into business transactions and events on your Mule servers, allowing you to track and analyze the flow and disposition of particular messages. For example, you can use the data to do root cause analysis on a failure within a business transaction or identify message processing bottlenecks.
This page illustrates some examples of using the Business Events tab to meet specific needs.
Root Cause Analysis Example
Assume that a business, let’s call it ShopMuley, runs a Mule application that handles orders from customers. The processing flow within the application looks like this:
The key parts of the application are as follows:
-
An order is received from a customer and then processed.
-
A discount is applied (if appropriate for the customer).
-
Further processing is done asynchronously.
-
A Salesforce contract is created.
-
Depending on the items ordered, the order is sent to either Sony or Logitech for fulfillment.
Now let’s suppose a customer calls ShopMuley’s support department and reports that he didn’t receive the items requested in purchase order 47625. The support department can use the Business Events tab to do a root cause analysis of the issue. Assume that the application has been set up to track events in the order fulfillment flow. Here is a code snippet that highlights the tracking-related specifications for the flow.
<flow name="Fulfillment Flow" doc:name="Fulfillment"> ❶
<http:inbound-endpoint host="localhost" port="1080" ...
tracking:enable-default-events="true" doc:name="Receive Order"
doc:description="Process HTTP requests or responses."/> ❷
...
<tracking:transaction id="#[groovy:payload.orderId]" /> ❸
<component doc:name="Calculate Discount"... >
<async doc:name="Async"
doc:description="Asynchronous block of execution">...</async>
</flow>❶ The name that will be displayed for the flow (Fulfillment) is specified in the doc:name attribute.
❷ Tracking is enabled for the default event, whose name will be displayed as Receive Order. Notice that display names have been specified for all of the default events in the flow.
❸ The transaction Id is customized. The Id column in the search results will display the order ID pertinent to the transaction.
These specifications enable the support department to search for transactions by order ID, view the events generated for the flow in a transaction, and see meaningful names displayed for the flow and events.
This makes it easy to search for a transaction whose order ID is 47625.
Clicking on the transaction whose Id is 47625, displays data for the events generated in the flow.
It appears that the order was successfully received from the customer, but the transaction failed before the order was shipped to Logitech for fulfillment. Perhaps a recent change in the code has caused the problem. The support staff will now focus on that part of the code to isolate and fix the problem.
Compliance Testing Example
In addition to doing root cause analysis, the Business Event tab is useful in many other ways. For example, you can take advantage of it to do compliance testing. Suppose the staff at ShopMuley wants to ensure that its discount is properly applied based on the discount tier level of the customer. To do that they can define "before" and "after" custom events that track the price of an item before and after the discount is applied. Here is what the custom events might look like in the Fulfillment Flow.
<flow name="Fulfillment Flow" doc:name="Fulfillment">
<http:inbound-endpoint host="localhost"
port="1080" ... tracking:enable-default-events="true"
doc:name="Receive Order"
doc:description="Process HTTP requests or responses."/>
...
<tracking:transaction id="#[groovy:payload.orderId]" />
<tracking:custom-event event-name="Price"> ❶
<tracking:meta-data key="price" value="#[groovy:payload.price]" />
<tracking:meta-data key="customer-tier" value="#[groovy:payload.customer-tier]" /> </tracking:custom-event>
<component doc:name="Calculate Discount" ... >
<tracking:custom-event event-name="Price After Discount"> ❷
<tracking:meta-data key="price-after-discount" value="#[groovy:payload.price]" />
<tracking:meta-data key="customer-tier" value="#[groovy:payload.customer-tier]" /> </tracking:custom-event>
<async doc:name="Async" doc:description="Asynchronous block of execution"> ... </async>
</flow>❶ This is the "before" custom event. It tracks the price of the item before the discount is applied, as well as the discount tier level of the customer. ❷ This is the "after" custom event. It tracks the price of the item after the discount is applied as well as the discount tier level of the customer.
After a transaction is run, the staff can view the data for the "before" event (listed here as "Price") to see the customer’s discount tier as well as the price before the discount is applied. And they can view the data for the "after" event (listed here as "Price After Discount") to see the price after the discount is applied.
Yet another use for the Business Events tab is in bottleneck detection. In this case, you can search the displayed data for events that consistently take a long time to process.