Business events information can include transaction execution time, errors, and results (successful completion or failure), and message payload information, which you can customize using Mule Expression Language (MEL).
via谷歌翻译：Business Events信息可以包括事务执行时间，错误和结果（成功或失败）以及消息有效负载信息，可以使用Mule表达式语言（MEL）自定义信息。
Mule makes it possible to set up custom events to capture specific payload information for later tracking and analysis at runtime. Also, some default events are automatically generated by Mule servers. For MMC users, to track and analyze default events at runtime, you must first enable event tracking in your application.
via谷歌翻译：Mule可以设置自定义事件来捕获特定的有效负载信息，以便在运行时进行后续跟踪和分析。另外，一些默认事件是由Mule服务器自动生成的。对于MMC用户，要在运行时跟踪和分析默认事件，必须先在应用程序中启用事件跟踪。
官网对于Business Events的使用说明主要分为了四个地方：
（1）使用Insight来过滤和分析Business Events（这个是Cloudhub用的）
（2）通过MMC的Business Events标签页来分析Business Events
（3）通过MMC的Business Events标签页来查询和过滤transactions和events
（4）MMC的Business Events跟踪用例
官网提示需要理解的专业名词 
官网对于transactions的解释为，相关事件的逻辑分组，通常对应为系统的Business View，还说transaction map to flow。而对于events的解释相对容易理解，解释为events是transactionslow-level的细节，这里的low-level应该指较底层的细节，而不是低级的意思。event可以是消息处理器，连接器，也可以是异常或者自定义event。所有events，除了自定义events外，其它均为默认events。
Batch Processing不支持使用Business Events
在Mule中有两种途径可以配置Business Events Tracking
（1）企业版中，在flow的指定位置配置自定义的Business Events，AnypointStudio中 
（2）对flow或者flow中指定的消息处理器/连接器启用默认的事件跟踪功能
Default event tracking is supported by all connectors and selected message processors. Enabling default events for these elements allows you to perform advanced debugging at runtime.
via谷歌翻译：所有连接器和选定的消息处理器都支持默认事件跟踪。为这些元素启用默认事件允许您在运行时执行高级调试。（这里本人测试，可开启tracking的组件实际并不多，如果有可视化配置上会有一个可勾选框） 
Message processor or connector level configuration takes precedence over flow level configuration.
via谷歌翻译：消息处理器或连接器级别配置优先于flow级别配置。
如果是在flow里面使用Custom Business Event组件，则需要定义一系列键值对用于获取你所感兴趣的event信息，而这些键值对的定义十分灵活，使用的是MEL表达式或是你所指定的值。 官网给出的例子 
如果你在flow级别的设置中勾选了Enable default events tracking，则该flow中所有的支持tracking的processor都会开启这个功能，如果对于某个processor想要禁用，则可以在其XML配置中使用tracking:enable-default-events="false"来覆盖flow级别的配置。
Business Events Tab页一览 
为了较为完整测试这个Business Event实际作用，本人编写了一个简单的模拟订单号创建的Demo，在flow中设置了一个Custom Business Event。成功显示订单信息，失败抛出异常，并且记录message_id。 flow结构图 
访问Demo，页面提示出现异常 
此时这个Demo中处理异常时所记录下来的message_id就十分重要了，因为根据它可以在Business Event Tab里面查找对应的记录。
MMC根据message_id查询business event 
可以看到状态那里提示失败，并且business event记录里面有处理时间等相关信息，点击该记录还能看到详细细节。
点击记录后页面效果 
可以看到记录行里面共有四个event记录行，其中event为Custom Business Event显示的Result对应着在flow设置时候的MEL配置。 Custom Business Event配置 
每一个event基本有其对应的处理时间以及其处理结果，如果有异常则可以点击查看异常信息。可以看到除了我自定义的event之外，其余event类型均为default。
上述例子使用的是异常处理时记录的message_id，模拟的场景是客户点击订单提交后，出现异常返回一个标识给用户供向客服查询相关订单信息为何失败。通过Business Event能够直观得知到该次处理过程中的失败所在，看上去如果只是针对错误提示，那么感觉貌似之前的Alert也是能做到相关提示错误，但是需要注意的是，实际上Business Event和Alert还是有其很大的不同之处。在该例子中，我也定义了一个alert警报，用于订单创建失败时候提示管理员（其实这里也可以看出两者的不一样，实际场景中了一个订单创建失败了从而发警报给管理员？），而在Alert中，其提示是类似下图所示： 
尽管两者提示的异常信息一致，但相较于Business Event来说，Alert的提示就显得有些简陋，只能给出大体的错误（这也因为Alert关注点并不是异常的记录）。而Mule企业版提供的Custom Business Event组件能够让我们提前在流程的关键节点植入，并且失败后在MMC获取该节点所记录的信息，供排查问题使用，也能够细节到每个event(message processor)处理的时间，供流程处理时间优化提供数据。Flow Analyzer能够获取到整个流程的处理时间，但并不能获取到Business Event这么细化的信息，同时Flow Analyzer的监听是有时间限制的（除非设置为无限制），Flow Analyzer更多地作为在运行时辅助开发调试的手段，而我个人感觉Business Event更多地偏向项目部署到生产环境后排查问题使用。当然，这个排查的好坏更多地取决于在开发过程中所植入的自定义组价是否获取到足够敏感的信息供使用。
或许在以后更多地使用中能够更好地理解Business Event…… 如果使用application name作为查询条件，应当最为方便，毕竟名字都是自己起的 