Community Update: Wiki Pruning, lots of Code Samples and IDE/Workbench/Google news

by Jon Mountjoy on July 15, 2008 at 07:46 AM

It's been far too long since the previous community update. To be fair, I have been doing a fair bit of traveling, mostly on the Tour de Force. Check out our videos from the Dublin event for a taste. In the interim we've released the awesome Google Data API Toolkit, and a new version of the Force.com IDE.

Besides the events, I've been doing a fair bit of blogging and learning about the platform. Right now I'm spending a lot of time pruning the wiki. I hope to make a few improvements, including making things a little easier to find. I've also started to use some of the wiki capabilities such as categories. So for example, here is a page of multimedia items on the wiki. It's not complete yet, but I hope you find it useful. Feel free to ping me about the wiki and any changes you would like to see (or not to see :-) ).

Enjoy the rest of this post, wherein I point to most of the new items that have appeared on developer.force.com recently.

Regards,
Jon

Resources

We have a couple of new resources for you:

Code

Check out the following new code samples:

Many thanks to Andrew Waite and Rasmus Mencke for these great samples.

Blogs

Here are some blog posts that caught my eye:

Multimedia

The following events/screencasts/webinars are now available for your viewing pleasure:

Upcoming Events

From our event calendar, we have the following events that may interest you:

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Intercepting Workflow Outbound Messages in a Ruby Server

by Jon Mountjoy on July 8, 2008 at 06:31 AM

I'm learning about workflow and approvals, and I've just got a Ruby server intercepting SOAP messages that are sent via the Force.com workflow system when changes are made to an object.

The Basic Idea

The way I see it is that you can use the Force.com Workflow system to carry out actions under certain conditions on particular objects. So for example, if object Y has its field X set to Z then perform action Q.

The conditions I chose were on the Contact object, with an evaluation criteria of "Every time a record is created or edited." The action I chose was what this blog post is all about: an outbound message. Essentially you can have the Force.com server send out a SOAP message to your destination of choice with data.

This is very powerful functionality, and takes 3 minutes to set up. You can imagine using it for integration between Force.com and some other external system. You can also perform simpler actions, like updating fields, sending emails and so on. All of this happens automatically, and the actions are managed by the server.

Here's how I set this up to send a SOAP message to a Ruby server sitting on my own remote site.

Setting up the Workflow

Go to Setup/Workflow & Approvals/Workflow Rules/New Rule. Select the Contact object, give the rule a name such as "ServerPingChange", set up some evaluation criteria (I chose "Every time a record is created or edited") and a Rule Criteria (I set mine to "Formula evaluates to true" and have a formula of "true"). Hit "Save and Next" and "Done".

That's it. As you can see, you have a lot of control over the conditions under which the workflow rule will be selected. Now let's go ahead and create the action, which are reusable. That is, if we create an action for Rule Y we can also use it for a different rule too.

Setting up the Action

Outbound Message_ MyOutboundMsg ~ Salesforce - Developer Edition.jpg Hit "Edit" under "Workflow Actions" for the workflow rule you just created, then "Add" "Outbound Message". I gave it a name of "MyOutboundMsg" and for endpoint address you need to select your server name. For example, I used http://www.jonmountjoy.com:8080/ (Don't use my server please ;-) ). You can then select which fields you want to send along in the message. I simply chose Id and Lastname.

That's it! You'll now see a cool "Click for WSDL" which you'll want to do. Download that WSDL file - that defines what your SOAP server endpoint needs to look like. You'll want to activate your workflow rule now (hit "Activate" on the rule), and set up your security now in Security Controls/RemoteSites to ensure that your remote server has access to Force.com.

Now whenever you add/modify a contact, a SOAP message will be sent to your endpoint.

Monitor

You can check your progress so far. Go ahead and edit a contact for example. Now go to Setup/Monitoring/OutboundMessages. You'll see a log of outbound messages because, of course, at this point you have nothing listening on the other end.


Outbound Messaging Delivery Status ~ Salesforce - Developer Edition.jpg

