Explore topic-wise InterviewSolutions in .

Correlation Context is when the mediation primitive needs to pass the value from the request flow to the response flow. Here, the correlation context plays the role of passing the value. 

Connected experiences are at the core of Mulesoft applications. Integrating data to deliver a SINGLE view of the customer, automating BUSINESS processes, and BUILDING connected experiences are all made easy through Mulesoft. Each unified part becomes a building block that is reusable through using this modern APPROACH which is API-led. The results of these are AGILITY and scale.

References and Resources

1. Mule in Action, Second Edition (O’Reilly) - By John D'Emic, David Dossot, John D'Emic, and Victor Romero
2. Hands-On Microservices - Monitoring and Testing (Packt Publishing) - By Dinesh Rajput
3. API Recipes with Mulesoft(r) Anypoint Platform - by Whishworks

The Scheduler component in Mule helps us to TRIGGER a flow when a time-based condition is met. 

The parameters related to CONFIGURING a scheduler are as follows:

• Frequency: The Scheduler USES frequency to trigger flows.
• START Delay: This signifies the time to wait before triggering a flow.
• Time Unit: This is the time unit for frequency and for Start Delay.

For example in some use cases where you NEED to do a specific task at a particular period of time or repeatedly at a fixed interval, your integration flow can be scheduled via Scheduler.

SOAP STANDS for Simple OBJECT Access Protocol. It is used to exchange structured information in the implementation of web services in COMPUTER networks. The following are the advantages of SOAP:

• For a web service to talk with the CLIENT applications, SOAP is one of the best mediums that is developed
• It is a light-weight protocol. This allows applications to pass messages and data back and forth between disparate systems easily.
• It can be used for the interchange of data between various applications.
• The SOAP protocol can work with any programming language-based applications on WINDOWS and Linux platforms.
• Web services built on the SOAP protocol do not require customization to work on the World Wide Web (WWW).

Data Integrator is a data visualization mapping tool launched by Mule. It has support for Java objects, flat files, and XML Mapping.

The Mule Data Integrator tool PROVIDES drag and drop features to make the coding process easier, as it could be a challenging task for a developer to code COMPLEX mapping functionalities. This process of mapping GETS support from eclipse to run the Data Integrator, which is part of the top layer applications in Mule Architecture. Data integration solves the problem of moving, transforming, and consolidating information from various parts of the enterprise. This enables it to undergo cleansing, standardizing, de-duplication, manipulation, and SYNCHRONIZATION between sources.

To make smart decisions on the request and response ENVIRONMENT or message delivery, filters are used. These are the most powerful CAPABILITIES given to the routers.

In order to decide what to do with the messages in the transit stage, filters give sight to the ROUTER. Some filters go through a thorough analysis of the given message to obtain the actual value of the desired output. 

The expression ‘filter’ returns either true or FALSE. If the expression returns true for a value or INDEX in the array, the value gets captured in the output array. If it returns false for a value or index in the array, that item gets filtered out of the output. If there are no matches, the output array will be empty.

Configuration patterns have been designed for EASE of use. The four configuration patterns that EXIST TODAY make things that people do all the time simple, understandable, and fast to create.

Mulesoft PROVIDES the following configuration patterns:

• Bridge
• Validator
• WS proxy
• Simple service pattern
• HTTP proxy

There are four different parts of the composed message in Mule. These are as FOLLOWS:

• Payload - This is the main context of data carried by a GIVEN message.
• Properties - Similar to the SOAP message, this contains meta-information or header
• Multiple Name ATTACHMENTS - This is used to PROVIDE support for multi-part messages.
• An exceptional payload - to hold errors that occur during the processing of the event.

The resources used for modularizing configuration in Mule are as follows:

• Independent Configuration: To load a number of independent configuration files one after the other, a mule instance is used.
• Inherited Configuration: One Configuration INHERITS a Configuration from another different configuration. This is like the name ‘inheritance’ suggests - a parent-child relationship between the 2 configurations. This ensures that no configuration file will be OMITTED booting of the application takes place. This is the guarantee that this dependency provides.

The following is an example: 

• Imported Configuration: This also supports spring configuration. This enables us to easily USE the spring config file to Mule configuration files. If we need to extend instance.xml then the spring context file will be imported:

• Heterogeneous configuration: In this type of configuration, we can utilize many types of files as the term ‘heterogeneous’ SIGNIFIES. By using the Groovy script method and Spring XML Configuration builders, we can create the instances.

Mulesoft as an integration platform offers many advantages. Following are some of them:

• It is LIGHTWEIGHT yet highly scalable. With Mulesoft, we can connect a large number of applications. For the communication to stay uninterrupted and consistent between the applications, ESB helps. Even though the protocols used for Virtual Machine are the same, building and maintaining communication between applications is allowed.
• Mulesoft can combine and connect over a large RANGE of application network
• It has integration support for CONNECTING various parts of the network.
• The components within the application are reusable. We can use pre-existing parts without having to write specific codes.
• As this is a vendor-neutral solution, many vendors can be INTEGRATED. Also, by minimizing the restrictions on vendors, the vendor dependencies are removed.
• For higher BUSINESS support, it has great adaptability to change.

A Mule transformer is used to strictly enforce the types of data it receives and its outputs. One CONFIGURATION can be used to relax this - An exception won’t be reported for bad input, but the original message will be returned without enforcing the expected result type by the transformer. Thus, this option should be used sparingly. A depiction of a Mule transformer is shown in the flowchart below. Mule has multiple transformers and each project you do might potentially have one transformer. 

There are different ways in which a transformer can alter a message:

• Payload type transformation - In this, the message payload data type is transformed from one binary form to another. As an EXAMPLE, a java.util.Map can be transformed into a javax.jms.MapMessage.
• Payload format transformation - In this, the message payload data format is transformed from one form to another. As an example, a byte array that has an XML document instance is transformed into a byte array that has a plain-text instance for logging.
• Properties transformation - In this, the properties of the message are changed. This could be done by either adding, modifying or REMOVING existing properties. As an example, a message that requires a given property to be set PRIOR to being sent to a JMS destination.

Usually, transformers come in pairs. In these pairs, the second transformer cannot perform what the first one performs. 

As an example, the payload format transformations such as compression and decompression, are handled by 2 different transformers. One of these transformers is able to reverse the action of the other one. This is what is called a round-trip transformer. The original message should be restituted by making a message go through a transformer and its round-trip. 

Using the flow-reference element of MULE, we can call a subflow. When the sublow is called using a flow-reference element by the main flow, the entire message structure (ATTACHMENTS, payload, properties, etc.) is passed ALONG with the context (transactions, SESSION, etc.) Similarly, the entire message along with the context is returned to the main calling flow after the processing of the message is done in the subflow. 

FOLLOWING are some features of Subflow:

• Subflows are very useful when you want to add re-usable logic, as you can call sub-flows multiple times.
• Referring subflows gives better performance than referring a flow.
• Subflows don’t have event sources. 

‘Flow’ is when we combine together multiple individual processors in order to handle a receipt, its processing and eventual ROUTING of a message. We can connect several flows together to build one whole application. This application can then be DEPLOYED on Mule, on-premise, or another app server, or also on the cloud.

Simply PUT, the sequences of the message processors are called flows. A message entering a flow can pass through a LARGE variety of processors. In the figure shown below, after receiving the message through a request-response INBOUND endpoint, Mule then transforms the content into a new format. The business logic is then processed in a component before returning a response through the message source.