Available as of Apache Camel 2.7
The mybatis: component allows you to query, poll, insert, update and delete data in a relational database using MyBatis.
Maven users will need to add the following dependency to their
pom.xml
for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-mybatis</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
mybatis:statementName[?options]
Where statementName is the statement name in the MyBatis XML mapping file which maps to the query, insert, update or delete operation you wish to evaluate.
You can append query options to the URI in the following format,
?option=value&option=value&...
This component will by default load the MyBatis SqlMapConfig file
from the root of the classpath and expected named as
SqlMapConfig.xml
. If the file is located in
another location, you would have to configure the
configurationUri
option on the
MyBatisComponent
component.
The MyBatis uri options are listed here:
Option | Type | Default | Description |
---|---|---|---|
consumer.onConsume
|
String
|
null
| Statements to run after consuming. Can be used, for example, to update rows after they have been consumed and processed in Camel. See sample later. Multiple statements can be separated with comma. |
consumer.useIterator
|
boolean
|
true
| If true each row returned when polling
will be processed individually. If false
the entire List of data is set as the IN
body. |
consumer.routeEmptyResultSet
|
boolean
|
false
| Sets whether empty result set should be routed or not. By default, empty result sets are not routed. |
statementType
|
StatementType
|
null
| Mandatory to specify for producer to control which kind of
operation to invoke. The enum values are:
SelectOne ,
SelectList ,
Insert , Update ,
Delete . |
maxMessagesPerPoll
|
int
|
0
| An integer to define a maximum messages to gather per poll. By default, no maximum is set. Can be used to set a limit of e.g. 1000 to avoid when starting up the server that there are thousands of files. Set a value of 0 or negative to disabled it. |
Camel populates the result message, either IN or OUT, with a header using the specified statement:
Header | Type | Description |
---|---|---|
CamelMyBatisStatementName
|
String
| The statementName used (for example: insertAccount). |
CamelMyBatisResult
|
Object
| The response returned
from MtBatis in any of the operations. For example,
an INSERT could return the
auto-generated key, or number of rows etc. |
The response from MyBatis will only be set as body if it's a
SELECT
statement. That means, for example,
for INSERT
statements Camel will not replace the
body. This allows you to continue routing and keep the original
body. The response from MyBatis is always stored in the header with
the key CamelMyBatisResult
.
For example if you wish to consume beans from a JMS queue and insert them into a database you could do the following:
from("activemq:queue:newAccount"). to("mybatis:insertAccount?statementType=Insert");
Notice we have to specify the statementType
, as
we need to instruct Camel which kind of operation to invoke.
Where insertAccount is the MyBatis ID in the SQL mapping file:
<!-- Insert example, using the Account parameter class --> <insert id="insertAccount" parameterType="Account"> insert into ACCOUNT ( ACC_ID, ACC_FIRST_NAME, ACC_LAST_NAME, ACC_EMAIL ) values ( #{id}, #{firstName}, #{lastName}, #{emailAddress} ) </insert>
When routing to an MyBatis endpoint you want more fine grained
control so you can control whether the SQL statement to be executed
is a SELEECT
, UPDATE
,
DELETE
or INSERT
etc. So
for instance if we want to route to an MyBatis endpoint in which the
IN body contains parameters to a SELECT
statement
we can do:
from("direct:start") .to("mybatis:selectAccountById?statementType=SelectOne") .to("mock:result");
In the code above we can invoke the MyBatis statement
selectAccountById
and the IN body should
contain the account id we want to retrieve, such as an
Integer
type.
We can do the same for some of the other operations, such as
SelectList
:
from("direct:start") .to("mybatis:selectAllAccounts?statementType=SelectList") .to("mock:result");
And the same for UPDATE
, where we can send an
Account
object as IN body to MyBatis:
from("direct:start") .to("mybatis:updateAccount?statementType=Update") .to("mock:result");
Since this component does not support scheduled polling, you need to use another mechanism for triggering the scheduled polls, such as the Timer or Quartz components.
In the sample below we poll the database, every 30 seconds using the Timer component and send the data to the JMS queue:
from("timer://pollTheDatabase?delay=30000").to("mbatis:selectAllAccounts").to("activemq:queue:allAccounts");
And the MyBatis SQL mapping file used:
<!-- Select with no parameters using the result map for Account class. --> <select id="selectAllAccounts" resultMap="AccountResult"> select * from ACCOUNT </select>
This component supports executing statements after data have been consumed and processed by
Camel. This allows you to do post updates in the database. Notice
all statements must be UPDATE
statements. Camel
supports executing multiple statements whose name should be
separated by comma.
The route below illustrates we execute the consumeAccount statement data is processed. This allows us to change the status of the row in the database to processed, so we avoid consuming it twice or more.
from("mybatis:selectUnprocessedAccounts?consumer.onConsume=consumeAccount").to("mock:results");
And the statements in the sqlmap file:
<select id="selectUnprocessedAccounts" resultMap="AccountResult"> select * from ACCOUNT where PROCESSED = false </select>
<update id="consumeAccount" parameterType="Account"> update ACCOUNT set PROCESSED = true where ACC_ID = #{id} </update>