Setting up your Ruby Server

I chose to use Ruby here. (I'll be trying this some day with Java and the Spring Framework if there's any interest.) Here's how I set up my Ruby server. It's somewhat convoluted as I had to set up a private gem home as my server is hosted and I don't have full control over it. Hopefully this will help folk doing the same.

Modify your .profile to accommodate a location for your gems if your server is hosted. I have mine include the following lines:

export GEM_HOME=~/ruby/gems/
export RUBYOPT=rubygems

Then I installed the soap4r gem, which provides the basis for my SOAP server. I did this by running

gem install soap4r

(Is there a better SOAP server out there for Ruby? This one looks pretty stale, although it works for my purposes. )

Now in a directory in which you have the WSDL downloaded from the previous step, execute:

~/ruby/gems/bin/wsdl2ruby.rb --wsdl wsdl --type server

You should now have a basic SOAP server! Let's tweak:

I modified NotificationService.rb like so, so that it listens on the correct port (the line is near the bottom of the file):

server = NotificationPortApp.new('app', nil, '0.0.0.0', 8080)

I added a line to DefaultMappingRegistry.rb so that it starts:

require 'default.rb'
gem 'soap4r'
require 'soap/mapping'

Unfortunately it took me an exceedingly long time to figure out that piece of magic. Why I need, I have no idea...

Now you can start hacking the piece that really matters, defaultServant.rb, which is the Ruby code that runs when a message is received. The soap4r gem makes it pretty simple to interact with the SOAP. Here's my final code that simply prints the incoming id and lastname:

 def notifications(request)
    p "Jack was here"
    p [request.notification[0].sObject.id]
    p [request.notification[0].sObject.lastName]
 
    ackResponse = NotificationsResponse.new
    ackResponse.ack = true
    return ackResponse
  end

The only tricky bit is ensuring that you create and return an ackResponse object. Without this, you'll receive the message but Force.com will keep resending it because it hasn't received a successful acknowledgement response.

Finally, run your server:

ruby NotificationService.rb

That's it! Here's the output I get whenever I modify the contact Tim Barr:

mountjoyj@sobek:~/oof$ ruby NotificationService.rb 
"Jon's Workflow Outbound Message Server Received:"
["0035000000N1GwjAAF"]
["Barr"]

Summary

I found outbound messaging pretty straightforward and easy to use. It took 3 minutes to set up the workflow rule, criteria and SOAP message, and I had great fun pulling my hair out getting the Ruby server to run :-)

Have fun!

History

I started learning this stuff as I was going to give part of the Workflow talk at Tour de Force in Dublin. Rick Greenwald ended up giving the entire presentation, thankfully. I don't know enough yet, and Rick knows it all. Thanks Rick!

Technorati Tags: , , ,

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Announcement of Google Data APIs on Force.com

by Jon Mountjoy on June 23, 2008 at 09:00 AM

The Force.com Toolkit for Google Data APIs has just been announced here at Tour de Force Santa Clara. The goal of the toolkit is to make Google App services, starting with Spreadsheets, Documents and Calendar, first class citizens of the Force.com environment. I got my hands on the toolkit yesterday and wrote a little integration app. Essentially I created events on my Google Calendar from within my Force.com app, and listed those events too. Here's what the code looked like to list events: 
CalendarService service = new CalendarService();
service.setAuthSubToken(fetchToken()); 
GoogleData.Calendar cal = service.getCalendarByTitle('TechCalendar');
GoogleData feed = service.getFeed( cal.alternate );
for( xmldom.element e: feed.entries) 
 titles.add(new MyEvent(e.getValue('title'), e.getValue('content')));
As you can see, it takes about 5 lines of code to connect to a calendar and iterate through the events. Creating an event is similarly straightforward: 
 CalendarService service = new CalendarService();
 service.setAuthSubToken(fetchToken()); 
 GoogleData.Calendar cal = 
     service.getCalendarByTitle('TechCalendar');
 Event ee = new Event(
   subject = 'Cool new Event',
   description = 'Clouds in the sky',
   ActivityDateTime = system.now(),
   DurationInMinutes = 120
 );
