An Architects Guide to the Salesforce1 Platform

Salesforce.com was initially created as a Sales Force Automation (SFA) / Customer Relationship Management (CRM) application in the cloud but has evolved over the years into a modern platform for all types of enterprise applications. Now the Salesforce name is a legacy artifact of that past. This is like the name Frigidaire which is still the name for a company that now produces much more than Frigidaires (i.e. Refrigerators). The Salesforce1 Platform still provides the SFA & CRM applications but is also a foundation for building modern systems.

Pricing & Additions

The Salesforce1 Platform comes in many editions and packages, like the Sales Cloud edition for CRM and the Platform edition for anything. The edition you choose will enable different features and provide a different foundation to start with. Check out the full list of editions to see the pricing and features for each option. The Developer Edition provides a free platform for developers.

Now lets go through the many different components of the Salesforce1 Platform from the 30,000 foot perspective.

Metadata-Driven Data Model

At the core the Salesforce1 Platform is a cloud database. That database is customized and configured via metadata. The metadata that defines the data model can be modified via XML definitions and via a point-and-click UI. The metadata for a tenant environment, known as an ‘organization’, or ‘org’, is versionable, packageable, and testable. An object or table is called an SObject and provides a bunch of out-of-the-box features:

  • Custom Fields
  • Validation Logic
  • Field-level Security
  • Relationships & Pick-Lists
  • Derived Values

All SObjects automatically provide:

  • SOAP & REST APIs
  • Basic CRUD-ish UIs
  • Mobile CRUD-ish UIs via the Salesforce1 mobile app
  • Indexed Search

Fields on SObjects can be any of the following types:

  • Auto Number
  • Formula
  • Roll-Up Summary
  • Lookup Relationship
  • Master-Detail Relationship
  • Checkbox
  • Currency
  • Date & Date/Time
  • Email
  • Geolocation
  • Number & Percent
  • Phone
  • Picklist & Picklist Multi-Select
  • Text, Text Area, Encrypted Text
  • URL

New organizations on the platform come with a number of out-of-the-box SObjects which differ depending on which edition of the platform you are using. For instance, new organizations using the Sales Cloud edition come with SObjects including Contact, Lead, and Opportunity.

Built into the Salesforce data model are essential security features like change auditing and field-level security.

Managed Runtime for Programmatic Customizations & Extensions

A system on the Salesforce1 Platform can be built entirely using the Metadata-driven Data Model. But there are use cases when programmatic logic is needed for things like custom UIs, triggers, and scheduled jobs. The programming languages used to write programmatic logic on the platform are:

  • Visualforce – Server-side templating language for custom UIs that run inside of your Salesforce system
  • Apex – Programmable logic for triggers, Visualforce controllers, & scheduled jobs
  • SOQL – Domain Specific Language (DSL) for database queries

Visualforce uses a JSP-like syntax for creating custom HTML pages that are rendered inside of Salesforce.com and can also be rendered in the Salesforce1 mobile app. Pages in Visualforce use the traditional server-side MVC architecture where the Visualforce page is the View, an Apex class is the controller, and the model is SObjects. Visualforce pages can include any JavaScript and can use JavaScript Remoting and/or RESTful JSON services. Here is a simple Visualforce page:

<apex:page>
    hello, world
</apex:page>

Apex has a Java-like syntax and runs on Salesforce in a managed, sandboxed, and secure runtime. There is both an Eclipse plugin and a web-based Developer Console for writing Apex. Apex triggers attach to SObject events like update, create, and delete. Batch jobs and scheduled jobs are also written in Apex. Here is a simple Apex trigger:

trigger Foo on Contact (after insert) {
    for (Contact newItem : trigger.new) {
        System.debug('Contact Created: ' + newItem.Name)
    }
}

SOQL queries can be run in the Developer Console and can also be easily embedded in Apex, for instance:

Contact contact = [SELECT Id FROM Contact LIMIT 1];

