THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Where statementName is the name in the iBATIS XML configuration 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&...
Options
Option | Type | Default | Description |
|---|---|---|---|
| | | Statements to run after consuming. Can be used, for example, to eg. update rows after they have been consumed and processed in Camel. See sample later. Multiple statements can be separated with comma. |
| Boolean | | If |
| Boolean | | Camel 2.0: Sets whether empty resultset result set should be routed or not. By default, empty result sets are not routed. |
| | | Camel 1.6.1/2.0: Mandatory to specify for IbatisProducer to control which iBatis |
| Integer | | Camel 2.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. |
...
Header | Type | Description |
|---|---|---|
| | Camel 1.x: The statementName used (for example: insertAccount). |
| | Camel 2.0: The statementName used (for example: insertAccount). |
| | Camel 1.6.2/2.0: The response returned from iBatis in any of the operations. For instance a an |
...
Camel 1.6.1: The response from iBatis will be set as OUT body
Camel 1.6.2/2.0: The response from iBatis will only be set as body if its 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 iBatis is always stored in the header with the key CamelIBatisResult.
...
For example if you wish to consume beans from a JMS queue and insert them into a database you could do .the following:
| Code Block |
|---|
from("activemq:queue:newAccount").
to("ibatis:insertAccount?statementType=Insert");
|
...
Where insertAccount is the iBatis id ID in the SQL map file:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- Insert example, using the Account parameter class -->
<insert id="insertAccount" parameterClass="Account">
insert into ACCOUNT (
ACC_ID,
ACC_FIRST_NAME,
ACC_LAST_NAME,
ACC_EMAIL
)
values (
#id#, #firstName#, #lastName#, #emailAddress#
)
</insert>
|
...
Available as of Camel 1.6.1/2.0
When routing to an iBatis 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. This is now possible in Camel 1.6.1/2.0. So for instance if we want to route to an iBatis endpoint in which the IN body contains parameters to a SELECT statement we can do:
| Wiki Markup |
|---|
{snippet:id=e1|lang=java|url=camel/trunk/components/camel-ibatis/src/test/java/org/apache/camel/component/ibatis/IBatisQueryForObjectTest.java} |
In the code above we can invoke the iBatis 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 QueryForList:
| Wiki Markup |
|---|
{snippet:id=e1|lang=java|url=camel/trunk/components/camel-ibatis/src/test/java/org/apache/camel/component/ibatis/IBatisQueryForListTest.java} |
And the same for UPDATE, where we can send an Account object as IN body to iBatis:
...
Since this component does not support scheduled polling, you need to use another mechanism for triggering the scheduled pools polls, such as the Timer or Quartz components.
In the sample below we poll the database, every 30th second 30 seconds using the Timer component and sends send the data to the JMS queue:
...
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.
...