We have had a lot of great interest in Cloud Loader, so the next question is "How do I start using it?" Well, here is a simple 5 Step guide to get going with Cloud Loader to start doing integration for $0.10 an hour (or less with a reserved instance).
Step 1 – Sign Up for EC2
Step 2 – Sign into the EC2 Management Console
The Console is where you can go to create and manage your EC2 Instances. Remember these are virtual servers and the console allows you to give them a static IP (Elastic IP), control the Security Group and stop and start your instances. First off you need to create a new instance of the Cloud Loader AMI.
Step 3 – Create a Cloud Loader Instance
Click on Instances→ Launch Instance→ Community AMIs and search on “Cloud_Loader” to find the Cloud Loader AMI. Click the Select button.
After clicking Select you need to specify some specifics about your instance. You will only need one instance and it can be a “Small” instance which will be fine to run the Cloud Loader.
Next click on “Create” next to the Key Pair Name option, enter a name for your key pair and download the key pair. This will be required to SSH into your Cloud Loader instance.
Next you need to pick a Security Group for the instance. You can use the default one or optionally specify other settings (which ports will be open). EC2 by default has all ports closed except 22 for SSH.
Last Click “Launch” to launch your instance. This will take 3-4 minutes to boot and fully launch.
Step 4 – Connect to your Instance
If you are using a PC you will need to use an SSH client such as PUTTy to log into your instance. Click here for Windows instructions.
If you are using a Mac you can use the native terminal to connect. Click here for detailed instructions on how to set up your certs and bash profile.
Step 5 – Configure your Instance
(Remember this is built on Apex Data Loader, so look here to learn more about it)
• After logging in go to the /usr/local/dataloader directory
• Create an FTP user on the Cloud Loader instance to use for the inbound FTP of data (the .csv file you want to load into Salesforce).
• Edit the config.properties file with your username and password for SFDC
Note: You will need to include your security token at the end of your password if you don’t whitelist the Amazon Elastic IP within Salesforce
• Edit the process-conf.xml file with the data loader processes you want to run
• Edit the automate-dl script to configure the email address you would like to use to send reports to.
• Setup a cron to run the automate-dl script (the way you schedule automated processes in UNIX)
Final Notes
Once you have tested this approach it is likely you will want to modify the script or approach to suit your own business need. With EC2 you can use Cloud Loader as a base AMI and then configure your own AMI based upon it with your own unique additions.
You may also like to utilize EBS (Elastic Block Storage) with Cloud Loader to have persistent storage of your configuration files, incoming integration files or log files. We plan to add this functionality in an upcoming release. If you have any further suggestions for Cloud Loader, please email us at: support@modelmetrics.com
Follow Reid: Twitter.com/ReidCarlberg. A few people on my team contributed to this at different points. Props to Shoby Abdi for getting it all together. Twitter.com/ShobyAbdi.
I recently ran into a challenge regarding a Salesforce-to-Salesforce mashup. We didn’t want to move the data (traditional integration, S2S/org to org sharing), but we also wanted to keep the solution as "clean" as possible — the simplest possible implementation with the fewest possible moving parts. This article is a walk through of how we solved it. I’ve included some lessons learned at the bottom.
Background
* Our goal was to create a mashup without a third party mashup provider.
* Although Apex facilitates callouts to external services, the API specs clearly state that Apex callouts are not designed to call full Salesforce.com API based webservices, so we knew we had to avoid that route.
* We wanted to have avoid creating a large number of dedicated Apex "stubs" on the data provider org.
* In addition to pulling information from the data provider org, we wanted to be update to update a record.
Here are the two screen shots that we ended up with. Note that both are on the calling org. In the first, you can see where a query has resulted in data coming back. In the second, you can see where we’ve updated a field and refreshed the query results. Neat!
Screen 1: The query "Select Id, Name, BillingStreet from Account where BillingState = ‘CA’" results in two records.
Screen 2: Here you can see the results of the first query, as well as my entries in the "update" section. I’m using the data I received from my query to determine which records to update.
Screen 3: And you can see here where "GenePoint" the company I select based on the ID has moved from "345 Shoreline Park" to "123 Reid Updated Blvd." (Class A digs if they ever existed.)
The Basic Process
1. Create a stub in the org that will provide the data. This should be a global webservice class. Save the generated WSDL for this class.
2. Import that WSDL using WSDL2APEX in the org that will consume the data. It will create a matching objects.
3. Create a utility method that handles authentication for you. You won’t be able to use either the partner or enterprise WSDL in your Apex so you’ll need to roll your own. We have a quick & dirty version below.
4. You’ll need a Visualforce page and a Visualforce controller to tie everything together. Those are pretty trivial so I’ve left them out of this post (but they’re in the code, below).
The Code – Data Provider Org
Code is posted in a separate file. Download it!
We started by creating a "DataProviderRequest" Apex Webservice class that executes queries and returns data.
Next was the Data Consumer. Note that this has both a "getSobjectData" and an "updateSobjectData" section.
Code contains working examples of:
* Dynamic SOQL / Dynamic Object Udpates
* Login to one SFDC org from another.
Lessons Learned
* You need to create your own intermediate data type to move content back and forth between the orgs. If you use SObject, you’ll have a schema which includes all of the SObject sub-types. Not very useful (and just too long).
* Performance is reasonably good although not perfect. Caching the session ID rather than logging in every time would improve performance.
* This is a reasonably good alternative to traditional integration methods but IMHO I would generally rather use things like Salesforce to Salesforce if the use case supports it.
* Getting this to production ready will require some tweaking but my over all thought is that it shouldn’t be too hard.
So Dan Galorath has noticed Force.com and started to quantify the savings he believes users can achieve with it. It looks like Marc Benioff sent the results around to all of SFDC. With good reason – Galorath estimates 30-40% lower costs when compared to Java.
Very cool. And consistent with my experience.
In an explanatory article, How Galorath Quantified the Salesforce.com Platform, there are a couple of interesting nuggets hidden all the way at the bottom:
"For applications that are consistent with the built in capabilities of the SalesForce.com Platform, there appears to be about an 80% reduction in the actual development effort. Because of the ability to create with point-and-click operations to support prototyping, the requirements and design effort is reduced with estimates ranging from 10% to 25%."
You read that right: 80% reduction in development effort. Wow.
And, since I’m a nitpicker, I’m going to pick on one thing. Galorath writes:
"APEX does not provide UI services or support external web service calls, the primary focus is to provide data oriented transactional services – more like Stored Procedures in Oracle or SQL Server."
The web services call issue is just incorrect. APEX absolutely supports those. And the UI services section — I think this is splitting hairs. APEX doesn’t, but Visualforce does.
Oh and since I’m really a nitpicker, it’s not "SalesForce.com" with a capital "F". It’s lower case. C’mon people.
Glad to see Force.com getting some good formal attention. Now if we could just get some Z notation animators for it.
Blog
Contact Us