Apex includes a JPA/Hibernate-like database access syntax called DML. This makes it easy to create, update, and delete SObjects in Apex. For example:

Contact c = new Contact(LastName='Bar');
insert c;
c.FirstName = 'Foo';
update c;
delete c;

Like SObject metadata, all of the programmatic code in Salesforce is versioned, packageable, and testable. Unit testing and code coverage are built into the Apex runtime and 75% code coverage is required in order to deploy code into a production Salesforce system. This code coverage requirement helps maintain stability across major platform upgrades because Salesforce uses customer tests to detect regressions and breakages.

Instead of writing Apex many approval processes and business rules can be created declaratively using Workflow. Just like SObject metadata, Workflows can be created with a point-and-click web interface, the Visual Workflow editor. Under the covers all workflows are just metadata which can be versioned and packaged like all of the other platform extensions and customizations.

The Salesforce.com UIs, Salesforce1 Mobile App, Apex runtime and Workflow systems are for back-office, employee-facing interactions. For customer-facing interfaces that interact with data on Salesforce, the Heroku service (part of the Salesforce1 Platform) enables developers to easily create, deploy, and scale custom web apps, mobile apps, and web / REST services. Heroku apps can be written in any language (Java, Ruby, Node.js, etc) and are deployed on a fully managed system that provides the infrastructure developers would normally have to assemble and manage on their own. For instance, services like load balancing, failover, centralized logging, continuous delivery pipelines, and instant scalability are provided out-of-the-box on Heroku.

Integration and ETL

The Salesforce1 Platform provides a variety of ways to integrate with other systems and perform data migrations & synchronization. The major interfaces for these types of data integrations are:

  • Heroku Connect - A standard, high-performance SQL interface to the data on Salesforce.
  • SOAP APIs - Schema-rich web services.
  • REST APIs - Simple JSON web services.
  • Streaming APIs - Event-driven messaging service.
  • Data Import & Export - Numerous tools, wizards, and web services provide easy access to import and export Salesforce data.
  • Email Notifications – Apex and Workflow can be used to send email notifications from Salesforce.
  • Mobile Notifications - Mobile notifications are built into the Salesforce1 mobile app and custom notifications are also supported.
  • OAuth 2.0 – The Salesforce web services use OAuth 2.0 to handle authenticating users so that integrated applications can make API requests on their behalf.
  • SAML - Enterprise Single Sign-On.
  • Mobile SDKs - Native, Hybrid, and HTML5 SDKs for custom mobile apps.
  • Integration Platform Vendors – Many integration platform vendors like InformaticaBoomiCast Iron, and MuleSoft have out-of-the-box support for integrating with Salesforce.

Massive Ecosystem

There is a massive galaxy of services, apps, frameworks, and libraries around the Salesforce1 Platform. Here are some of those:

The Platform You Can Trust

Because the Salesforce1 Platform is your foundation for business-critical data and apps, the foundation of Salesforce must be Trust. In large enterprise systems there are many aspects to Trust, like transparency of system uptime & responsivenessmulti-tier security, and privacy & certifications.

Get Started

Ready to dive in? The best way to dip your toes in the water and starting building something on the Salesforce1 Platform is by going through the Salesforce Developer Workshop. It won’t cost you anything except time and will help you to understand many of these components by using them. Let me know how it goes!

Posted in Salesforce.com | 1 Response

Building & Deploying Reactive Service Pipelines — Live in Salt Lake City

This Wednesday (Aug 6, 2014) I will be presenting Building & Deploying Reactive Service Pipelines at the Utah Scala Enthusiasts group in Salt Lake City. Here is the abstract:

Composition of micro-service is a modern integration pattern that couples nicely with Reactive and Continuous Delivery. These paradigms enable small teams to move quickly while integrating cross-silo data stores for modern JavaScript UIs and REST services. This session will use Scala, Play Framework, and Heroku to illustrate how to build and deploy Reactive Service Pipelines.

RSVP Now! Hope to see you there.

Posted in Reactive, Scala | Leave a comment

