When integrating any non native application (JAVA or NET or ..) with salesforce, you need to have the salesforce API library in place that can be referred/used as a referenced library in project being developed. This library is the the one that acts as face to salesforce i.e., intermediary between your application and salesforce.
Simple yet important step of such type of integration is to generate stub code (jar file) from wsdl (salesforce enterprise or partner wsdl) and though such a simple step, we (at least I) always forget (or I should say cant recall easily) the step on how to generate same.
Below are three easy steps to generate stub code (jar) from a wsdl:
java -classpath wsc-xx.jar com.sforce.ws.tools.wsdlc *wsdl* *jar.file*
java -jar wsc-23.jar *wsdl* *jar.file*
wsdl is the name of the WSDL file
jar.file is the name of the output jar file that wsdlc generates
You can include an optional argument: -Dpackage-prefix=myprefix
With this you are all set with stub code / library and ready to make soap API calls to Salesforce.
Came acrorss a site Database.com, is that a new baby to be delivered in Today’s Dremaforce’10 conference?
Read more @ http://www.database.com/
The VMForce value proposition:
- Download Eclipse and SpringSource
- Signup for a Salesforce Development account and define your data model
- Write your Java app using objects that serialize to Salesforce
- Drag and drop your app onto a VMWare hosted service to Force.com to deploy
The partnership breaks down as:
- VMWare hosts your app
- Salesforce hosts your database
The 2 are seamlessly integrated so that Java Developers can effectively manage the persistence layer as a black box in the cloud without worrying about setting up an Oracle or MySql database, writing stored procedures, or managing database performance and I/O. For larger organizations already using Salesforce but developing their custom Java apps, this opens up some new and attractive options.
CIO’s are being bombarded with virtualization as a viable cloud computing solution, so I think Salesforce has wisely taken a step back and taken a position that says
“We do declarative, hosted databases better than anyone else. Go ahead and pursue the virtualization path for your apps and leverage our strength in data management as the back end”
The post ends with two really good questions …
The connection between VMWare and Salesforce is presumably via webservices and not natively hosted in the same datacenter. Does this imply some performance and latency tradeoffs when using VMForce?No. Per the comment from David Schach, the app VM is running in the same datacenter as the Force.com DB.
It strikes me as quite simple to develop Customer/Partner portals or eCommerce solutions in Java that skirt the limitations of some Salesforce license models when supporting large named-user/low authentication audiences. Will Salesforce limit the types and numbers of native objects that can be serialized through VMForce