+ Start a Discussion

Apex Data Loader PropertyPlaceholderConfigurer/Dynamic Property Replacement

I am using the data loader as an integration point to run numerous nightly data loads.  Has anyone successfully implemented the Spring PropertyPlaceholderConfigurer to dynamically replace tags in the configuration xml?  For example, if my process-conf.xml has numerous beans below which use UNC paths to specify log and file locations:

<entry key="process.outputError" value="\\Dev\Logs\Contact\contactUpsert_error.csv"/>
<entry key="process.outputSuccess" value="\\Dev\Logs\Contact\contactUpsert_success.csv"/>

I would like to have a custom value in my config.properties file like:


And be able to update the two entries above to look like:

<entry key="process.outputError" value="\\${system.environment}\Logs\Contact\contactUpsert_error.csv"/ >
<entry key="process.outputSuccess" value="\\${system.environment}\Logs\Contact\contactUpsert_success.csv"/>

I have done this using the spring framework before but have been unable to get it working within the data loader.  Thank you in advance for your time.

Hi , 

See the blog below, 

Spring bean variables with data loader command line

If you use Apex Data Loader from the command line, you will know that changing usernames, passwords, and environments is a bit painful if you have more than one bean in your process-conf.xml file. Adding variables should be easy but getting the syntax right without an IDE is not. I couldn't find much help on the web so a Java guru colleague came through with the following fix.

In the head of the process-conf.xml file, below the <beans> tag and above the first <bean>, add the following code to declare a "user" variable with a specified Salesforce username:

<bean id="user" class="java.lang.String">
<constructor-arg value="yourusername"/>
Then in the map entries replace

<entry key="sfdc.username" value="yourusername"/>

with the following code:

<key> <value>sfdc.username</value></key>
<ref bean="user" />

Do the same in each of the process beans, and use the same technique to declare variables for your environment, encrypted password, and output folders.

To share a properties file external to your process-conf.xml file, use the Spring PropertyPlaceholderConfigurer as detailed in this techno.blog.




Thanks for the reply Ashish, unfortunately, the first blog example can be handled with the use of the config.properties file.  The second blog post is essentially what I have been trying to do, but it does not seem to work the way the Data Loader application is structured.  In theory, yes it should work...but in reality I have not found anyone including myslef who have actually been able to execute it successfully.
I was kind of hoping I could use the ${env.variablename} syntax simialr to what's used with ant's build.xml file.  

I have a script that runs my dataloader from the commandline.  It looks like:
DrozBook:dataloader tgagne$ cat ~/bin/process 

if [ $# -gt 1 ]; then
	export ARG2=$2
	echo $ARG2

time java \
	-cp $dataloaderdir/dataloader-$version-uber.jar:$dataloaderdir/ojdbc6.jar:$dataloaderdir/postgresql-9.4-1201.jdbc4.jar:$dataloaderdir/sqljdbc4.jar \
	-Dsalesforce.config.dir=`pwd`  \
	com.salesforce.dataloader.process.ProcessRunner process.name=$1 | grep --line-buffered -vi "will be ignored since destination column is empty"

Inside process-conf.xml I wanted to use the argument to change the name of the CSV file I was reading from for an import.
<entry key="dataAccess.name" value="${env.ARG2}" />

But alas, dataloader didn't swallow it.
Caused by: com.salesforce.dataloader.exception.DataAccessObjectInitializationException: File: /Users/tgagne/git/customer/dataloader/${env.ARG2} not found.  Open failed.

The way this is done in build.xml is with the tag
<property environment="env"/>

But sticking it near the top of process-conf.xml just blows-up the stack.

Is there something I'm missing or is it impossible to do such a thing with process-conf.xml?
We looked at this for a good amount of time, but ended up not finding a good resolution.  We decompiled the dataloader source and something with their implementation of spring was blocking other tags from being replaced.  To us it wasnt worth digging deeper to try and resolve at the time.