Mule Applications Test

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.

Target of the test : A Mule ESB

Agent deploying the test : An internal/remote agent

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

First-level Descriptor: Mule Application

Second-level Descriptor: Mule Flow

Configurable parameters for the test

Parameters	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Port	The port number at which the specified host listens.
JMX Remote Port	To collect metrics from a Mule ESB, the eG agent monitoring that server should be configured to use JMX to connect to the JRE used by the server and pull out the metrics of interest. Here, specify the port at which the jmx listens for requests from remote hosts. Ensure that you specify the same port that you configured in the ${MULE_HOME}/conf/wrapper.conf of the target application For more details, refer to Pre-requisites for Monitoring the Mule ESB
JMX User, JMX Password, and Confirm Password	By default, the JMX connector on the Mule ESB requires no authentication and security, in that case set the JMX User and JMX Password parameters as none. If the JMX connector on the Mule ESB requires both authentication and security, then to enable the eG agent to use JMX, you need to configure the agent with the credentials of a user who is authorized to use JMX and has read only privileges. You can hence configure the JMX User and JMX Password parameters with the credentials of a user with monitor role given in jmxremote.password and jmxremote.access files. To know the credentials of such a user, refer to Pre-requisites for Monitoring the Mule ESB Confirm the JMX Password you specify by retyping that password in the Confirm Password text box.
JNDIName	The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same.
JMX Provider	This test uses a JMX Provider to access the MBean attributes of the Mule ESB and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol.
Timeout	Specify the duration (in seconds) for which this test should wait for a response from the Mule ESB. If there is no response from the server beyond the configured duration, the test will timeout. By default, this is set to 1000 seconds.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Execution errors	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.
Fatal errors	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.
Processed events	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.
Average processing time	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.
Synchronous events received	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. For the Summary descriptor, this measure reports the number of messages processed synchronously across all the flows in the application.
Total events received	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.
Asynchronous events received	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.