Hi, In the Talend Open Studio, Mediation perspective I don't see any component for jdbc or jpa (http://camel.apache.org/jdbc.html). Is there any other way to use jdbc component here or am I missing something ?
In general, you can use cMessageEndpoint for any Camel component for which there is no explicit component in the tool palette. For example, there is no cJPA or cJDBC or cSQL. If you look at the URI structure in the documentation, you can just configure with the URI. For example, based on the camel-sql component documented here, http://camel.apache.org/sql-component.html, you might configure a camel-sql component with a URI like so "sql1:select first, last from customers?dataSourceRef=ds1" where ds1 is a bean representing your data source.
Thanks for the response. it looks like there must be a simple way around for my scenario. I have a file that stores data in XML format. I want to parse this message and extract the data and store it in database. What will be the easiest way to do this using mediation route. Thanks, Sanjay
Hello Sanjay, well - telling the truth - the easist and quickest way to fulfill the scenario is to use Talend Data Integration jobs (in the Integration perspective). To set up JPA - finally a link I was looking for: http://pic.dhe.ibm.com/infocenter/wasinfo/fep/topic/com.ibm.websphere.osgifep.multiplatform.doc/topi... - I'd advice to use another IDE to build yourself a separate OSGi module with spring/blueprint persistence definition. The TOS community edition won't enable you to do so, you will have to have an enterprise edition or use another IDE. To define elements in osgi context or camel context in TOS CE seems possible by java coding in the cConfig element, but I find easier to build a separate module. Indeed you can do it in mediation routes as well, just - you have to set up the persistence , then manually parse the input XML (ok - using xpath ValueBuilder) and then build persistence entities and store them. And do not forget to handle edge cases (errors, data validation ..). No problem with that, I see more trouble with sustainability of the solution. On another side - If you'd use the taled DI jobs, you will loose the object layer, but you will have a metadata perspective available for managing your schemas in XML and DB and relations to existing jobs. I find it more sustainable (if you change your schema, it will update all related jobs using the updated metadata ). So I'd advice to be practical and do not force mediation routes where there are easy ways through. And for the use case you've described, the DI jobs are FAST (to build, deploy and execute). Carpe diem Gabriel