service.insertEvent(cal, ee);
The only part that requires brain cycles in getting any of this to work was the authentication structure, which is part of the Google Data API architecture. Essentially you (as the Google Calendar user, for example) have the authenticate your application with Google, which requires a few page redirects and token exchanges. At the end of the day you end up with a token that you use in all subsequent interactions (see the fetchToken() above). There's plenty of documentation (and test coverage) to get you going, and as the code is open source you can go and scrabble around for yourself too. Here are all the bits: This opens the door to a lot of opportunities, so get coding! Update 2008-June-24: See Ryan's post on this over on the Google Data API Blog.

Technorati Tags: , ,

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Community Update: Intros, Tour de Force, Visualforce

by Jon Mountjoy on May 30, 2008 at 05:03 AM

I'm a new member of the force.com team, and I'll be working here as the community manager and editor-in-chief of developer.force.com. As a result, I hope to be touching base with a lot of you developers, ISVs and admins out there, as well our internal salesforce.com employees. I'll also be working at developing our blog and content strategies, infrastructure and more. There's a lot to do, and I'm keen to help our thriving community grow even bigger. Feel free to ping me at any time about the community, with any suggestions, complaints or comments (jmountjoy at salesforce dot com) or join me on Twitter or other data streams.

I will be producing a community update like this every week or two, highlighting forthcoming events (check out the awesome Tour de Force website with new events in the USA, Ireland and Japan), community members (see Anshu), webinars (Move Beyond S-Controls), interesting board threads, things that catch my eye (like the Dreamforce Session Idea site), external sites (Simon, Joe, Steve and many more) and so on, so please stay tuned.

Regards,
Jon

Resources

We have a couple of new resources for you:

  • A short Visualforce Components Demonstration by Adam Gross shows off some of the capabilities found in Visualforce Components. This is going to big: reusable, modular, user interface components. I need to create a directory listing components that we can start finding them all. Done!
  • A new Visualforce resource page recently went live, pointing to reference material, tutorials and webinars to get you up to speed on the technology.

Blogs

In the blogs, I'd like to welcome new blogger Anshu Sharma. Anshu blogged about being In India, with Force(.com)!, and some of the questions he encountered during a talk he gave on PaaS and Force.com.

Also in the blogs, Ron Hess tells us about Coding The Cloud at Google's I/O Event, where he's presenting on integrating force.com apps with Google GData interfaces. I'm also keen to see how our developers use the new Google Earth API. We've seen plenty of Google Maps mashups - now how can we use Google Earth too?

Finally, Peter Coffee has some interesting thoughts on what it means to be Disconnected. He makes the point that "..it's not the problem of any single technology provider (or even any particular subset of the tech provider ecosystem) to solve the problem of staying up and running even if your public network link is intermittent."

Upcoming Events

From our event calendar, we have the following events that may interest you:

Education Services

Education services have two upcoming courses:

Technorati Tags: , ,

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

Coding The Cloud at Google's I/O Event

by Ron Hess on May 16, 2008 at 07:11 AM

Ever since the introduction of Apex SOA / Callouts last spring, I've wanted to revisit the GData integration sample code that was originally built using JavaScript. Now with the upcoming Google I/O developer event in San Francisco on our speaking calendar, I am putting the finishing touches on a great Apex to Google demo. In my Google I/O presentation, I will explain and demonstrate how you can quickly achieve a custom integration between your force.com platform apps and Google GData interfaces. Yes, Apex speaks REST, and you can learn how. Salesforce.com is honored to be one of the companies that Google has invited to speak at its upcoming, first-of-its-kind, developer gathering. Bing Yang from our R&D team will be speaking there too in another GData session that will cover authentication mechanisms. 

With the introduction of Salesforce for Google Apps, several integrations are already available out-of-the-box. However for a Force.com developer, it's just the start.  What if you want to integrate your platform app with Google Spreadsheets or Calendars?  Well, the good news is that there are plenty of features in both force.com and Google to build a robust and high performance GData integration that is custom to your force.com app.

