Mar 31, 2014

Calling Out to a Google API with an Access Token

One of the best things about Google is that they have APIs for all their services. These APIs come handy when you are trying to integrate with Google from within Salesforce. I recently had to do just that, and thought I'd share some of what I've learned...

First of all, I quickly realized that I couldn't use the Force.com Google Data API Toolkit because Google Data APIs are part of an older generation of Google APIs that have authentication methods that are deprecated. Also the Google Data APIs don’t include some of the more interesting enterprise applications that Google has to offer. The newer Google APIs are SOAP based and you need to go through an OAuth 2.0 handshake to authenticate. I used the OAuth 2.0 for Web Server Applications flow, and didn't have too much issues with it (look for a future post on that).

Since Apex does not have a client library for the newer Google APIs, I had to download the WSDL for the resource I wanted to access. I had a couple of issues with wsdl2apex, but was able to get around them. However, after some poking around, I realized that the wsdl conversion didn't work too well after all and had to abandon that path (I think it is related to how wsdl2apex translates attributes and gets around reserved words).

My next move was to make the SOAP call with a normal http callout, which meant that I had to create the XML body to add to the callout. Most of the transaction was a no brainer, but I had a hell of a time figuring out how to include the access token in the SOAP XML. I found the documentation to be either confusing, old, or plain wrong (I did complain about it in one of the boards, and they made some changes since). After quite a bit of trials and errors, I finally got it right though.

So to spare you the extra time it took me to put this together, the following is a very quick sample method that shows you how to set the SOAP headers, including the access token. Please note that this code sample is very simplified - I jammed everything into one method and did not include coverage. Also, in my implementation I am using the XML stream writer to create the body, but in this case included the XML as a sting so it is easier to read.

Mar 21, 2014

Inspecting SOAP Callouts Generated From WSDL (WebServiceCallout)

When working with SOAP callouts from within Salesforce, you can’t view the transaction headers and body xml before you invoke the callout. So if the callout fails or an exception occurs, you have very little information to help you solve the problem.

Here's what you need to do to see the contents of your outbound API requests:
  1. Start a free Runscope account (runscope.com) - it's a very useful tool if you do any type of integration.
  2. In Runscope, click on the Captures link on the left menu. At the top of the Captures page, you’ll see a capture URL for the bucket you’re in. Copy that URL.
  3. Use the URL from #2 to create a new Remote Site setting in your org.
  4. Find the interface port class that was created when you converted from a WSDL using wsdl2apex, or the location of the WebServiceCallout.invoke() method in your code.Change the callout endpoint to the URL from #2, and save the class.
  5. Execute your code (anonymous or through UI).
  6. Go to the Runscope Captures page again. A new capture will be shown. Expand the new capture and click on the Request link - that will show you exactly how your transaction is formatted including the header and the SOAP body.

Mar 3, 2014

Known Issue: Publisher Update Actions Invoked by Inline Edits

One of our Orgs required multiple field updates to be performed through a Publisher Action.  The Action was working great from Salesforce1 as well as from the Chatter feed when it was realized that the field updates defined in one of the Publisher Actions was triggered from normal updates to the record.

I was able to replicate this in a Developer Org - below are the details:

Here's the Action:



The Action is simple - when used, the Opportunity's Stage is updated to "Closed Won."  When looking at the Action's Layout, it works with or without (displayed below) fields present:



From Chatter, the Action looks like this:



From Salesforce1, it looks like this:



With the Chatter feed displayed at the top of the page, when you make an inline-edit, the Publisher Action will run:



  1. Before:  The Stage is already set to "Prospecting" and the Approval picklist is blank
  2. Update:  Using inline editing, the "Approval" field is updated to "Approved" and then the "Save" button is clicked.
  3. After:  Once the page refreshes from the "Save," the Stage has been flipped to "Closed Won" as defined in the Publisher Action.
Again, this is in a brand new Developer Org where the only things created were the "Approval" picklist field and the Publisher Action.  The above is not occurring due to any Apex Code behind or Workflow Rule Field Updates.

After pinging Salesforce, we've learned that this is a known issue with a patch due out soon.  A possible workaround was to add another Action, a Create action for the same entity, if possible, and locate it to the right of the Update Action.

Other short-term solutions include hiding the Chatter feed when using inline editing mode or using the "Edit" mode and avoid using inline editing mode.