You're a custom web app developer and your manager tells you you're responsible for building a Salesforce integration. You've written web service clients before, so no sweat, right? You start to research Salesforce API's and realize there are a few things you'll need to know to make this interface really shine.
Here are 5 topics to research to get your Salesforce integration project started on the right foot.
Be An OAuth Champ
OAuth is the security protocol used by Salesforce to protect its web services. I won't go in depth on the nitty-gritty, but here are a few things you need at a minimum:
- Learn how Salesforce does OAuth. This is a great deep-dive offered by Salesforce. Really, read it several times, as long as it takes to really understand it. Explain it to the person next to you, your pet poodle, or your grandmother. Really know how it works.
- In Salesforce, you'll need someone to set up a Connected App, to enable the API. Learn the various OAuth permissions, and choose the one(s) that apply to you.
- Store your OAuth tokens securely. Treat them as a protected resource -- encrypt at rest, and protect the ones that give access to production and sandbox data. The sandbox is usually a dupe of production, so it's got lots of juicy data in it.
SOAP vs. REST
The age-old question. Both are fully supported by Salesforce and will be for the foreseeable future. There are a few things that can affect your decision here:
- Tooling and in-house knowledge -- you probably already have a bias one way or the other
- B2B integrations vs. Custom Web Apps vs. Mobile Apps -- B2B platforms are often built for SOAP communications. Mobile apps lend themselves more easily to REST. Custom web apps are a toss-up.
The SOAP API and REST API have excellent documentation. Choose the one that best fits your scenario
Choose A User
Logging in to the Salesforce API requires identifying yourself as a specific Salesforce user. Your privileges in the API are the same as that user in the Salesforce web UI. The regular Salesforce security rules (object-level, field-level, record-level, etc.) all apply through the API.
If the users of your application are also Salesforce users, then it may be best to log in as your application's current user. This requires storing OAuth credentials per user, but it allows you to interact with the API at the appropriate permission level.
If your users are not Salesforce users, you may need a single account with broader access.
Learn A Little Bit About Salesforce
I know, you're a Java/Ruby/.NET/PHP person who has a natural suspicion for "clicks, not code" development. Well, SAAS is here to stay, and you may find your life becomes a lot easier if you take the time to learn some basics about Salesforce. Here are some things I'd recommend:
- SOQL is the query language you'll use to get data. It's similar to SQL, but has its own quirks. A good overview is here. The good thing is, SOQL errors are usually very descriptive, so you don't have to spend much time understanding why your query is broken. This is really helpful.
- Know Custom vs. Native objects, and how they differ in the API. Namely, all custom objects and fields are suffixed by "__c" in their name. For example, a custom object called "Cheeseburger" will be represented in SOQL as "Cheeseburger__c".
- Get ready to do some query tuning -- Here are some best practices. Understand a little about caching, and why your queries run faster the second time.
- Try your hand at the Salesforce Developer Cert. This gives you a good foundation in Salesforce fundamentals.
Know Your Toolbox
Salesforce gives you some helpful developer tools:
- Workbench : Allows you to run practice queries against your org, right from the web. If you're developing a query, this is an easy way to do it, rather than running them through the API.
- Developer Console: You won't need to use many of the features here unless you're doing hardcore development inside Salesforce, but the Query Path feature can be helpful in debugging slow queries.
You should also ensure you have strong client tooling to support your web service development. A few things I always use:
- Message Logging -- I do a lot of .NET development, and I've found WCF's Message Logging feature is really helpful. Seeing the exact request and response helps a lot with debugging issues.
- Application Logging -- especially when you are doing an OAuth handshake, detailed application logging can be very helpful in understanding what's going on. ("Salesforce keeps throwing a 400 Bad Request... why?!") Keep a detailed log of messages to and from Salesforce (minus the secure tokens) and you'll save yourself a lot of grief.