This is what CODA has done in CODA2go, their new force.com financials app -- they include a feature to export your invoices into Google spreadsheets where you can edit them in a normal sheet format. 

If you haven't already registered for I/O, please check out the sessions and speakers and get ready for a deep dive into various Google developer technologies, with a bit of force.com platform thrown in. Stop by the demo area and say hello!

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Tour de... eBay Developers Conference!

by Adam Gross on May 13, 2008 at 02:43 PM

We have always been big fans of eBay, and especially the work they have been doing with their platform - so we were delighted to be invited to keynote and present at the eBay Developers Conference June 16-18th in Chicago. There has been a lot of great work between our communities already, including Infopia's e-commerce app and the Skype mashup - but when you add in the new integration features of Apex and Visualforce, along with a host of APIs from Skype, Paypal and other eBay services you can quickly imagine some pretty interesting new apps.  Join us there to learn the technical details of how to bring Force.com and eBay together (and show us what you've built since our Chicago Tour de Force last month!)

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Developing the Cloud at DevX

by Dave Carroll on January 21, 2008 at 02:42 PM

Head on over to DevX to read a Special Report feature on SaaS and Building On-Demand Applications in the Cloud. This report consists of five articles around building applications for On-Demand including Force.com, Amazon and Bungee Labs.

I'd like to especially thank E.J. Wilburn of CRMFusion for contributing a great article and tutorial for this Report. You can read his article Getting SaaS-y with Apex and VisualForce.

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Data Loader open source - latest version posted to SourceForge

by Rick Greenwald on August 13, 2007 at 10:28 AM

We have posted the source code  for Data Loader 10 on SourceForge,net, in both CVS format and in a ZIP file distribution. This new posting is a significant advance over the version of Data Loader previously available at SourceForge 18 months ago, and includes a custom web service stack built for high performance salesforce interactions.  You can freely download this Java application to extend the functionality of Data Loader, or just to see a good example of how we use the Apex API to move large amounts of data in and out of the salesforce database.  As with any open source software, you can redistribute this code, but please keep in mind that we only support the existing version of Data Loader, not any modified or extended versions based on the open source code.

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Part II of the Salesforce Enterprise Integration Series is online on ADN

by Markus Spohn on July 27, 2007 at 08:35 AM

Check out Part II of the Salesforce Enterprise Integration Series that we just posted on the Apex Developer Network: http://wiki.apexdevnet.com/index.php/Enterprise_Integration_Series
Part II discusses the Next Generation Integration Services Apex Web Services and Salesforce SOA that will be released by Salesforce.com later this year. Don't miss it and stay tuned for more...

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

New Salesforce Enterprise Integration Series on ADN

by Markus Spohn on July 11, 2007 at 01:32 PM

Are you interested in learning more about how to integrate with Salesforce.com? Check out the new Enterprise Integration Series that we just launched on the Apex Developer Network:
http://wiki.apexdevnet.com/index.php/Enterprise_Integration_Series
Part I of the Series will give you a general overview of existing integration methodology & techniques in Salesforce.com. Part II will talk about next generation integration services like Apex Web Services and Salesforce SOA that will be released later this year by Salesforce.com. Stay tuned for more...

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

SalesForce.com and BEA Workshop: Apex API the Easy Way

by Kavindra Patel on July 2, 2007 at 09:33 AM

Over the weekend, I was chatting with Bill Roth who heads the tools team at BEA. He has been doing some interesting things with BEA Workshop and Salesfore.com and He wanted to pass on a message to the ADN Community.

“I have been a fan of SalesForce.com for a long time, and have subscribed to the ADN developer program for several years, since my days at E.piphany. It helps that SFDC have built out some very well thought out APIs and a really interesting platform strategy. In this blog, I will show you how you can use BEA Workshop to build meaningful web services apps by connecting to the SFDC APEX APIs.  It’s a how-to on using web services to connect to your SFDC account.” -Bill Roth

