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:
- Download Enterprise (Partner) WSDL by navigating to Setup -> API – > Enterprise (Partner) WSDL (right click and save file as “abc.wsdl”, ensure extension “.wsdl” is there).
- Download Force.com Web Service Connector (WSC) . The Force.com Web Service Connector (WSC) is a high performing web service client stack implemented using a streaming parser. WSC also makes it much easier to use the Force.com API (Web Services/SOAP or Asynchronous/REST API). You can download a pre-built WSC jar file from: http://code.google.com/p/sfdc-wsc/downloads/list
Now generate Stub Code from a WSDL. Run wsdlc on the WSDL you have downloaded:
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
- Now write your client application. Add wsc-xx-min.jar and jar.file (generated by wsdlc) to your classpath, then compile and run your client application.
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/
Jesper Joergensen has a good blog post that answers many important questions around VMForce. To add, Mike @embracingthecloud lists following really good thoughts about VMForce.
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