Going Reactive at OSCON 2014

This year at OSCON I will be leading a hands-on lab and presenting about Reactive, Play Framework, and Scala. Here are two sessions:

  • Reactive All The Way Down (lab) – 9:00am Monday, July 21

    In this tutorial you will build a Reactive application with Play Framework, Scala, WebSockets, and AngularJS. We will get started with a template app in Typesafe Activator. Then we will add a Reactive RESTful JSON service and a WebSocket in Scala. We will then build the UI with AngularJS.

  • Building Modern Web Apps with Play Framework and Scala – 2:30pm Wednesday, July 23

    Play Framework is the High Velocity Web Framework For Java and Scala. It is lightweight, stateless, RESTful, and developer friendly. This is an introduction to building web applications with Play. You will learn about: routing, Scala controllers & templates, database access, asset compilation for LESS & CoffeeScript, and JSON services.

Hope to see you there!

Posted in Conferences, Play Framework, Reactive, Scala | Leave a comment

Scala vs Java 8 at the Scala Summit

Bruce Eckel will be hosting the Scala Summit in Crested Butte again this summer. The Open Spaces conference will be September 15 – 19 which is a perfect time of year up in the Colorado Rockies. The theme of the Scala Summit this year is Scala vs. The New Features in Java 8. So there will definitely be some fascinating discussions. I’m also looking forward to working on some IoT projects during the hackathons. Bruce and I have a few pcDuino devices that will be fun to get Scala working on. Hope to see you there!

Posted in Conferences, Scala | Leave a comment

Salesforce Gradle Plugin

As part of the Salesforce Wear Developer Pack for Android Wear I created a Gradle plugin that fetches and deploys Salesforce code (Apex). Gradle is the default build tool for Android but it can also be used with many other languages. For instance, here is an example build.gradle file for a project that fetches all of the Apex classes and Visualforce pages:

buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
    }
    dependencies {
        classpath 'com.jamesward:force-gradle-plugin:0.1'
    }
}
 
apply plugin: 'force'
 
repositories {
    mavenLocal()
    mavenCentral()
}
 
force {
    username = forceUsername
    password = forcePassword
    unpackagedComponents = ["ApexPage": "*", "ApexClass": "*"]
}

The unpackagedComponents definition uses the Salesforce Metadata Types and pulls everything specified down into the src/main/salesforce/unpackaged directory when you run the forceMetadataFetch Gradle task. The forceMetadataDeploy Gradle task deploys everything in the src/main/salesforce/unpackaged directory to Salesforce.

Try this out:

  • Install Gradle
  • Create a new project directory containing the build.gradle above
  • In your project directory create a new file named gradle.properties containing your Salesforce username & password:

    forceUsername=foo@bar.com
    forcePassword=password
  • Fetch your Salesforce Metadata:

    gradle forceMetadataFetch
  • Make a change and deploy the Metadata:

    gradle forceMetadataDeploy

For a complete example check out the Visualforce + AngularJS + Bootstrap project.

All of the code for the Salesforce Gradle Plugin is on GitHub: https://github.com/jamesward/force-gradle-plugin

Let me know what you think. Thanks!

Posted in Gradle, Salesforce.com | 5 Responses

Create Webhooks on Salesforce.com

Webhooks are the modern, web-oriented way for servers to receive notifications from other servers. For instance, when an event happens on a server, like Salesforce.com, your own custom application can receive the event via a web request.

Salesforce already has a built-in way to handle events called Triggers which run on Salesforce via Apex code. However, you may want to receive these events in your own custom application. In Salesforce it is pretty easy to write the Apex to do this but why not automate that process? I built the Salesforce Webhook Creator to do just that. Here is a short demo:

If you want to test it out, use my Echo Webhook app by entering a URL like:
https://echo-webhook.herokuapp.com/SOME-UNIQUE-ID

All of the code is on GitHub – contributions welcome!

Let me know what you think!

Posted in Salesforce.com | Leave a comment

