DEV Community: WB

Hello Mule (MUnit)

WB — Wed, 27 Dec 2023 17:05:19 +0000

In the previous post, we implemented a mule application that read a file from an inbox directory, processed its content and moved the file into an outbox directory.
In this post, we are going to write a unit test for that integration. Let's go!

Right click on the helloworld project and select new MUnit Test.
Select the flow that you are trying to unittest, set a name for the unit test and press Finish

Now you have an empty Unit Test for your flow that we are going to implement.

What can we test in this flow? Our application performs 3 main tasks:

Read the file from the inbox directory
Process the file content
Move the file into the outbox directory

By testing task 2, we are effectively also testing task 1. After that, we can check that the file has effectively been moved into the outbox directory.
But before we get to writing the unit test, we need to modify the flow from the previous post. We had hardcoded the inbox path into the flow, which makes testing not flexible. We do not want to use the same path at runtime and at test time.
Let's create a global config and externalize the working directories.
Go back to the helloworld-flow and select the Global Elements tab

Edit the file_Config configuration and replace the hardcoded working directory path with the followingn placeholder parameter: ${file.helloworld.inboxDir}

Right click on src/main/resources and select new file. Give it the name config.yaml
Enter the lines:

file:
  helloworld:
    inboxDir: C:/dev/Mulesoft/tutorial

and save the file.

We need to tell Mule to read the newly created file to find the configured placeholder. We do this by creating a "Global configuration properties".
Go back to the tab Global Elements and click the Create button.
Under "Global configurations", select Configuration properties,

Press Ok and enter the name of the configuration file you created config.yaml

With that, we have externalized the path of the working directory and can use a different path in the unit test by using another property file only for the test. This is what we are going to do next:
Right Click src/test/resources and create a new File. Give it the name test-config.yaml.
In that file enter the following lines:

file:
  helloworld:
    inboxDir: src/test/resources/tutorial

This is going to be the working directory for our unit test.
In the Global Elements Tab of our unit test, add a new Configuration properties and set the file name to test-config.yaml. This way, MUnit is going to resolve placeholder properties by looking into that file.
To activate the file connector during test,
enter the following snippet under the <munit:test> tag in the configuration xml

      <munit:enable-flow-sources>
           <munit:enable-flow-source value="hello-worldFlow"/>
         </munit:enable-flow-sources>

or you can use the General Properties Tab of the test suite:

Here we enable the file connector, so that it can start polling the inbox directory during the unit test.
Now you can run your unit test. When it's done, you will get an error, because the directory tutorial is missing. Create 3 new directories tutorial, tutorial/inbox, tutorial/outbox

Now run you unit test and you will have a green line.
Sadly, we haven't really testes anything yet. We have just made sure that your testing environment is setup correclty.

Now we need to drop a file with a content into the inbox directory, and check the content in our unit test to make sure that the processor is working fine.
Let's configure a validation by adding an assertion to check the content of the file from tin inbox directory. We want to drop a file with the content "Hello World" in that directory.

Here we assert that the payload is equals to "Hello World". We have also added a logger in the unit test to be able to read the message in the console.
If you run this test, it will fail. Since we have enabled the file connector in the unit test, it is going to be running concurrently with MUnit itself on a different thread and MUnit will jump straight to the validation section of the unit test without waiting for the file connector to read from the directory. This is a tricky scenario, because the Unit Test should be synchronous with the event source in this case. A solution could be to disable the flow source in the unit test, and feed it a payload from another file connector.

Now what we need is to add a beforeTest processor to create a file into the inbox directory.

Now your unit test should go green.

THis is still not satisfactory, because the reference flow had to be disabled. The test.txt file stays in the inbox directory and is not being moved into the oubox directory.
In the next post, we will describe how to fix this issue so we can test a file connector without hacing to disable it in the unit test.
Stay tuned.

Hello Mule (Mulesoft)

WB — Thu, 21 Dec 2023 19:39:19 +0000

This post is the first of a series of articles about system integration in the enterprise. We will approach the topic from first principles and gradually expand into real world scenarios.

What is System Integration?

System integration is everything. Anytime 2 "things" need to communicate with eachother, they are actually "integrating" with one another. Over the years, system integration has come to mean the process of integrating heterogeneous systems. These are systems that have clear boundaries between eachother, usually built by different teams to address different concerns, but need to talk to eachother by exchanging messages. A data warehouse system (DWS) may need to be aware of all the items that were ordered during the day for analytics purposes. An oder-management system (OMS) will then have to report the relevant data to the DWS. There need to be a way to exchange messages between the 2 systems in a reliable and robust way. One tried and tested solution is the use of files as exchange mechanism. Here we have an inbox directory, in which the OMS will drop the files with the list of items sold during the day, and the DWS will read them for processing.

In the next section, we will implement a solution to this simple yet intricate process. We will start with a local file exchange and then continue with a SFTP Server.

Mule

System Integration is difficult to implement right. There are a lot of great tools available on the market to help make the task of the system integrator easy. Some of the tools will be touched in this blogs serie, but the main focus will be on Mule, and sometimes we will compare the Mule solution with Apache Camel or Spring Integration.

Hello Mule

File exchange is the "helloworld" of system integration. Let's implement files exchange with Anypoint Studio
If you have ever worked with eclipse before, you will feel right at home because anypoint studio is based on the eclipse platform.
Let's jump right into it:

Go to
File -> New -> Mule Project

In the "Mule Palette", enter "File" in the search box.

You will get the list of file connectors available. The one we are going to use, is the "On new or Updated File". This connector will monitor a directory for any new or updated file and trigger processing. Drag and drop it on the blank canvas

Select the connector to activate its configuration:

Under "Basic Settings", add a new connector configuration by clicking the + button.

Choose a working directory on your machine and click "Ok". I have created mine under C:\dev\Mulesoft\tutorial
In the "General" configuration panel, set the directory to "inbox", the Matcher to "Edit inline" and the filename pattern to "*.txt"

Mule will be watching for *.txt files in the directory C:\dev\Mulesoft\tutorial\inbox. You have to make sure that you have created the inbox directory.

Scroll down and locate the Scheduling Strategy. Make sure it is "Fixed frequency". Leave "Frequency" to 1000 and TimeUnit to MILLISECONDS. Mule will be monitory the inbox directory every 1000 milliseconds (1 second).

Scroll down to the "Post processing action" section and enter directory to move the *.txt files to. Make sure that directory exists.

We are almost ready to test our application. What is missing is a processor that will process the files as they are being read from the inbox directory. We are going to add a simple Logger which purpose is to output the content of the file that are being loaded by mule.
In the "Mule Palette", enter "logger"

Select the "Logger" processor and drag and drop into the flow after the file connector.

Right click the canvas and select Run project. Wait until the application has been deployed by looking in the Console.

Create a file test.txt and drop it into the inbox directory. The file will be moved automatically to the outboxdirectory by the mule application.
In the console window, observe how the Logger processor is logging the file read from the inbox directory.

If you have made it to this point, congratulations. In the next posts, we will look into unit testing the application with MUnit. We will also show how to read the content of the file.
Stay tuned.