| Wiki Markup |
|---|
h2. File Component - *Camel 2.0 onwards*
{info:title=Using Camel 1.x}
This documentation is only for Camel 2.0 or newer. If you are using Camel 1.x then see this [link|File] instead.
{info}
The File component provides access to file systems, allowing files to be processed by any other Camel [Components] or messages from other components to be saved to disk.
h3. URI format
{code}
file:directoryName[?options]
{code}
or
{code}
file://directoryName[?options]
{code}
Where *directoryName* represents the underlying file directory.
You can append query options to the URI in the following format, {{?option=value&option=value&...}}
{tip:title=Only directories}
Camel 2.0 only support endpoints configured with a starting directory. So the *directoryName* must be a directory.
If you want to consume a single file only, you can use the *fileName* option, e.g. by setting {{fileName=thefilename}}.
Also, the starting directory must not contain dynamic expressions with ${ } placeholders. Again use the {{fileName}} option to specify the dynamic part of the filename.
In Camel 1.x you could also configure a file and this caused more harm than good as it could lead to confusing situations.
{tip}
{warning:title=Avoid reading files currently being written by another application}
Beware the JDK File IO API is a bit limited in detecting whether another application is currently writing/copying a file. And the implementation can be different depending on OS platform as well. This could lead to that Camel thinks the file is not locked by another process and start consuming it. Therefore you have to do you own investigation what suites your environment. To help with this Camel provides different {{readLock}} options and {{doneFileOption}} option that you can use. See also the section _Consuming files from folders where others drop files directly_.
{warning}
h3. URI Options
h4. Common
{div:class=confluenceTableSmall}
|| Name || Default Value || Description ||
| {{autoCreate}} | {{true}} | Automatically create missing directories in the file's pathname. For the file consumer, that means creating the starting directory. For the file producer, it means the directory to where the files should be written. |
| {{bufferSize}} | 128kb | Write buffer sized in bytes. |
| {{fileName}} | {{null}} | Use [Expression] such as [File Language] to dynamically set the filename. For consumers, it's used as a filename filter. For producers, it's used to evaluate the filename to write. If an expression is set, it take precedence over the {{CamelFileName}} header. (*Note:* The header itself can also be an [Expression]). The expression options support both {{String}} and {{Expression}} types. If the expression is a {{String}} type, it is *always* evaluated using the [File Language]. If the expression is an {{Expression}} type, the specified {{Expression}} type is used - this allows you, for instance, to use [OGNL] expressions. For the consumer, you can use it to filter filenames, so you can for instance consume today's file using the [File Language] syntax: {{mydata-$\{date:now:yyyyMMdd}.txt}}. |
| {{flatten}} | {{false}} | Flatten is used to flatten the file name path to strip any leading paths, so it's just the file name. This allows you to consume recursively into sub-directories, but when you eg write the files to another directory they will be written in a single directory. Setting this to {{true}} on the producer enforces that any file name recived in {{CamelFileName}} header will be stripped for any leading paths. |
| {{charset}} | {{null}} | *Camel 2.5:* this option is used to specify the encoding of the file, and camel will set the Exchange property with Exchange.CHARSET_NAME with the value of this option. |
{div}
h4. Consumer
{div:class=confluenceTableSmall}
|| Name || Default Value || Description ||
| {{initialDelay}} | {{1000}} | Milliseconds before polling the file/directory starts. |
| {{delay}} | {{500}} | Milliseconds before the next poll of the file/directory. |
| {{useFixedDelay}} | {{false}} | Set to {{true}} to use fixed delay between pools, otherwise fixed rate is used. See [ScheduledExecutorService|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html] in JDK for details.|
| {{recursive}} | {{false}} | If a directory, will look for files in all the sub-directories as well. |
| {{delete}} | {{false}} | If {{true}}, the file will be deleted *after* it is processed |
| {{noop}} | {{false}} | If {{true}}, the file is not moved or deleted in any way. This option is good for readonly data, or for [ETL] type requirements. If {{noop=true}}, Camel will set {{idempotent=true}} as well, to avoid consuming the same files over and over again. |
| {{preMove}} | {{null}} | Use [Expression] such as [File Language] to dynamically set the filename when moving it *before* processing. For example to move in-progress files into the {{order}} directory set this value to {{order}}. |
| {{move}} | {{.camel}} | Use [Expression] such as [File Language] to dynamically set the filename when moving it *after* processing. To move files into a {{.done}} subdirectory just enter {{.done}}. |
| {{moveFailed}} | {{null}} | Use [Expression] such as [File Language] to dynamically set the filename when moving *failed files after* processing. To move files into a {{error}} subdirectory just enter {{error}}. *Note:* When moving the files to another location it can/will *handle* the error when you move it to another location so Camel cannot pick up the file again. |
| {{include}} | {{null}} | Is used to include files, if filename matches the regex pattern. |
| {{exclude}} | {{null}} | Is used to exclude files, if filename matches the regex pattern. |
| {{idempotent}} | {{false}} | Option to use the [Idempotent Consumer] EIP pattern to let Camel skip already processed files. Will by default use a memory based LRUCache that holds 1000 entries. If {{noop=true}} then idempotent will be enabled as well to avoid consuming the same files over and over again. |
| {{idempotentRepository}} | {{null}} | Pluggable repository as a [org.apache.camel.processor.idempotent.MessageIdRepository|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/idempotent/MessageIdRepository.html] class. Will by default use {{MemoryMessageIdRepository}} if none is specified and {{idempotent}} is {{true}}. |
| {{inProgressRepository}} | {{memory}} | Pluggable in-progress repository as a [org.apache.camel.processor.idempotent.MessageIdRepository|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/idempotent/MessageIdRepository.html] class. The in-progress repository is used to account the current in progress files being consumed. By default a memory based repository is used. |
| {{filter}} | {{null}} | Pluggable filter as a {{org.apache.camel.component.file.GenericFileFilter}} class. Will skip files if filter returns {{false}} in its {{accept()}} method. Camel also ships with an *ANT path matcher* filter in the {{camel-spring}} component. More details in section below. |
| {{sorter}} | {{null}} | Pluggable sorter as a [java.util.Comparator<org.apache.camel.component.file.GenericFile>|http://java.sun.com/j2se/1.5.0/docs/api/java/util/Comparator.html] class. |
| {{sortBy}} | {{null}} | Built-in sort using the [File Language]. Supports nested sorts, so you can have a sort by file name and as a 2nd group sort by modified date. See sorting section below for details. |
| {{readLock}} | {{markerFile}} | Used by consumer, to only poll the files if it has exclusive read-lock on the file (i.e. the file is not in-progress or being written). Camel will wait until the file lock is granted.
This option provides the build in strategies:
- {{markerFile}} is the behaviour from Camel 1.x, where Camel will create a marker file and hold a lock on the marker file. This option is *not* avail for the [FTP|FTP2] component.
- {{changed}} is using file length/modification timestamp to detect whether the file is currently being copied or not. Will at least use 1 sec. to determine this, so this option cannot consume files as fast as the others, but can be more reliable as the JDK IO API cannot always determine whether a file is currently being used by another process. This option is *not* avail for the [FTP|FTP2] component.
- {{fileLock}} is for using {{java.nio.channels.FileLock}}. This option is *not* avail for the [FTP|FTP2] component.
- {{rename}} is for using a try to rename the file as a test if we can get exclusive read-lock.
- {{none}} is for no read locks at all.|
| {{readLockTimeout}} | - | Optional timeout in millisecondsmillis for the read-lock, if supported by the read-lock. If the read-lock could not be granted and the timeout triggered, then Camel will skip the file. At next poll Camel, will try the file again, and this time maybe the read-lock could be granted. Use a value of 0 or lower to indicate forever. In *Camel 2.0* the default value is 0. In *Camel 2.1* the default value is 10000. Currently {{fileLock}}, {{changed}} and {{rename}} support the timeout. |
| {{readLockCheckInterval}} | {{1000}} | *Camel 2.6:* Interval in millis for the read-lock, if supported by the read lock. This interval is used for sleeping between attempts to acquire the read lock. For example when using the {{changed}} read lock, you can set a higher interval period to cater for _slow writes_. The default of 1 sec. may be _too fast_ if the producer is very slow writing the file. |
| {{exclusiveReadLockStrategy}} | {{null}} | Pluggable read-lock as a {{org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy}} implementation. |
| {{processStrategy}} | {{null}} | A pluggable {{org.apache.camel.component.file.GenericFileProcessStrategy}} allowing you to implement your own {{readLock}} option or similar. Can also be used when special conditions must be met before a file can be consumed, such as a special _ready_ file exists. If this option is set then the {{readLock}} option does not apply. |
| {{maxMessagesPerPoll}} | {{0}} | An integer that defines the maximum number of messages to gather per poll. By default, no maximum is set. Can be used to set a limit of e.g. 1000 to avoid having the server read thousands of files as it starts up. Set a value of 0 or negative to disabled it. |
| {{startingDirectoryMustExist}} | {{false}} | *Camel 2.5:* Whether the starting directory must exist. Mind that the {{autoCreate}} option is default enabled, which means the starting directory is normally auto created if it doesn't exist. You can disable {{autoCreate}} and enable this to ensure the starting directory must exist. Will thrown an exception if the directory doesn't exist. |
| {{directoryMustExist}} | {{false}} | *Camel 2.5:* Similar to {{startingDirectoryMustExist}} but this applies during polling recursive sub directories. |
| {{doneFileName}} | {{null}} | *Camel 2.6:* If provided, Camel will only consume files if a _done_ file exists. This option configures what file name to use. Either you can specify a fixed name. Or you can use dynamic placeholders. The _done_ file is *always* expected in the same folder as the original file. See _using done file_ and _writing done file_ sections for examples. |
{div}
h4. Default behavior for file consumer
* By default the file is locked for the duration of the processing.
* After the route has completed, files are moved into the {{.camel}} subdirectory, so that they appear to be deleted.
* The File Consumer will always skip any file whose name starts with a dot, such as {{.}}, {{.camel}}, {{.m2}} or {{.groovy}}.
* Only files (not directories) are matched for valid filename, if options such as: {{include}} or {{exclude}} are used.
h4. Producer
{div:class=confluenceTableSmall}
|| Name || Default Value || Description ||
| {{fileExist}} | {{Override}} | What to do if a file already exists with the same name. The following values can be specified: *Override*, *Append*, *Fail* and *Ignore*. {{Override}}, which is the default, replaces the existing file. {{Append}} adds content to the existing file. {{Fail}} throws a {{GenericFileOperationException}}, indicating that there is already an existing file. {{Ignore}} silently ignores the problem and *does not* override the existing file, but assumes everything is okay. |
| {{tempPrefix}} | {{null}} | This option is used to write the file using a temporary name and then, after the write is complete, rename it to the real name. Can be used to identify files being written and also avoid consumers (not using exclusive read locks) reading in progress files. Is often used by [FTP|FTP2] when uploading big files. |
| {{tempFileName}} | {{null}} | *Camel 2.1:* The *same* as {{tempPrefix}} option but offering a more fine grained control on the naming of the temporary filename as it uses the [File Language]. |
| {{keepLastModified}} | {{false}} | *Camel 2.2:* Will keep the last modified timestamp from the source file (if any). Will use the {{Exchange.FILE_LAST_MODIFIED}} header to located the timestamp. This header can contain either a {{java.util.Date}} or {{long}} with the timestamp. If the timestamp exists and the option is enabled it will set this timestamp on the written file. *Note:* This option only applies to the *file* producer. You _cannot_ use this option with any of the ftp producers. |
| {{eagerDeleteTargetFile}} | {{true}} | *Camel 2.3:* Whether or not to eagerly delete any existing target file. This option only applies when you use {{fileExists=Override}} and the {{tempFileName}} option as well. You can use this to disable (set it to false) deleting the target file before the temp file is written. For example you may write big files and want the target file to exists during the temp file is being written. This ensure the target file is only deleted until the very last moment, just before the temp file is being renamed to the target filename. |
| {{doneFileName}} | {{null}} | *Camel 2.6:* If provided, then Camel will write a 2nd _done_ file when the original file has been written. The _done_ file will be empty. This option configures what file name to use. Either you can specify a fixed name. Or you can use dynamic placeholders. The _done_ file will *always* be written in the same folder as the original file. See _writing done file_ section for examples. |
{div}
h4. Default behavior for file producer
* By default it will override any existing file, if one exist with the same name.
{tip:title=Override is now default}
In Camel 1.x the {{Append}} is the default for the file producer. We have changed this to {{Override}} in Camel 2.0 as this is also the default file operation using {{java.io.File}}.
And also the default for the FTP library we use in the [camel-ftp|FTP2] component.
{tip}
h3. Move and Delete operations
Any move or delete operations is executed after (post command) the routing has completed; so during processing of the {{Exchange}} the file is still located in the inbox folder.
Lets illustrate this with an example:
{code:java}
from("file://inbox?move=.done").to("bean:handleOrder");
{code}
When a file is dropped in the {{inbox}} folder, the file consumer notices this and creates a new {{FileExchange}} that is routed to the {{handleOrder}} bean. The bean then processes the {{File}} object. At this point in time the file is still located in the {{inbox}} folder. After the bean completes, and thus the route is completed, the file consumer will perform the move operation and move the file to the {{.done}} sub-folder.
The *move* and *preMove* options should be a directory name, which can be either relative or absolute. If relative, the directory is created as a sub-folder from within the folder where the file was consumed.
By default, Camel will move consumed files to the {{.camel}} sub-folder relative to the directory where the file was consumed.
If you want to delete the file after processing, the route should be:
{code:java}
from("file://inobox?delete=true").to("bean:handleOrder");
{code}
We have introduced a *pre* move operation to move files *before* they are processed. This allows you to mark which files have been scanned as they are moved to this sub folder before being processed.
{code:java}
from("file://inbox?preMove=inprogress").to("bean:handleOrder");
{code}
You can combine the *pre* move and the regular move:
{code:java}
from("file://inbox?preMove=inprogress&move=.done").to("bean:handleOrder");
{code}
So in this situation, the file is in the {{inprogress}} folder when being processed and after it's processed, it's moved to the {{.done}} folder.
h4. Fine grained control over Move and PreMove option
The *move* and *preMove* option is [Expression]-based, so we have the full power of the [File Language] to do advanced configuration of the directory and name pattern.
Camel will, in fact, internally convert the directory name you enter into a [File Language] expression. So when we enter {{move=.done}} Camel will convert this into: {{$\{file:parent}/.done/$\{file:onlyname}}}. This is only done if Camel detects that you have not provided a $\{ } in the option value yourself. So when you enter a ${ } Camel will *not* convert it and thus you have the full power.
So if we want to move the file into a backup folder with today's date as the pattern, we can do:
{code}
move=backup/${date:now:yyyyMMdd}/${file:name}
{code}
h4. About moveFailed
The {{moveFailed}} option allows you to move files that *could not* be processed succesfully to another location such as a error folder of your choice. For example to move the files in an error folder with a timestamp you can use {{moveFailed=/error/$\{file:name.noext}-$\{date:now:yyyyMMddHHmmssSSS}.$\{file:ext}}}.
See more examples at [File Language]
h3. Message Headers
The following headers are supported by this component:
h4. File producer only
{div:class=confluenceTableSmall}
|| Header || Description ||
| {{CamelFileName}} | Specifies the name of the file to write (relative to the endpoint directory). The name can be a {{String}}; a {{String}} with a [File Language] or [Simple] expression; or an [Expression] object. If it's {{null}} then Camel will auto-generate a filename based on the message unique ID. |
| {{CamelFileNameProduced}} | The actual absolute filepath (path + name) for the output file that was written. This header is set by Camel and its purpose is providing end-users with the name of the file that was written. |
{div}
h4. File consumer only
{div:class=confluenceTableSmall}
|| Header || Description ||
| {{CamelFileName}} | Name of the consumed file as a relative file path with offset from the starting directory configured on the endpoint. |
| {{CamelFileNameOnly}} | Only the file name (the name with no leading paths). |
| {{CamelFileAbsolute}} | A {{boolean}} option specifying whether the consumed file denotes an absolute path or not. Should normally be {{false}} for relative paths. Absolute paths should normally not be used but we added to the move option to allow moving files to absolute paths. But can be used elsewhere as well. |
| {{CamelFileAbsolutePath}} | The absolute path to the file. For relative files this path holds the relative path instead. |
| {{CamelFilePath}} | The file path. For relative files this is the starting directory + the relative filename. For absolute files this is the absolute path. |
| {{CamelFileRelativePath}} | The relative path. |
| {{CamelFileParent}} | The parent path. |
| {{CamelFileLength}} | A {{long}} value containing the file size. |
| {{CamelFileLastModified}} | A {{Date}} value containing the last modified timestamp of the file. |
{div}
h3. Batch Consumer
This component implements the [Batch Consumer].
h4. Exchange Properties, file consumer only
As the file consumer is {{BatchConsumer}} it supports batching the files it polls. By batching it means that Camel will add some properties to the [Exchange] so you know the number of files polled the current index in that order.
{div:class=confluenceTableSmall}
|| Property || Description ||
| {{CamelBatchSize}} | The total number of files that was polled in this batch. |
| {{CamelBatchIndex}} | The current index of the batch. Starts from 0. |
| {{CamelBatchComplete}} | A {{boolean}} value indicating the last [Exchange] in the batch. Is only {{true}} for the last entry. |
{div}
This allows you for instance to know how many files exists in this batch and for instance let the [Aggregator] aggregate this number of files.
h3. Common gotchas with folder and filenames
When Camel is producing files (writing files) there are a few gotchas affecting how to set a filename of your choice. By default, Camel will use the message ID as the filename, and since the message ID is normally a unique generated ID, you will end up with filenames such as: {{ID-MACHINENAME-2443-1211718892437-1-0}}. If such a filename is not desired, then you must provide a filename in the {{CamelFileName}} message header. The constant, {{Exchange.FILE_NAME}}, can also be used.
The sample code below produces files using the message ID as the filename:
{code}
from("direct:report").to("file:target/reports");
{code}
To use {{report.txt}} as the filename you have to do:
{code}
from("direct:report").setHeader(Exchange.FILE_NAME, constant("report.txt")).to( "file:target/reports");
{code}
... the same as above, but with {{CamelFileName}}:
{code}
from("direct:report").setHeader("CamelFileName", constant("report.txt")).to( "file:target/reports");
{code}
And a syntax where we set the filename on the endpoint with the *fileName* URI option.
{code}
from("direct:report").to("file:target/reports/?fileName=report.txt");
{code}
h3. Filename Expression
Filename can be set either using the *expression* option or as a string-based [File Language] expression in the {{CamelFileName}} header. See the [File Language] for syntax and samples.
h3. Consuming files from folders where others drop files directly
Beware if you consume files from a folder where other applications write files directly. Take a look at the different {{readLock}} options to see what suits your use cases. The best approach is however to write to another folder and after the write move the file in the drop folder. However if you write files directly to the drop folder then the option {{changed}} could better detect whether a file is currently being written/copied as it uses a file changed algorithm to see whether the file size / modification changes over a period of time. The other read lock options rely on Java File API that sadly is not always very good at detecting this. You may also want to look at the {{doneFileName}} option, which uses a marker file (done) to signal when a file is done and ready to be consumed.
h3. Using done files
*Available as of Camel 2.6*
See also section _writing done files_ below.
If you want only to consume files when a done file exist, then you can use the {{doneFileName}} option on the endpoint.
{code:java}
from("file:bar?doneFileName=done");
{code}
Will only consume files from the bar folder, if a file name done exists in the same directory as the target files. Camel will automatic delete the done file when it's done consuming the files.
However its more common to have one done file per target file. This means there is a 1:1 correlation. To do this you must use dynamic placeholders in the {{doneFileName}} option. Currently Camel supports the following two dynamic tokens: {{file:name}} and {{file:name.noext}} which must be enclosed in ${ }. The consumer only supports the static part of the done file name as either prefix or suffix (not both).
{code:java}
from("file:bar?doneFileName=${file:name}.done");
{code}
In this example only files will be polled if there exists a done file with the name _file name_.done. For example
- {{hello.txt}} - is the file to be consumed
- {{hello.txt.done}} - is the associated done file
You can also use a prefix for the done file, such as:
{code:java}
from("file:bar?doneFileName=ready-${file:name}");
{code}
- {{hello.txt}} - is the file to be consumed
- {{ready-hello.txt}} - is the associated done file
h3. Writing done files
*Available as of Camel 2.6*
After you have written af file you may want to write an additional _done_ file as a kinda of marker, to indicate to others that the file is finished and has been written. To do that you can use the {{doneFileName}} option on the file producer endpoint.
{code:java}
.to("file:bar?doneFileName=done");
{code}
Will simply create a file named {{done}} in the same directory as the target file.
However its more common to have one done file per target file. This means there is a 1:1 correlation. To do this you must use dynamic placeholders in the {{doneFileName}} option. Currently Camel supports the following two dynamic tokens: {{file:name}} and {{file:name.noext}} which must be enclosed in ${ }.
{code:java}
.to("file:bar?doneFileName=done-${file:name}");
{code}
Will for example create a file named {{done-foo.txt}} if the target file was {{foo.txt}} in the same directory as the target file.
{code:java}
.to("file:bar?doneFileName=${file:name}.done");
{code}
Will for example create a file named {{foo.txt.done}} if the target file was {{foo.txt}} in the same directory as the target file.
{code:java}
.to("file:bar?doneFileName=${file:name.noext}.done");
{code}
Will for example create a file named {{foo.done}} if the target file was {{foo.txt}} in the same directory as the target file.
h3. Samples
h4. Read from a directory and write to another directory
{code:java}
from("file://inputdir/?delete=true").to("file://outputdir")
{code}
Listen on a directory and create a message for each file dropped there. Copy the contents to the {{outputdir}} and delete the file in the {{inputdir}}.
h4. Reading recursive from a directory and write the another
{code:java}
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir")
{code}
Listen on a directory and create a message for each file dropped there. Copy the contents to the {{outputdir}} and delete the file in the {{inputdir}}. Will scan recursively into sub-directories. Will lay out the files in the same directory structure in the {{outputdir}} as the {{inputdir}}, including any sub-directories.
{code}
inputdir/foo.txt
inputdir/sub/bar.txt
{code}
Will result in the following output layout:
{code}
outputdir/foo.txt
outputdir/sub/bar.txt
{code}
h5. Using flatten
If you want to store the files in the outputdir directory in the same directory, disregarding the source directory layout (e.g. to flatten out the path), you just add the {{flatten=true}} option on the file producer side:
{code:java}
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir?flatten=true")
{code}
Will result in the following output layout:
{code}
outputdir/foo.txt
outputdir/bar.txt
{code}
h4. Reading from a directory and the default move operation
Camel will by default move any processed file into a {{.camel}} subdirectory in the directory the file was consumed from.
{code:java}
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir")
{code}
Affects the layout as follows:
*before*
{code}
inputdir/foo.txt
inputdir/sub/bar.txt
{code}
*after*
{code}
inputdir/.camel/foo.txt
inputdir/sub/.camel/bar.txt
outputdir/foo.txt
outputdir/sub/bar.txt
{code}
h4. Read from a directory and process the message in java
{code}
from("file://inputdir/").process(new Processor() {
public void process(Exchange exchange) throws Exception {
Object body = exchange.getIn().getBody();
// do some business logic with the input body
}
});
{code}
The body will be a {{File}} object that points to the file that was just dropped into the {{inputdir}} directory.
h4. Read files from a directory and send the content to a jms queue
{code}
from("file://inputdir/").convertBodyTo(String.class).to("jms:test.queue")
{code}
By default the file endpoint sends a {{FileMessage}} which contains a {{File}} object as the body. If you send this directly to the JMS component the JMS message will only contain the {{File}} object but not the content. By converting the {{File}} to a {{String}}, the message will contain the file contents what is probably what you want.
The route above using Spring DSL:
{code:xml}
<route>
<from uri="file://inputdir/"/>
<convertBodyTo type="java.lang.String"/>
<to uri="jms:test.queue"/>
</route>
{code}
h4. Writing to files
Camel is of course also able to write files, i.e. produce files. In the sample below we receive some reports on the SEDA queue that we processes before they are written to a directory.
{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/ToFileRouteTest.java}
h4. Write to subdirectory using {{Exchange.FILE_NAME}}
Using a single route, it is possible to write a file to any number of subdirectories. If you have a route setup as such:
{code}
<route>
<from uri="bean:myBean"/>
<to uri="file:/rootDirectory"/>
</route>
{code}
You can have {{myBean}} set the header {{Exchange.FILE_NAME}} to values such as:
{code}
Exchange.FILE_NAME = hello.txt => /rootDirectory/hello.txt
Exchange.FILE_NAME = foo/bye.txt => /rootDirectory/foo/bye.txt
{code}
This allows you to have a single route to write files to multiple destinations.
h4. Using expression for filenames
In this sample we want to move consumed files to a backup folder using today's date as a sub-folder name:
{code:java}
from("file://inbox?move=backup/${date:now:yyyyMMdd}/${file:name}").to("...");
{code}
See [File Language] for more samples.
h3. Avoiding reading the same file more than once (idempotent consumer)
Camel supports [Idempotent Consumer] directly within the component so it will skip already processed files. This feature can be enabled by setting the {{idempotent=true}} option.
{code:java}
from("file://inbox?idempotent=true").to("...");
{code}
By default Camel uses a in memory based store for keeping track of consumed files, it uses a least recently used cache storing holding up to 1000 entries. You can plugin your own implementation of this store by using the {{idempotentRepository}} option using the {{\#}} sign in the value to indicate it's a referring to a bean in the [Registry] with the specified {{id}}.
{code:xml}
<!-- define our store as a plain spring bean -->
<bean id="myStore" class="com.mycompany.MyIdempotentStore"/>
<route>
<from uri="file://inbox?idempotent=true&idempotentRepository=#myStore"/>
<to uri="bean:processInbox"/>
</route>
{code}
Camel will log at {{DEBUG}} level if it skips a file because it has been consumed before:
{code}
DEBUG FileConsumer is idempotent and the file has been consumed before. Will skip this file: target\idempotent\report.txt
{code}
h4. Using a file based idempotent repository
In this section we will use the file based idempotent repository {{org.apache.camel.processor.idempotent.FileIdempotentRepository}} instead of the in-memory based that is used as default.
This repository uses a 1st level cache to avoid reading the file repository. It will only use the file repository to store the content of the 1st level cache. Thereby the repository can survive server restarts. It will load the content of the file into the 1st level cache upon startup. The file structure is very simple as it store the key in separate lines in the file. By default, the file store has a size limit of 1mb when the file grew larger Camel will truncate the file store be rebuilding the content by flushing the 1st level cache in a fresh empty file.
We configure our repository using Spring XML creating our file idempotent repository and define our file consumer to use our repository with the {{idempotentRepository}} using {{\#}} sign to indicate [Registry] lookup:
{snippet:id=example|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/idempotent/fileConsumerIdempotentTest.xml}
h4. Using a JPA based idempotent repository
In this section we will use the JPA based idempotent repository instead of the in-memory based that is used as default.
First we need a persistence-unit in {{META-INF/persistence.xml}} where we need to use the class {{org.apache.camel.processor.idempotent.jpa.MessageProcessed}} as model.
{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-jpa/src/test/resources/META-INF/persistence.xml}
Then we need to setup a Spring {{jpaTemplate}} in the spring XML file:
{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-jpa/src/test/resources/org/apache/camel/processor/jpa/spring.xml}
And finally we can create our JPA idempotent repository in the spring XML file as well:
{snippet:id=jpaStore|lang=xml|url=camel/trunk/components/camel-jpa/src/test/resources/org/apache/camel/processor/jpa/fileConsumerJpaIdempotentTest-config.xml}
And yes then we just need to refer to the *jpaStore* bean in the file consumer endpoint using the [[idempotentRepository}} using the {{\#}} syntax option:
{code:xml}
<route>
<from uri="file://inbox?idempotent=true&idempotentRepository=#jpaStore"/>
<to uri="bean:processInbox"/>
</route>
{code}
h3. Filter using org.apache.camel.component.file.GenericFileFilter
Camel supports pluggable filtering strategies. You can then configure the endpoint with such a filter to skip certain files being processed.
In the sample we have build our own filter that skips files starting with {{skip}} in the filename:
{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/FileConsumerFileFilterTest.java}
And then we can configure our route using the *filter* attribute to reference our filter (using {{\#}} notation) that we have defines in the spring XML file:
{code:xml}
<!-- define our sorter as a plain spring bean -->
<bean id="myFilter" class="com.mycompany.MyFileSorter"/>
<route>
<from uri="file://inbox?filter=#myFilter"/>
<to uri="bean:processInbox"/>
</route>
{code}
h4. Filtering using ANT path matcher
The ANT path matcher is shipped out-of-the-box in the *camel-spring* jar. So you need to depend on *camel-spring* if you are using Maven.
The reasons is that we leverage Spring's [AntPathMatcher|http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/util/AntPathMatcher.html] to do the actual matching.
The file paths is matched with the following rules:
- {{?}} matches one character
- {{*}} matches zero or more characters
- {{**}} matches zero or more directories in a path
The sample below demonstrates how to use it:
{snippet:id=example|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/file/SpringFileAntPathMatcherFileFilterTest-context.xml}
h3. Sorting using Comparator
Camel supports pluggable sorting strategies. This strategy it to use the build in {{java.util.Comparator}} in Java. You can then configure the endpoint with such a comparator and have Camel sort the files before being processed.
In the sample we have built our own comparator that just sorts by file name:
{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/FileSorterRefTest.java}
And then we can configure our route using the *sorter* option to reference to our sorter ({{mySorter}}) we have defined in the spring XML file:
{code:xml}
<!-- define our sorter as a plain spring bean -->
<bean id="mySorter" class="com.mycompany.MyFileSorter"/>
<route>
<from uri="file://inbox?sorter=#mySorter"/>
<to uri="bean:processInbox"/>
</route>
{code}
{tip:title=URI options can reference beans using the # syntax}
In the Spring DSL route about notice that we can refer to beans in the [Registry] by prefixing the id with {{\#}}. So writing {{sorter=#mySorter}}, will instruct Camel to go look in the [Registry] for a bean with the ID, {{mySorter}}.
{tip}
h3. Sorting using sortBy
Camel supports pluggable sorting strategies. This strategy it to use the [File Language] to configure the sorting. The {{sortBy}} option is configured as follows:
{code}
sortBy=group 1;group 2;group 3;...
{code}
Where each group is separated with semi colon. In the simple situations you just use one group, so a simple example could be:
{code}
sortBy=file:name
{code}
This will sort by file name, you can reverse the order by prefixing {{reverse:}} to the group, so the sorting is now Z..A:
{code}
sortBy=reverse:file:name
{code}
As we have the full power of [File Language] we can use some of the other parameters, so if we want to sort by file size we do:
{code}
sortBy=file:length
{code}
You can configure to ignore the case, using {{ignoreCase:}} for string comparison, so if you want to use file name sorting but to ignore the case then we do:
{code}
sortBy=ignoreCase:file:name
{code}
You can combine ignore case and reverse, however reverse must be specified first:
{code}
sortBy=reverse:ignoreCase:file:name
{code}
In the sample below we want to sort by last modified file, so we do:
{code}
sortBy=file:modifed
{code}
And then we want to group by name as a 2nd option so files with same modifcation is sorted by name:
{code}
sortBy=file:modifed;file:name
{code}
Now there is an issue here, can you spot it? Well the modified timestamp of the file is too fine as it will be in milliseconds, but what if we want to sort by date only and then subgroup by name?
Well as we have the true power of [File Language] we can use the its date command that supports patterns. So this can be solved as:
{code}
sortBy=date:file:yyyyMMdd;file:name
{code}
Yeah, that is pretty powerful, oh by the way you can also use reverse per group, so we could reverse the file names:
{code}
sortBy=date:file:yyyyMMdd;reverse:file:name
{code}
h3. Using GenericFileProcessStrategy
The option {{processStrategy}} can be used to use a custom {{GenericFileProcessStrategy}} that allows you to implement your own _begin_, _commit_ and _rollback_ logic.
For instance lets assume a system writes a file in a folder you should consume. But you should not start consuming the file before another _ready_ file have been written as well.
So by implementing our own {{GenericFileProcessStrategy}} we can implement this as:
- In the {{begin()}} method we can test whether the special _ready_ file exists. The begin method returns a {{boolean}} to indicate if we can consume the file or not.
- in the {{commit()}} method we can move the actual file and also delete the _ready_ file.
h3. Debug logging
This component has log level *TRACE* that can be helpful if you have problems.
{include:Endpoint See Also}
- [File Language]
- [FTP2] |
Page History
Overview
Content Tools
Apps