[[ibatis-component]]
= iBatis Component (deprecated)
:page-source: components/camel-ibatis/src/main/docs/ibatis-component.adoc

*Available as of Camel version 1.2*


The *ibatis:* component allows you to query, poll, insert, update and
delete data in a relational database using
http://ibatis.apache.org/[Apache iBATIS].

*Prefer MyBatis*

The Apache iBatis project is no longer active. The project is moved
outside Apache and is now know as the MyBatis project.

Therefore we encourage users to use xref:mybatis-component.adoc[MyBatis] instead.
This camel-ibatis component will be removed in Camel 3.0.

iBatis do not support Spring 4.x. So you can only use Spring 3.x or
older with iBatis.

Maven users will need to add the following dependency to their `pom.xml`
for this component:

[source,xml]
------------------------------------------------------------
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-ibatis</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>
------------------------------------------------------------

== URI format

[source,java]
------------------------------
ibatis:statementName[?options]
------------------------------

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&...`

This component will by default load the iBatis SqlMapConfig file from
the root of the classpath and expected named as `SqlMapConfig.xml`.

 It uses Spring resource loading so you can define it using `classpath`,
`file` or `http` as prefix to load resources with those schemes.

 In Camel 2.2 you can configure this on the iBatisComponent with the
`setSqlMapConfig(String)` method.

== Options




// component options: START
The iBatis component supports 4 options, which are listed below.



[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *sqlMapClient* (advanced) | To use the given com.ibatis.sqlmap.client.SqlMapClient |  | SqlMapClient
| *sqlMapConfig* (common) | Location of iBatis xml configuration file. The default value is: SqlMapConfig.xml loaded from the classpath | classpath:SqlMapConfig.xml | String
| *useTransactions* (common) | Whether to use transactions. This option is by default true. | true | boolean
| *resolveProperty Placeholders* (advanced) | Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. | true | boolean
|===
// component options: END








// endpoint options: START
The iBatis endpoint is configured using URI syntax:

----
ibatis:statement
----

with the following path and query parameters:

=== Path Parameters (1 parameters):


[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *statement* | *Required* The statement name in the iBatis XML mapping file which maps to the query, insert, update or delete operation you wish to evaluate. |  | String
|===


=== Query Parameters (27 parameters):


[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *isolation* (common) | Transaction isolation level | TRANSACTION_REPEATABLE_READ | String
| *useTransactions* (common) | Whether to use transactions. This option is by default true. | true | boolean
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
| *maxMessagesPerPoll* (consumer) | This option is intended to split results returned by the database pool into the batches and deliver them in multiple exchanges. This integer defines the maximum messages to deliver in single exchange. 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 disable it. | 0 | int
| *onConsume* (consumer) | Statement to run after data has been processed in the route |  | String
| *routeEmptyResultSet* (consumer) | Whether allow empty resultset to be routed to the next hop | false | boolean
| *sendEmptyMessageWhenIdle* (consumer) | If the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead. | false | boolean
| *strategy* (consumer) | Allows to plugin a custom IBatisProcessingStrategy to use by the consumer. |  | IBatisProcessing Strategy
| *useIterator* (consumer) | Process resultset individually or as a list | true | boolean
| *exceptionHandler* (consumer) | To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |  | ExceptionHandler
| *exchangePattern* (consumer) | Sets the exchange pattern when the consumer creates an exchange. |  | ExchangePattern
| *pollStrategy* (consumer) | A pluggable org.apache.camel.PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation before an Exchange have been created and being routed in Camel. |  | PollingConsumerPoll Strategy
| *statementType* (producer) | Mandatory to specify for the producer to control which kind of operation to invoke. |  | StatementType
| *synchronous* (advanced) | Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). | false | boolean
| *backoffErrorThreshold* (scheduler) | The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in. |  | int
| *backoffIdleThreshold* (scheduler) | The number of subsequent idle polls that should happen before the backoffMultipler should kick-in. |  | int
| *backoffMultiplier* (scheduler) | To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. |  | int
| *delay* (scheduler) | Milliseconds before the next poll. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 500 | long
| *greedy* (scheduler) | If greedy is enabled, then the ScheduledPollConsumer will run immediately again, if the previous run polled 1 or more messages. | false | boolean
| *initialDelay* (scheduler) | Milliseconds before the first poll starts. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 1000 | long
| *runLoggingLevel* (scheduler) | The consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that. | TRACE | LoggingLevel
| *scheduledExecutorService* (scheduler) | Allows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. |  | ScheduledExecutor Service
| *scheduler* (scheduler) | To use a cron scheduler from either camel-spring or camel-quartz2 component | none | ScheduledPollConsumer Scheduler
| *schedulerProperties* (scheduler) | To configure additional properties when using a custom scheduler or any of the Quartz2, Spring based scheduler. |  | Map
| *startScheduler* (scheduler) | Whether the scheduler should be auto started. | true | boolean
| *timeUnit* (scheduler) | Time unit for initialDelay and delay options. | MILLISECONDS | TimeUnit
| *useFixedDelay* (scheduler) | Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details. | true | boolean
|===
// endpoint options: END





== Message Headers

Camel will populate the result message, either IN or OUT with a header
with the operationName used:

[width="100%",cols="10%,10%,80%",options="header",]
|=======================================================================
|Header |Type |Description

|`CamelIBatisStatementName` |`String` |The *statementName* used (for example: insertAccount).

|`CamelIBatisResult` |`Object` |The *response* returned from iBatis in any of the operations. For
instance an `INSERT` could return the auto-generated key, or number of
rows etc.
|=======================================================================

== Message Body

The response from iBatis 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 iBatis is always stored in the header
with the key `CamelIBatisResult`.

== Samples

For example if you wish to consume beans from a JMS queue and insert
them into a database you could do the following:

[source,java]
--------------------------------------------------
from("activemq:queue:newAccount").
  to("ibatis:insertAccount?statementType=Insert");
--------------------------------------------------

Notice we have to specify the `statementType`, as we need to instruct
Camel which `SqlMapClient` operation to invoke.

Where *insertAccount* is the iBatis ID in the SQL map file:

[source,xml]
------------------------------------------------------------
  <!-- 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>
------------------------------------------------------------

== Using StatementType for better control of IBatis

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. 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:

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`:

And the same for `UPDATE`, where we can send an `Account` object as IN
body to iBatis:

=== Scheduled polling example

Since this component does not support scheduled polling, you need to use
another mechanism for triggering the scheduled polls, such as the
`timer` or xref:quartz-component.adoc[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:

[source,java]
---------------------------------------------------------------------------------------------------------------------------------------
from("timer://pollTheDatabase?delay=30000").to("ibatis:selectAllAccounts?statementType=QueryForList").to("activemq:queue:allAccounts");
---------------------------------------------------------------------------------------------------------------------------------------

And the iBatis SQL map file used:

[source,xml]
----------------------------------------------------------------------------
  <!-- Select with no parameters using the result map for Account class. -->
  <select id="selectAllAccounts" resultMap="AccountResult">
    select * from ACCOUNT
  </select>
----------------------------------------------------------------------------

=== Using onConsume

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.

And the statements in the sqlmap file:
