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.
The recorded webinar “VMforce : Cloud Computing for Java Developers” provides an introduction to Cloud Computing, overview of the Force.com platform, and a sneak peak of VMforce.
The webinar was recorded, and it is available for viewing @
For additional information, tutorials and tips, visit following site and blog:
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
Author : Chirag Mehta & Angelica Buffa
Using FTP servers to store and share files is very common now at days. Most language programs let you develop FTP clients and consume their services.
With Apex, there are three possible approaches to resolve the integration with this kind of file servers:
I – Data Loader CLI – Windows approach.
- Download Salesforce Data Loader Command Line Interface (Read more at http://wiki.developerforce.com/index.php/Using_Data_Loader_from_the_command_line)
- Write a Widows Batch file (.bat file)
- First command in the batch file will be connect to FTP server (ms-dos command ‘ftp’) and then get the necessary files from ftp server to the local folder.
- Second set of commands execute the Data Loader CLI jar and loads step3 retrieved file into Salesforce.
- To automate the execution of the batch, we can schedule the bat file execution using scheduled task feature of Windows operating system.
II – Java Web Service
- Write a Java FTP client, expose it as a Web Service
- Consume above WS into your Salesforce Org using Apex “Browse WSDL” functionality
III – Http Request
- Create a Http Request to the FTP server
- Handle the response using either of HttpRequest and HttpResponse Apex Class
- Ps: The problem that you can face is the size of the files. Please remember that HTTP Request size are currently limited to 100Kb of data, so larger exports would fail unless a mechanism was created to utilize multi-part transmissions.