Please let us know, if you would like more in-depth content on this or related topic.

Comments (0) | TrackBack (0) Save to del.icio.us Digg this story

Using Adobe Flex to Build Rich On-Demand App - Follow Up

by Dave Carroll on June 27, 2007 at 12:56 PM

Thanks to all of you who attended the webinar today.  We really enjoyed presenting the exciting combination of Adobe Flex/AIR and the salesforce.com platform.  I have created a wiki page to contain the code that I demonstrated today.

The sample is simplistic but illustrates some key concepts when using Flex and the Flex Toolkit for Apex.  First is the data binding piece.  Flex natively supports collections as the data source for data binding.  The Flex Toolkit for Apex returns a collection as the result of a query.  This makes simple binding extremely easy.

Another concept that is key, but was not illustrated in the webinar, is the ability to create your own components based on (inheriting from) the standard SDK components.  This makes modifying the behavior of items like the Grid component very easy.  This is especially true when compared to other "traditional" RIA technologies.

Grab the trial version of Flex Builder, or better yet, take advantage of the discount code presented in the webinar, and try some of this stuff out yourself.  I am confident that you will not only find it useful but fun as well.

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

Sforce Open Source OleDb Driver

by PK on October 17, 2005 at 07:16 PM

The guys at ForceAmp have made their OleDb driver for Sforce Open Source.  This is also built on the Office Toolkit.  Neat stuff.

From their post:

If you are looking for a way to access Salesforce.com data via SQL SELECT statements or need to quickly replicate your Salesforce.com data into local SQL Server tables, check out the DBAmp open source project at http://sourceforge.net/projects/dbamp .

If you don't have SQL Server, you can download a free version from Microsoft called the SQL Server 2005 Express Edition and use it to host DBAmp.

You can watch a Dreamforce presentation on DBAmp at http://www.crmsuccess.com/browse/content_detail.jsp?id=006300000034wbZAAQ&flid=02n300000000ID7AAM&slid=&tlid=02o300000000haWAAQ

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

Sforce Data Loader: Using the command line interface

by Andrew Waite on June 13, 2005 at 03:13 PM

The Sforce Data Loader can be scripted to run from a command line by following these steps:

1. Prepare your system
To use the Command Line Interface ("CLI") of the Sforce Data Loader your target machine (the machine upon which the loader will run via the CLI) needs to have the Java Runtime Environment ("JRE") v1.4.2_03 or greater installed and configured. JRE 1.5 is not supported.

The CLI of the Sforce Data Loader uses the same processing engine as the Graphical User Interface ("GUI") provided in the Windows installation.

In order to use the CLI you must first install the Sforce Data Loader on your Windows computer using the .exe provided in setup of Salesforce.  

If you intend to use the CLI of the Sforce Data Loader on the same machine on which it is installed you need not move any files. In this case you can skip to "3. Setting operation parameters" below.

If the target machine for your scheduled process is not the same as where you installed the GUI using the .exe then you need to perform step 2.

2. Copy the loader engine and files

Once the GUI is installed, open the directory you selected during install, the default is:

C:\Program Files\salesforce.com\Sforce Data Loader

Copy the sforcedataloader.jar file located in this directory the working directory of your batch process on the target machine. In this working directory, create a folder named "conf" and copy everything in C:\Program Files\salesforce.com\Sforce Data Loader\conf to this directory.

Alternatively, you can  download SforceDataLoader.zip which  contains the jar file and conf  directory for those that can't easily install the windows gui.

3. Setting operation parameters:
Depending on your operation you must provide a minimum set of parameters to run. These parameters can be specified in either the config.properties file in your conf directory or as command line arguments. Modify the parameters according to your operation and desired behavior. Sample required parameters for a basic extract operation of Account records are as follows:

# Required parameters for processing an Extract operation
username=you@yourcompany.com
password=yourpassword
operation=extract
extractionSOQL=SELECT Id,Name FROM Account
extractionTarget=account-extract.csv