Cross-Origin Resource Sharing (CORS) for Salesforce.com

By default browsers limit access to cross-origin resources. For instance, if a JavaScript app is loaded from foo.com then it isn’t allowed to access content from bar.com because this would be a significant security hole. Cross-Origin Resource Sharing (CORS) is the way to workaround this limitation in modern browsers.

Salesforce.com has a great REST api but unfortunately it doesn’t yet have native CORS support (but you can vote for this feature). Having CORS support comes in handy with JavaScript UIs on top of the Salesforce REST APIs. Luckily you can easily workaround this by proxying the API requests through the server that is serving the JavaScript UI so that the REST requests are not cross-origin. But it is tedious to set this up for every app, so I created a generic Salesforce CORS proxy.

For demo purposes the CORS proxy is available at: https://sfdc-cors.herokuapp.com

So you can just replace your Salesforce domain name with sfdc-cors.herokuapp.com to use the CORS proxy. Here is an example:

$ curl -i -H 'Authorization: Bearer YOUR_SESSION_ID' https://sfdc-cors.herokuapp.com/services/data/v30.0/query/?q=select%20Id%20from%20Account
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

The HTTP Response contained the necessary CORS header on the GET request. An OPTIONS request also returns the right response headers to allow the request.

This app is open source so you can easily deploy it on your own Heroku app or in your own environment for production usage.

One of the other nice features of this proxy is that it figures out which Salesforce instance to connect to. So you no longer need to specify something like na9.salesforce.com – instead just use one domain name for all of your apps and instances.

I hope this is useful for you. Let me know if you have any questions or feedback.

Posted in Salesforce.com | 7 Responses

Integrating Clouds & Humans with Salesforce and Android Wear

Right out of the gate in my new job at Salesforce.com and I have been working on a pretty exciting new project to integrate clouds and humans using Salesforce.com and Android Wear. This week Salesforce launched six new open source developers packs for wearables. I created the Salesforce Wear Pack for Android Wear to help developers start building cloud-driven wearable apps for emerging devices like smart watches. Check out a short demo of the sample app I built:

All of the code and instructions for getting this application running in your development environment are in the QuoteDiscountApproval sample app.

This project was a ton of fun and I’ve learned a bunch of new things about Android, Gradle, and Salesforce.com which will provide some great fodder for upcoming blogs. So check out the Salesforce Wear Pack for Android Wear and stay tuned for more blog posts on these topics.

Posted in Android, Salesforce.com | 1 Response

Testing Webhooks Was a Pain – So I Fixed the Glitch

Popularized by GitHub, Webhooks are the modern way for apps to receive notifications / events from other servers. But testing Webhooks has always been pretty painful, especially if you want to automate those tests. So I created a little app to make it easier. Before we get into that lets cover the basics…

A Webhook is a way for you to define a URL that is called by another service when a particular event occurs. For example, you can configure your repo on GitHub to have a Webhook that calls http://foo.com/pr when a new Pull Request is created. The old alternative to this is polling (bad).

Testing Webhooks is painful because the service calling your Webhook can’t reach your localhost and it can be hard to get the payload of the request. So I created a very simple app to help with this. To use it set the Webhook URL to:

https://echo-webhook.herokuapp.com/SOMETHING_UNIQUE

Now when the other service does its POST to that URL the request body is cached and can be retrieved via a GET to the same URL. Here is a simple curl test:

curl -H "content-type: application/json" -d '{"foo": "bar"}' https://echo-webhook.herokuapp.com/foobar
curl https://echo-webhook.herokuapp.com/foobar
{"foo":"bar"}

Your app can get the payload of the Webhook request and if needed pass it to your localhost Webhook for testing. All of the code for this app is on GitHub: https://github.com/jamesward/echo-webhook (Note: If you don’t want your data going through my app just git push that repo to your own Heroku app.)

I hope this is useful for others! Let me know if you have any questions or problems.

Posted in Tools | 1 Response


  • View James Ward's profile on LinkedIn