At long last, the oft-rumored VMForce has been officially announced.
Huh?
VMForce is a technology brought about by a partnership between salesforce.com and VMware, the leader in virtualization technology. VMForce enables Java applications to run on Force.com infrastructure, the robust development platform built by the folks at salesforce.com.
What does all of that mean?
Java is one of the most widely used development languages in the world. It is a mature technology with millions of active developers, with more applications running than can likely be counted. With VMForce, many of those applications can now be migrated easily to run in the cloud.
These applications will then be available anywhere, on almost any device. They are instantly social, searchable, and scalable. And since they’re on Force.com, you get great security and visibility into uptime.
Posted a couple of minor updates to Cloud Converter, mostly small bug fixes that affected the metadata explorer feature. If you already have it installed as a web tab in your org, there’s nothing you need to do. You automatically have access to these. Enjoy!
I recently listed the desktop version of CardLasso on Adobe’s AIR Marketplace. If you haven’t heard of AIR, check it out on the Adobe site. It is the “Adobe Integrated Runtime” which allows you to run RIA apps on your desktop and distribute them with the ease of a web app. Our AIR version of CardLasso is targeted at the Tradeshow user, and allows you to quickly gather business cards when you have no internet connection and save them locally. You can sync them up to Lasso2Go later back at Starbucks or the hotel.
It seems like not a lot of people know about the AIR Marketplace so I wanted to write a quick note to raise awareness and let you know about the listing process.
First off, I really like their approach. You can use your existing Adobe ID to create a publishing account on the marketplace, this took 10 seconds.
Next you enter publisher information to tell everyone a little about your company and upload a company logo. Very fast and easy. I was immediately approved as a publisher.
Then I filled out the listing for our application which included all the standard info you would expect, description, logos, links to download the app, etc… (See below)
The only hard part about the listing process was sizing down graphics and screen shots to fit the requirements, but not a big deal.
Then I clicked submit.
Literally less than an hour later I had an email from Adobe with a few questions and suggestions on my listing. I made the suggested changes and our product was live.
It was great to list a product on an online store and have it live a four hours after starting the listing process. Granted it doesn’t have the volume that the Apple AppStore has, or the security implications that the Salesforce AppExchange listings have, but both Apple and Salesforce could learn a few things from how Adobe approaches the listing process.
It’s been live for a few days, check it out here and add a review to let us know what you think.
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
I’ve been working on a new feature for Cloud Converter, the ability to import an app from an Excel spreadsheet. Here’s a walk through. You can use this for free, link code at the bottom.
You can add this to your org — DE, EE, UE — by creating a web tab with this URL:
Note that this is a beta release — you should treat it as such. I recommend you try it out on a dev org or in a sandbox before doing something in a production org.
Also, you can see it’s hosted over on Amazon Web Services. It’s always possible that the URL will change to something more Model Metrics Esque when it goes GA at some unknown point in the future.
So why do I need a server again to integrate with the cloud?
Historically one of the arguments against SaaS, or now “The Cloud” was that integration is difficult or expensive. Several great providers have emerged in this space to make integration with cloud platforms inexpensive and more recently, even cloud based. These approaches are great for many companies, but as you know one size doesn’t fit everyone and many companies don’t want to bring in another vendor.
Salesforce has made integration somewhat of a commodity with it’s constant improvements to the DataLoader application. Most of you are probably familiar with it, but if not, it is a Java based client side tool that allows you to load data into Salesforce. It can handle all of the basic CRUD operations you might expect. It now supports direct database access as well so you don’t have to rely on .csv flat files as you did previously.
The other great thing about DataLoader is that you can take the JAR file and run it in a scripted and automated fashion to get integration on the cheap. This approach works well to master customer data from an ERP system, or update nightly financials or orders. It can also pull data out of Salesforce to feed a Data Warehouse for example.
The only issue, you need a server to host this puppy on.
As you know the “clouds” are converging and Salesforce, Google and Amazon all play well together. So why not leverage the Amazon cloud to handle this type of integration? Good news, it works great on Amazon, and is freely available for you to use.
Cloud Loader is a free pre-packaged AMI (Amazon Machine Instance) that you can literally have up and running in a few minutes and have data flowing into or out of Salesforce in the cloud. It is based on Data Loader, but is fully automated and even has email notifications buit-in.
Cloud Loader does require that the data coming into Salesforce be available on a FTP server that is accessible from an Amazon EC2 Instance. All you need to do within Cloud Loader is add your mapping file as well as your Salesforce and FTP credentials and you are ready to roll.
Had a great note today from a Salesforce Sales Engineer in Belgium. David wrote:
(After David, I have one more screen shot.)
*****
Just wanted to let you know that I’ve spent some time with the new version of the Cloud Converter code you’ve got up on Code Share : It works like a charm and it will be very useful for us and our customers.
I’ve tested it on a local [MS] SQLExpress Server.
Converts nicely to:
I’m sure you’ve seen this in action before but I hadn’t, it’s very cool. Beautiful usage of our Metadata API. The java code is really easy to adapt to any db or table.
*****
Thanks, David.
This next screen shot shows a few other things — namely, the lookup relationship and long field types.
Today, your business needs you more than ever. The economy is weakening. Competition is intense.. You’ve helped it navigate technologies for years. But the business has immensely complex new challenges today. It needs your help to operate more efficiently. It needs your help to innovate in new ways.
In short – they need you to lead – but they need you to lead differently.
They need you to lead them through radical change.
What do I mean?
Have the wisdom to divide the marketing hype and the FUD from the real story behind cloud computing and utility computing. Despite their catchy names, Larry Ellison’s protestations, and the high-energy sales effort you’ll run into, these are real, they’re here to stay and they make a substantial difference. Your competitors know how to exploit them. Your business needs to, too. This is your responsibility.
Have the courage to rely less on the technologies that have served you well so far. Oracle. Microsoft. SAP. As painful as it is to admit, they aren’t keeping up. And they won’t do anything interesting in this department until enough of you, their soon-to-be-former-customers, leave them. There’s every likelihood they won’t do it then. And some of your old-line competitors will ignore my plea and do the same: nothing. This is your opportunity.
Have the strength to pull your team through the keyhole of this new paradigm. They’ll feel threatened because their old skills aren’t as useful as they once were. They’ll be scared for their jobs. But they’re closest to the problem and the ones who can best help you take the next step. Change is hard. Not everyone will make it. But you’ll need those who can make the switch for the very real, high value add work of transforming your company. This is your challenge.
Have the generosity to share what you know about technological success with the newest drivers of technical innovation in your company – business owners. Cloud computing and utility computing both reduce or eliminate barriers to technology driven innovation, but they don’t eliminate the need for things like validation and requirements gathering. They help technology become more egalitarian, but neither cloud computing nor utility computing know your business. Think disintermediation. Think empowerment. Think coaching. This is your reinvention.
Have the energy to jump in with both feet. Have the patience to put up with some bumps in the road. Clouds are built on solid technology and maturing quickly, but they’re still relatively young. A blip here or there doesn’t mean the sky is falling. Moreover, your efforts to transform the technical backbone of your enterprise will span multiple generations of cloud and utility computing, including future significant transformation that no one even thinks is possible yet. This ongoing radical change – this is your chosen profession.
Take the next step.
Build your next web application on the Salesforce.com Force.com platform. Start with a free developer account. Do it in secret and only show someone when it’s done.
Move a server to Amazon Web Services’ Elastic Computing Cloud (EC2). Start with the very next small project that someone wants to do but you’re worried is going to cost too much. Publish the price difference to the rest of the business.
Do a cost comparison between what you’ve spent on Exchange and what your email would cost to run on Google Apps. Now do that same comparison adding together your total email spend with your total Microsoft Office licensing cost. Google Apps can replace some of it. Launch a pilot.
Do it on your own or with help. Do it because your business demands it. Do it because you’re scared your competition is out innovating you. Do it because you’re tired of worrying about backups and whether or a not a server is running. Do it to grow the value your business delivers without growing headcount.
Developing Cloud Converter has been a great excuse for me to get deeper into the Salesforce.com / Force.com Metadata API.Although working with it isn’t rocket science, I’ve come across a few interesting tidbits I thought I would share.Before I get too deep into this, I should encourage you to read the docs – they’re pretty useful and contain some very useful sample code.
1. Know when to use the standard API’s “Describe” functionality instead of the Metadata API.In general, the various “describe” calls will give you a great READ ONLY view into your metadata.If you don’t need to create, update or delete, use Describe.Otherwise, use the Metadata API. Oh and you’ll want the Metadata API for developer stuff – Apex, Visualforce, etc.
2. Keep in mind that the Metadata API has a different set of limitations and conventions than the standard API.For example, the standard API is generally synchronous while the Metadata API is asynchronous.The standard API lets you do several hundred operations at once.The Metadata API, 10.
3. Object types matter.In the Partner WSDL with the standard API, you use generic SObjects and can often combine object types into a single operation.Not so in the Metadata API.In the Metadata API, when you’re working with Custom Objects, you can only work with Custom Objects.You can’t, for example, mix in Custom Fields.
4.Sequence matters.For example, you have to create a Custom Object before you can create Custom Fields or a Custom Tab.
5.Naming conventions matter.For example, some object use Dot Notation in the name, others use Hyphen Notation – the same as Dot but with a Hyphen.For example, if you want to specify that a custom field should be on a particular custom object, MyField on MyObject, for example, you specify a name of “MyObject__c.MyField__c” and the Metadata API will handle it.On the other hand, if you want to create a Layout called “My Object Layout” for MyObject__c, you would give it a full name of “MyObject__c-My Object Layout”.
6.The Metadata API is hackable.No, not in the War Games way (to be honest, I haven’t tried) – hackable in that you can force it to do some interesting things in ways other than specified in the docs if you get stuck.For example, in Cloud Converter, I decided I didn’t want to go through the trouble of editing the default layout.Instead, I created a new one and used the Metadata API’s “update” method.Worked great!
7.Use the source.I only figured out the hackable part after I spent some time looking at the Metadata XML files you can download from Force.com.They’re pretty easy to read and will very likely clear up any trouble you’re having figuring out how to do what you want to do.
8.The Metadata API appreciates some TLC.You will occasionally need to do things other than the core “create”, “update” and “delete” functions.For example, I found that I had to bounce my Metadata API session from time to time.Once was when I was finished creating the fields and needed to then build a layout. The Metadata API was unaware of those fields until I bounced it.Another example is that I needed to let the system sleep for a bit between creating the custom tab and loading data.A third example was when I wanted to create Lookup fields.When I created those in the same call as the regular fields, it failed.When I segmented them out to their own create call, it worked.None of these were big deals – just something to keep in mind.
9.The Metadata API is very literal.For example, if you create a new custom tab, it will create a tab.And that tab will be hidden from all profiles until you tell it otherwise.There are probably a few other things like this.I’ve been updating this profile setting manually when testing required me to.See #10 for how stupid this was.
10.The Metadata API is powerful.If you’re doing something manually that’s vaguely related to metadata, stop.You can probably do it with the Metadata API and save yourself a bunch of time.For example, if you, unlike me, read the docs when you ran into the profile / custom tab issue in #9, you would have found the “ProfileTabVisibility” object designed to handle just that.
That should get you started.If you run into any other hints or lessons learned I’d love to hear about them.Feel free to email or comment.
I’ve been working on some Cloud Converter enhancements for the last few days.Everything is uploaded to Google Code and ready for you to use.
The details:
After an extremely helpful note from an early user, I have changed the way we connect to databases. It’s now more generic.This is a good thing.You specify your DB driver, credentials and query string and CC does the rest.Remember that you’ll need to import your database driver JAR file if you’re hitting something like Oracle, etc.
You can now specify an “external id” field type.This is extremely useful for tables that include a surrogate id (identity field, etc).
You can now create picklists from any data you like.So, for example, if you have a field which contains “red”, “yellow” or “blue”, and that field today is controlled by the UI rather than the DB, you can convert that into a picklist by specifying the field name and query.
You can now create lookup fields that reference other objects perfect for keeping track of your one-to-many type relationships.
You can use foreign keys to determine your lookup field values.This is the standard upsert based foreign key resolution that’s included as part of the regular salesforce API.
Data can now be loaded as either upsert or insert depending on your needs.
There’s a class that illustrates these pretty clearly – CloudConverterScript_Sample.Open it in your favorite IDE and you can take a look through how it all works.I’ve also added a road map section to the readme.txt to keep track of some longer-term goals.
Note: Cloud Converter is undergoing active development.If you have code modifications that you do not want overwritten by a simple update from Google Code, you should copy those off to a different project before downloading this latest update.
Questions? Comments? Suggestions? Love to hear them.
Blog
Contact Us.png)