Insert/Update/Delete operations have a separate set of required parameters. A sample of the required parameters for a basic input operation for Account records are as follows:

# Required parameters for processing an Insert operation
username=you@yourcompany.com
password=yourpassword
operation=inserts
batchSize=200
mappingFile=conf/default.sdl
dataAccessObject=account-insert.csv
entity=Account
outputSuccess=success.csv
outputError=error.csv

Best Practice: Run the process once manually using the GUI, specifying the parameters as desired. The settings from the manual execution will be saved to:

C:\Documents and Settings\<windows username>\Application Data\salesforce.com\Sforce Data Loader\config.properties

If the operation is not an extract, be sure to save your map as well('default.sdl' above).

Copy that config.properties file and your map (.sdl) to the conf directory in the working directory of your target machine.

Modify the values in config.properties to contain valid system paths for the appropriate files on your target system (the examples here assume a linux/unix system).

4. Prepare and execute

Refer to the section titled, "Using the Command Line Interface" in the Sforce Data Loader User Guide for detailed information to prepare the command and run the data loader from the command line. 

After the load is completed, the program will export your parameters to the config.properties file. This process will not include any comments. If you want to maintain your properties for reference, save them under a different file name. Note: this resave will not include the password property.

Best Practice: If your process is repetitive you should be passing the password as a command-line argument.

You should also pass in the outputSuccess and outputError parameters when performing inserts/updates/deletes and extractionTarget when performing extract as the loader will overwrite files found to have the same filename.

5. Parameter Reference

####### BEGIN FILE  ############################
# Loader Config Parameters
#
# This can be copied as your sample config.properties file. Lines
# beginning with a '#' indicate comments and will be ignored by the
# program.

###### Required for All operations ####################
#
# Salesforce user account credentials. Your account must be active
# and you will see better performance if you run as a System
# Administrator
username=you@yourcompany.com
password=yourpassword

# The operation type being performed. A valid value is
# 1 of: extract, inserts, updates, deletes
operation=extract

#
####### Required only for extract ###################
#
# The query that defines the scope and type of data to be returned
# from sforce. For more information on the Sforce Object Query Language
# please see the API documentation on sforce.com
extractionSOQL=SELECT Id,Name FROM Account

# The file that will contain the data extracted from Salesforce
extractionTarget=account-extract.csv

#
####### Required only for Inserts/Updates/Deletes ###########
#
# The path to the file that contains the field mapping for your
# operation.  It is recommended that you use the Sforce Data Loader
# GUI to generate the mapping file. Note: you must map the Id field in
# updates/deletes operations and you must NOT do so in inserts
mappingFile=conf/default.sdl

# The path to the file containing the source data
dataAccessObject=account-update.csv

# The name of the entity that is the target of the data. This is
# any accessible object in the API. Note: if this is a custom object
# you must append the '__c' suffix (two under-scores, then the letter c)
entity=Account

# The path to the file that contains the success output
outputSuccess=success.csv

# The path to the file that contains the error output
outputError=error.csv

# The size (number of records) of each request
batchSize=200

#
####### Optional parameters #####################
#
# Please refer to the Sforce Data Loader User Guide for more
# information regarding these parameters (default values are shown)

#endpoint=https://www.salesforce.com
#lastBatchRow=0
#assignmentRule=
#rowToStartAt=0
#extractionRequestSize=2000
#insertNulls=false
#timeoutSecs=60
#proxyPassword=
#proxyHost=
#proxyPort=
#
###### END OF FILE #######################

Comments (104) Save to del.icio.us Digg this story

Sforce integration whitepaper

by PK on March 30, 2005 at 04:14 PM

There is a new sforce integration whitepaper that does a great job of describing how a company might integrate their front-office CRM to their back-office accounting and ERP counterparts. The document explains business process, data model, connectivity, and technology considerations you’ll want to think through. If you’ve been considering an integration project, this might be just what you need to gain clarity and kick things off.

Comments (1) Save to del.icio.us Digg this story