Operation mapping
- •db:select → JdbcTemplate.query(...) returning a List<Map<String,Object>> or a mapped type
- •db:insert → JdbcTemplate.update(...) with named parameters
- •db:update → JdbcTemplate.update(...)
- •db:delete → JdbcTemplate.update(...)
- •db:bulk-insert → JdbcTemplate.batchUpdate(...)
- •db:stored-procedure → SimpleJdbcCall
Before and after: a select
<db:select config-ref="dbConfig">
<db:sql>SELECT id, name FROM customers WHERE region = :region</db:sql>
<db:input-parameters>#[{ region: attributes.queryParams.region }]</db:input-parameters>
</db:select>String sql = "SELECT id, name FROM customers WHERE region = :region";
Map<String, Object> params = Map.of("region", region);
List<Map<String, Object>> rows =
namedParameterJdbcTemplate.queryForList(sql, params);Configuration mapping
The Mule db:config (host, port, user, password, database) maps to Spring's standard datasource properties in application.yml, so credentials live in configuration, not code:
spring:
datasource:
url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}
username: ${DB_USER}
password: ${DB_PASSWORD}How the conversion is validated
Database operations are verified end-to-end: the converted Spring Boot app is deployed alongside the original Mule app and the same requests are replayed against both, with every response field compared. In our reference conversion, the database endpoints (select, insert, bulk-insert, delete) match the Mule runtime byte-for-byte.
See the worked reference conversion on the Proof page for the actual field-by-field results.