eG Help

Mule applications are created to perform system integrations. Typically, the application reads data from internal and external sources, processes and transforms data to the required formats or structures, and writes that output to the systems and servers where you store or use the transformed data. Mule applications are configured to run in Mule runtime engine (Mule). A request to a Mule application triggers Mule to encode the request and data in a Mule event and to pass it to either single or multiple threads. Mule apps process messages and other parts of Mule events through Mule components, connectors, and modules that are set up within the scope of Flow and Subflow components within an app. At the simplest level, flows are sequences of processors. A message that enters a flow can pass through a variety of processors. In a typical flow, a Mule application receives a message through a source (such as an HTTP Listener component), transforms that message into a new format, and processes any business logic before writing the processed message to an external system in a format that the system can read.

Any exception that occurs during the message processing through a Mule flow can hinder the normal flow execution and thereby cause failure of user requests. If the number of failed requests are left unnoticed it can lead to critical errors and hence affect the smooth running of your application. Any unexpected surge in incoming traffic or high average processing time of events can lead to bottleneck conditions that adversely affects the message processing capability of the application. Hence it is very crucial to identify and resolve such discrepancies way before it affects the availability or performance of the Mule applications.

This test auto-discovers each Mule flow in every application deployed on the Mule ESB and reports the number of fatal errors and execution errors. In addition, this test also points to the average processing time, processed events, synchronous and asynchronous events received by each application. This way, the test helps you to proactively identify any error conditions or processing bottlenecks and problematic or error-prone Mule flows before it degrades the user experience.

Outputs of the test : One set of results for each application:flow on the target Mule ESB being monitored.

Measurement	Description	Measurement Unit	Interpretation
ExeError	Indicates the number of execution errors occurred in this flow on this application.	Number	A low value is desired for this measure. This error occurs when there is any exception during the processing of message through a Mule flow and this in turn causes normal flow execution stops. Execution errors may cause failure of user requests. Compare the value of this measure across Mule flows to isolate the flows that are error-prone. For the Summary descriptor, this measure reports the number of execution errors occurred across all the flows in the application.
FatalError	Indicates the number of erroneous/failed requests occurred in this flow on this application.	Number	A low value is desired for this measure. Fatal errors are very critical and can affect the performance of the application. Compare the value of this measure across Mule flows to isolate the flows that are error-prone. For the Summary descriptor, this measure reports the number of fatal errors occurred across all the flows in the application.
ProcEvent	Indicates the number of events processed by this flow on this application.	Number	This measure helps to analyze the incoming traffic to your application. Mule collects events information for the flows and message processors to handle the business transactions. For the Summary descriptor, this measure reports the number of events processed across all the flows in the application.
TotProcessTime	Indicates the average time taken to process any event by this flow on this application.	Seconds	A low value is desired for this measure. A high value indicates that the flow is taking more time to process events and hence is an indication of bottleneck conditions. Compare the value of this measure across Mule flows to isolate the flows that were taking too long to process events. For the Summary descriptor, this measure reports the average time taken to process events across all the flows in the application.
SyncEventRec	Indicates the number of messages processed synchronously by this flow on this application.	Number	Synchronous type of flow processes messages along a single thread, which is ideally suited to transactional processing. Compare the value of this measure across Mule flows to isolate the flows that were taking too long to process events. For the Summary descriptor, this measure reports the number of messages processed synchronously across all the flows in the application.
TotEventRec	Indicates the total number of events received by this flow on this application.	Number	For the Summary descriptor, this measure reports the total number of events received across all the flows in the application.
AsynEventRec	Indicates the number of messages processed asynchronously by this flow on this application.	Number	Asynchronous type of flow processes messages along multiple threads. For the Summary descriptor, this measure reports the number of messages processed asynchronously across all the flows in the application.