Mule 4: Database Connector (Part 1)

Lots of people are wondering about the new features in Mule since Mule released its latest version, Mule 4. There are tons of changes that you can witness in Mule 4 compared to Mule 3. All of the Mule 3's connectors have been replaced by operation-based connectors in Mule 4.

Note: Mule 4 is the latest iteration of the Mule runtime engine. Mule 4 has a totally different approach to connect to the database and perform CRUD operation on a database.

Database Connector in Anypoint Studio 7

All of the connectors are no longer bundled with Mule runtime. We need to explicitly associate them with our application. Not every connector is available inside the palette by default. In Studio, you need to add the database connector explicitly to start working on it.

Add a Connector to Studio

1. In Mule Palette, click Add Module > Add Extension.

2. In Add Module to Project, select the module you want to add from the list of available modules.

3. Click Finish and OK.

After adding the connector to Studio, the connector and its operations appear in the Mule Palette and we can start working on it.

Database Engines Supported Out-of-the-Box

The database connector in Mule 4 provides specialized support for the following databases:

• Derby

• MySQL

• Oracle

• Microsoft SQL Server

So, if we have to configure any other database apart from the above, then we can set it up using a generic JDBC configuration in Mule 4.

Connecting to a Generic Database

The generic database connector can connect to any database for which a JDBC driver is available. The generic connection type is useful in cases where:

1. When we want to connect to a database for which MuleSoft does not provide the out-of-the-box support for the connector.

2. When we want to connect to one of the supported databases but you are using custom options that are not included in the connection types.

A generic connector configuration simply requires the driver class name and connection URL.

The following example shows how to connect to an HSQL database:

<db:generic-config name="Generic_Database_Configuration"
url="jdbc:hsqldb:hsql://localhost:9002" 
driverClassName="org.hsqldb.jdbcDriver"
doc:name="Generic Database Configuration" />

In this post, we will see a use case of the SELECT operation.

Querying a Database (SELECT Operation)

The SELECT operation is used to retrieve information from the relational database. Here, we will supply a SQL query and use DataWeave to supply the parameters to the query.

When we configure a DB operation using the database connector, there are many ways to add parameters values to the SQL statement that you execute against the database.

Approach #1

Using input parameters in the queries:

<flow name="selectParameterizedQuery">
  <db:select config-ref="Generic_Database_Configuration">
    <db:sql>SELECT * FROM EMPLOYEE WHERE name = :name</db:sql>
    <db:input-parameters>
      #[{'name' : payload}]
    </db:input-parameters>
  </db:select>
</flow>

As we see in the above example, input parameters are supplied as key-value pairs, which we can now create by embedding a DataWeave script. Those keys are used in conjunction with the semicolon character (:) to refer to a parameter value by name. This is the recommended approach for using parameters in your query.

Approach #2

The alternative is to directly write queries, but this is a very dangerous practice and can lead to many anomalies and is not recommended.

 <db:sql>SELECT * FROM EMPLOYEE WHERE name = #[payload] </db:sql>

The advantages of using input parameters to configure the WHERE clause in a SELECT statement this way are:

1. The query becomes immune to SQL injection attacks.

2. The connector can perform optimizations that are not possible otherwise, which improves the application’s overall performance.

In the Next Post…

With these basics in mind, in our next post, we will see the DB connector SELECT operation head-on.

Hope this helps! Keep learning!