Pulling Go Code Colorado Data into Salesforce

This weekend I’m at the Go Code Colorado Challenge Weekend event in Durango. The purpose of Go Code Colorado 2016 is for teams to build something useful for businesses using one or more of the Colorado Public Datasets. Some teams are using Salesforce for the back-office / business process side of the app they are building. So I decided to see if I could pull a Colorado Public Dataset into Salesforce. Turns out it’s super easy! Just follow these steps:

  1. Sign up for a Salesforce Developer Edition
  2. Create a new External Data Source with the following field values:

    External Data Source = Colorado Public Data
    Name = Colorado_Public_Data
    Type = Lightning Connect: OData 2.0
    URL = https://data.colorado.gov/OData.svc
    Special Compatibility = Socrata

    new_external_data_source

  3. Save the new External Data Source and then hit “Validate and Sync” to fetch the metadata for the services.
  4. Select one or more tables from the list. A good table to test with is the “Occupational Employment Statistics” dataset.
    validate_and_sync
    Sync the table and you should see a new “External Object” in the list of External Objects.
    external_objects
  5. The data is now available in Salesforce. An easy way to see the dataset is to create a tab in the Salesforce UI. On the Custom Tabs Setup page create a new Custom Object Tab for the “Occupational Employment Statistics” object and select a Tab Style:
    new_custom_object_tab
    Complete the creation of the tab (select Next, Next, Save).
  6. Select the “Occupational Employment Statistics” tab (which might be in a drop-down menu depending on the width of your browser:
    custom_tabs
    Next to the View – All selector, hit “Go!” to fetch the data from the Colorado Public Data source. You’ll now see the records:
    records
    Note: The columns displayed in this view can be customized in the External Object’s Search Layout.
    Selecting a record’s ID will display the record details:
    record_details

That’s it! Now you can build all sorts of business processes and other employee-facing interactions around the public data.

Good luck to all of the Go Code Colorado teams!

Quick Force Java – Getting Started with Salesforce REST in Java

Recently I blogged about a toolchain that quickly gets you going with the Salesforce REST APIs. I believe developers should be able to get started with new technologies without having to install tons of stuff and struggle for days. That blog used Quick Force Node for those who want to use JavaScript / Node.js. I’ve had a number of requests for a Java version of this toolchain so I created Quick Force Java.

Check out a screencast that shows how to start with nothing, deploy a Salesforce REST app on Heroku, setup OAuth, setup a local dev environment, make & test changes to the app, and then deploy those changes back to the cloud (all in under 12 minutes):

Try out Quick Force Java and let me know how it goes!

Salesforce REST APIs – From Zero to Cloud to Local Dev in Minutes

When getting acquainted with new technologies I believe that users shouldn’t have to spend more than 15 minutes getting something simple up and running. I wanted to apply this idea to building an app on the Salesforce REST APIs so I built Quick Force (Node). In about 12 minutes you can deploy a Node.js app on Heroku that uses the Salesforce REST APIs, setup OAuth, then pull the app down to your local machine, make and test changes, and then redeploy those changes. Check out a video walkthrough:

Ok, now give it a try yourself by following the instructions in Quick Force (Node)!

I hope this will be the quickest and easiest way you’ve gotten started with the Salesforce REST APIs. Let me know how it goes!

FYI: This *should* work on Windows but I haven’t tested it there yet. So if you have any problems please let me know.

Dreamforce 2015 Video: Tour of Heroku + Salesforce Integration Methods

This year at Dreamforce I presented a session that walked through a few of the ways to integrate Heroku apps with Salesforce. Here is the session description:

Combining customer-facing apps on Heroku with employee-facing apps on Salesforce enables a whole new generation of connected and intelligent experiences. There are four primary ways to do this integration: Heroku Connect, Canvas, Apex / Process Callouts, and the Salesforce REST APIs. Using code and architectural examples, we’ll walk through these different methods. You will walk away knowing when you should use each and how to use them.

Check out the video recording of the session.

To dive into these methods here are the “Further Learning” resources for each method:

I hope this is helpful. Let me know if you have any questions.

Salesforce Canvas Quick Start for Java Developers

Salesforce provides a variety of different ways to integrate external apps into the Salesforce UI. Canvas is an iframe-based approach for loading externally hosted UIs into pages on Salesforce. The nice thing about Canvas versus a plain iframe is that Canvas has a JavaScript bridge which enables secure communication between the external iframe and Salesforce. This communication happens in the context of the Salesforce user and doesn’t require the typical OAuth handshake. Because Canvas apps live outside of Salesforce they can be built with any language and run anywhere, including Heroku.

I’ve put together a quick start Canvas app that uses Java and Play Framework to get you going in minutes. You can either run this app on Heroku or on your local machine. The fewest steps to get everything setup is with Heroku so I’ll cover that first.

Deploying a Canvas App on Heroku

Heroku is an app delivery platform that works with a variety of back-end programming languages and frameworks. I’ve created a Canvas-ready Java app using Play Framework and set it up for instant deployment. To get started, signup for a free Heroku account (if needed), then launch your own copy of the salesforce-canvas-seed app.

Once the app has been deployed, open / view the app and follow the instructions to complete the setup process. You will create a new Connected App on Salesforce that is used to identify the external app. Once you’ve completed the instructions you will now have a fully functional Canvas app, running on Heroku, and written in Java.

Running a Canvas App Locally

Cloud deployment with Heroku is quick and easy but if you want to make changes to your app you should setup a local development environment. To do that, download the salesforce-canvas-seed Activator bundle, extract the zip, and from a command line in the project’s root directory, run (on Windows, omit the ./):

./activator -Dhttps.port=9443 ~run

This will start the app with HTTPS enabled. Connect to the app: https://localhost:9443
Your browser may give you a warning about the certificate not being valid, which you should ignore / approve the connection. Then you will see instructions for setting up a new Connected App on Salesforce which will be used for local development. After following those instructions you will have a Canvas app running locally. Now you can begin making changes to the app.

The app/assets/javascripts/index.js file contains the client-side application while the app/views/index.scala.html file contains the HTML content for the application. The app you’ve just setup should just be displaying the logged in user’s name. That is happening using some jQuery and the Canvas SDK. The HTML file contains:

<h1>Hello <span id='username'></span></h1>

The index.js file contains:

Sfdc.canvas(function() {
  // Save the token
  Sfdc.canvas.oauth.token(window.signedRequestJson.oauthToken);
  Sfdc.canvas.byId('username').innerHTML = window.signedRequestJson.context.user.fullName;
});

This JavaScript sets up the OAuth token for the Canvas SDK. Then the contents of the username tag are replaced with the current user’s name.

That should be everything you need to get started building against the Canvas SDK. For more information on that check out the Canvas Docs.

Let me know how it goes!

Introducing Force WebJars: Add JavaScript Libs to Salesforce With a Click

The typical method of adding JavaScript and CSS libraries (e.g. jQuery, Bootstrap, and AngularJS) to Salesforce environments is to locate a library’s download, download it, then upload it to Salesforce, then figure out the structure of the files so that you can use them from Visualforce. Using WebJars as a basis, I’ve created an easy way to add libraries to Salesforce, called Force WebJars.

Here is a quick demo:

Give it a try and let me know how it goes!

BTW: The source is on GitHub.

Dreamforce 2014: Wearables, Engagement Apps, $1M Hackathon

Dreamforce 2014 is quickly approaching and this year is going to be amazing! I’ll be presenting a few sessions and helping at the $1 Million Hackathon. Here are my sessions:

  • Integrating Clouds & Humans with the Salesforce Wear Developer Packs

    As smart watches and other human-integrated devices make their way into the mainstream, developers will need to quickly ramp up to these new paradigms and interaction models. Integrating these new wearable devices with Salesforce connects users to their businesses and customers in new ways. Join us as we use code and examples to dive into the architecture and patterns for developing wearable Salesforce apps with the Salesforce Wear Developer Pack for Android Wear.

  • Architecting Engagement Apps

    Modern systems are composed from all sorts of pieces, like back-office systems, legacy systems, mobile apps, JavaScript web UIs, third-party services, relational data, NoSQL data, and big data. Effective user engagement requires an architecture that brings all of these pieces together instead of the traditional siloed approach. Join us to learn about the Engagement Architecture and how it can be used to create modern composition-oriented systems.

This year at the $1M Hackathon there will be 35 different prizes including prizes for building apps on Heroku and prizes for open source projects!

Hope to see you there!

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!

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!