The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

1. A Beginner’s Guide to Object-Oriented Programming with Apex: Encapsultation

with one comment

This is part 2 in the series “A Beginner’s Guide to Object-Oriented Programming with Apex” and will cover the aspect of Encapsulation. For part 1 go here.

What the hell is Encapsulation?

Encapsulation isn’t a tricky concept in itself but some confusion does arise from it’s close relationship with Abstraction (to be covered in my next post). Broadly it is defined as one of, or both of the following:

  1. An information hiding mechanism.
  2. A bundling of data and methods that operate on that data.

These are pretty abstract statements but in reality are very simple. I will demystify them with examples below but for now let’s use an analogy:

Imagine you have a watch (or if you have one just consider it, don’t worry about the imagining part) that tells you the date and time. You can adjust the date and time using buttons/knobs/switches but you have no idea what happens inside the watch, just that it results in the date and time changing. You have some data (the date and time), you have some methods to operate on that data (buttons/knobs/switches) and there is a whole lot of stuff going on in the background that you don’t know about (and it’s better that way, imagine you had to adjust all those bits and pieces yourself).

That’s encapsulation baby! Read the rest of this entry »

Written by Wes

June 17, 2014 at 6:09 pm

Posted in SalesForce, Apex

Tagged with , ,

0. A Beginner’s Guide to Object-Oriented Programming with Apex: An Introduction

with 3 comments

Apex has come a long way in the past few years, and as Salesforce has grown so has the number of super smart people working on the platform. There are lots of guides on how to do fancy things using JavaScript, Apex and Visualforce as well as many more whitepapers on the topics of governances and standards. However I think there is a gap, and I’d like to plug it.

Over the next few weeks and months I will be releasing articles that describe and show the basics of object-oriented programming (OOP) with Apex. My approach will be to make these articles as modular and simple as possible. The target audience? Developers with a-teeny-bit-of-experience through to those who have tons of experience but never had any formal training in OOP.

What the hell is OOP?

Good question, and although many agree on some elements of OOP there is still a divergent view in the details. Contrasting it to what came before helps though.

The programming paradigm prior to OOP essentially had everyone writing code as your would an essay i.e. a single long text with one line written (and executed) after the other. There were no classes, no methods, no GOTO statements even (if you go far back enough that is). If you needed the same complex calculation in 5 parts of your application you had to write it 5 times. This is obviously a bad idea and over time the geniuses that created computer programming started inventing bits and pieces of engineering to make it easier to create, maintain and extend their code. Collectively, these features together with their experience were the beginnings of OOP.

The most commonly cited features of OOP are described below.

Encapsulation

A way to hide state (or private data), but also – confusingly – a way to bundle data and capabilities to operate on that data.

As an example consider a sausage making machine, you pour some stuff into one end and get sausages out of the other without needing to know the internal workings. The inner workings are encapsulated within the machine.

Abstraction

This is one of the trickiest concepts because it is relative, you can have levels of abstraction and it essentially means providing the appropriate level of information and data at the requested level.

With my previous example, if you are the sausage maker then you just need to know what stuff to insert into which part of the machine. But, if you were the sausage machine repair man you would need to have the tools, knowledge and access to all the bits and bobs inside of the machine. These are different levels of abstraction.

Inheritance

A controversial aspect since some languages think that inheritance is bad. In short it is the capability of a class or object to have certain methods and attributes passed down to them through a hierarchy.

Now that I’ve started the sausage story I can’t stop! All sausages share certain qualities e.g. they’re all encased in something, have some type of contents and (usually) need to be cooked before being eaten. You could represent these common attributes in a parent class and have specific types of sausages (pork, chicken, blood pudding) “subclass this superclass” i.e. inherit from it.

Polymorphism

Polymorphism is extremely rewarding when you get it right because it just feels smart. In short it allows you to define ways of dealing with data without knowing exactly how that data will be defined in the future.

To finish off the sausage story (anyone else hungry?) you could put any type of meat into the machine but in the end you will still always get a sausage i.e. provided that a certain type of input (any type of meat and spice) is provided to the machine it “knows” what to do with it (make delicious sausages) even though the types of sausages may have differences.


 

Don’t worry if these concepts haven’t clicked just yet, each will be covered in detail in future posts.

These concepts are obviously academic and language agnostic but Apex makes them available to you through the constructs of classes, methods and attributes of those classes, instances of those classes.

A note on terminology. In the Salesforce world an Object is most commonly used to refer to a data entity e.g. Account or CustomObject__c. In the OOP paradigm an Object is an instance of a Class i.e. MyClass.cls is an Apex class which provides the blueprint for instances of itself. This becomes clearer with an example:


MyClass myObject = new MyClass();

myObject.divideByZero();

MyClass is the class, and myObject is an instance of that class AKA an object. Got it? Great.

Why Should I Use OOP?

Because it will make you a better programmer and it doesn’t hurt with the ladies/men (delete as appropriate). Your code will be better, you will end up doing less boring work and it will be easier (and quicker) to fix bugs. I guarantee it.

Next Time on Th3Silverlining

My next post will delve into the feature called Encapsulation so hit the subscribe button to find out when it’s published. See y’all then.

 

Written by Wes

June 6, 2014 at 5:10 pm

Salesforce: Universal Batch Scheduling Class

with 2 comments

Mark David Josue. All Rights Reserved.I’d like to propose a new way of working with scheduled batch classes. I’ve worked on several hundred Salesforce projects in the past few years and often see batch scheduling classes being created per scheduling requirement and it grinds my OCD – not in a good way. In most cases you should only need one “Batch Scheduler” per Org, let me demonstrate how and why.

The Universal Batch Scheduler™

Requirements

Let’s assuming you have a batch class that you need to run on a repeated schedule*, such a class signature is given below. That class will have to obey some conventions such as implementing the Batchable interface as shown in the standard documentation.

global class MyBatch implements Database.Batchable<SObject> {

// …

}

* For one off, schedule execution of batch classes you can use the System.ScheduleBatch() method.

The Scheduler

Now you might be tempted to created a scheduled Apex class specifically for this batch class, but by using the principle of polymorphism you could create a universal scheduler instead.

First of all you’ll need to implement the required interface for scheduled Apex classes as shown below.

global class BatchScheduler implements Schedulable {

// …

}

Next assign global, class-level variables which will be used to access the parameter values required when executing a batch class. Note that we’re creating a variable called “batchClass” whose type is the interface Database.Batchable. This means that any class that implements this interface can be assigned to this variable, this behaviour is called polymorphism.

  global Database.Batchable<SObject> batchClass{get;set;}
  global Integer batchSize{get;set;} {batchSize = 200;}

And finally implement the method required by the Scheduleable interface and use the variables to kick off the execution of a batch class.

  global void execute(SchedulableContext sc) {
   database.executebatch(batchClass, batchSize);
  }

Et voila! You now have a class that can be used to schedule any batch class in your Org. The final code being:

global class BatchScheduler implements Schedulable {
  global Database.Batchable<SObject> batchClass{get;set;}
  global Integer batchSize{get;set;} {batchSize = 200;}

  global void execute(SchedulableContext sc) {
   database.executebatch(batchClass, batchSize);
  }
}

In order to use it you would have to initiate the schedule from an anonymous block (Developer Console, Eclipse, Mavensmate etc.). For example I would schedule my batch class using something like this:

// Instantiate the batch class
MyBatch myBatch = new MyBatch();

// Instantiate the scheduler
BatchScheduler scheduler = new BatchScheduler();

// Assign the batch class to the variable within the scheduler
scheduler.batchClass = myBatch;

// Run every day at 1pm
String sch = '0 0 13 * * ?';

System.schedule('MyBatch - Everyday at 1pm', sch, scheduler);

There may be cases where the universal batch scheduler is not appropriate i.e. special pre-work has to be done in the scheduling class, but in most cases I’ve seen it’ll do the job. Hopefully this’ll help you make your Orgs a little neater too.

Written by Wes

February 2, 2014 at 12:34 pm

If This Then Salesforce

leave a comment »

I’ve been enjoying IFTTT for a while now and if you haven’t experimented with it yet then I’m not sure we’ll ever be friends. Essentially it’s a very easy tool that lets you set triggers on a source API e.g. Foursquare and have some information from that API be posted to a target API e.g. Jawbone Up. IFTTT calls these recipes and I’d like to demonstrate some particularly delicious combinations that can be used with Chatter.

Salesforce Org Alerts and Known Issue posted to Chatter

Salesforce makes Instance Alerts e.g. “Perfomance degradation on EU0.” available through an RSS feed so all you need to do is create a recipe (or copy mine) that monitors the appropriate RSS url for changes and posts to a particular Chatter group.

You can do a similar thing with Salesforce Known Issues.

Tweets posted to Chatter

Quite often there are interesting tweets that I want to share with a particular group on Chatter. One of the recipes I’ve created in this class uses the hashtag #tqcd to push a particular tweet to our “Development” Chatter group.

Screen Shot 2013-11-15 at 15.24.04We also have more than a few Reid Carlberg fans in Tquila so we have a recipe that shares his tweets to a dedicated group in our Org. His tweets are mostly about facial hair at the moment but who am I to judge genius.

Limitations

At this point Chatter can only be used as a target system in any recipe but I’m hoping they’ll change that in future.

Best Practices

So far I’ve established two guidelines:

  • Create a separate Chatter group for recipes that will be executed often. This gives people the option to opt-out of those posts.
  • If possible create a separate Salesforce user to post on Chatter. This will reduce the number of explicit posts you making it easier for others to find information in your feed.

You can find all these recipes on my IFTT profile. There are quite a few other interesting recipes regarding Salesforce on the IFTTT website but I’m hoping that you’ll be inspired to think of new creative ways to use the tool. If you do please let me know in a comment below or on Twitter.

Written by Wes

November 15, 2013 at 5:35 pm

Salesforce Analytics API Sample Code

with 6 comments

Spider ChartA picture is worth a thousand words, so goes the justification for graphic novels. I kid, I love the hell out of graphic novels but now I’ve been sidetracked and this is only the second sentence of this post.

So, the Analytics API. I’m pretty enamoured with it as it seems is Pat Patterson, and I think that it’s one of the most useful features the platform has ever made available. Presenting the right chart (or set of charts) to a manager or executive can empower them to make business decision in minutes, powerful stuff. To that end myself and a few of my fellow Tquilites have begun building an opensource library of Analytics API demos to aid you in aiding your clients/managers/execs.

Below I’ve included a few introductory steps to help you get started. To start with you’ll need the code from github.

Step 0

I’ll be stepping through the Google Charts Stacked Bar Chart example from github so you’ll be able to test this out yourself.

Step 1 – Create a report

Certain report formats map well to certain chart formats so make sure you choose the right type of report. For example, stacked bar charts map well to matrix reports, summary charts map well to pie charts.

Once you have created your report and have some interesting data, determine the report ID and keep it somewhere safe. Report IDs always start with “00O”.

Report ID

Step 2 – Create a Visualforce Page

As it says in the heading of this section, create a new VF page. Easy peasy lemon squeezy.

Step 3 – Include the chosen JS library

As with any web-based language you’ll need to include the JS library that you want to use. I’m going to use Google Charts in this example. Note I’m also using jQuery to make the AJAX callout.

 <script type=”text/javascript” src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
 <script type="text/javascript" src="https://www.google.com/jsapi"></script>

Step 4 – Call the Analytics API

The API call can be made server-side or client-side, with this example making use of a client-side call.

    /** Fetch the JSON data representing the the report **/
    var jsonData = JSON.parse($.ajax({
        beforeSend: function(xhr) {
          xhr.setRequestHeader('Authorization', 'Bearer {!$Api.Session_ID}');
        },
        /** You'll need a URL parameter key called "id" that has a Summary Report id value **/
        url: "/services/data/v29.0/analytics/reports/{!$CurrentPage.parameters.id}",
        dataType:"json",
        async: false
        }).responseText);

The results of the callout are fed into the callback function and available through the variables “ai” and “ae” (see below).

Step 5 – Parse the resulting JSON & build the required data structure

The structure of the JSON depends on the report type but is fairly simple to understand. Be sure to use console.log() to investigate what’s going on if you get stuck.

    var chartData = new google.visualization.DataTable();

    chartData.addColumn('string', 'Stage');

    $.each(jsonData.groupingsDown.groupings, function(di, de) {
      chartData.addColumn('number', de.label);
    });

    $.each(jsonData.groupingsAcross.groupings, function(ai, ae) {
      var values = [];
      values.push(ae.label);

      $.each(jsonData.groupingsDown.groupings, function(di, de) {

        values.push(jsonData.factMap[de.key+"!"+ae.key].aggregates[0].value);
      });

      chartData.addRow(values);
    });

Step 6 – Generate the chart

Finally invoke the drawing of the chart along with any options required.

    var options = {
      title: jsonData.attributes.reportName,
      vAxis: {title: jsonData.reportMetadata.groupingsAcross[0].name},
      isStacked: true
    };

    var chart = new google.visualization.ColumnChart(document.getElementById('chart'));
    chart.draw(chartData, options);

Voila! You now know the basics of building custom charts in Visualforce (or any other web language) using the Analytics API. To try this out log into your Org and then browse to:

http://[your salesforce instance]/apex/YourPage?id=[reportId]

Feel free to use this code anyway that you can imagine and we’d be over the moon if you contribute your own awesome to what we’re building. Fork us on github.

Written by Wes

November 10, 2013 at 4:57 pm

Developing Chrome Extensions for Salesforce

with 4 comments

Get off my case!Chrome extensions are awesome, they provide amazing convenience that is limited only by your imagination. There are some amazing Chrome Extensions for Salesforce already, some of my favourites being:

As a great fan of JavaScript I’ve always wanted to create a Chrome Extension for Salesforce and I’ve finally gotten around to it. The hardest part was figuring out what context the JS executes in (e.g. in the current tabs context, or in some separate context). Let me step through the code to show you how it’s done.

Chrome Extension Structure

A Chrome Extension is made up of a JavaScript, HTML, images and JSON. At its core is a manifest file which contains the metadata describing your application in JSON. There is a lot of documentation about the structure of this file but some of the key elements are shown below.

{
  "name": "Get off my case!",
  "version": "0.8.1",
  "description": "Presents a notification above the favicon with the number of cases assigned to the current user.",
  "manifest_version": 2,
  "icons" : {
               "16": "img/icons/16.png",
               "48": "img/icons/48.png",
               "128": "img/icons/128.png"
             },
  "permissions": [ "tabs", "https://*.force.com/*", "https://*.salesforce.com/*"],
  "update_url": "https://clients2.google.com/service/update2/crx",
  "author": "Wesley Nolte",
  "browser_action": {
     "default_icon": "img/tquila_lozenge.png"
  },
  "content_scripts": [ {
     "js": [  "js/jquery.js",
              "js/forcetk.js",
              "js/tinycon.js",
              "js/contentscript.js" ],
     "matches": [ "https://*.salesforce.com/*", "https://*.force.com/*" ]
  }]
}

This file references all external resources (JavaScript, images etc.), the important parts here being the JavaScript i.e. jquery.js, forcetk.js, tinycon.js and contentscript.js. In short these files represent:

  • jquery.js – the jQuery library
  • forcetk.js – the JavaScript wrapper for the Salesforce.com REST API, but with one modification i.e. the ability to fetch info about the current user
  • tinycon.js – a small library used to create the notification on the tab
  • contentscript.js – the JavaScript file that brings them all together

The JavaScript

The first 3 JavaScript files are libraries that great, but aren’t particularly interesting in the context of this tutorial. The last file is where the magic happens, the code is listed below.

/* Get the cookie values om nom nom */
function getValueFromCookie(b) {
    var a, c, d, e = document.cookie.split(";");
    for (a = 0; a < e.length; a++)
        if (c = e[a].substr(0, e[a].indexOf("=")), d = e[a].substr(e[a].indexOf("=") + 1), c = c.replace(/^\s+|\s+$/g, ""), c == b) return unescape(d)
}

/* Encapsulating code instead of just letting it lay about */
function init() {
	// Get an instance of the REST API client and set the session ID
	var client = new forcetk.Client();
	client.setSessionToken(getValueFromCookie("sid"));

	// Retrieve the data representing the current user
	client.currentUser(function(response){
		var user = response;

		// Find cases that belong to the current user
		client.query("SELECT COUNT() FROM Case WHERE ownerId = '{0}'".replace("{0}",user.id), function(response){
			Tinycon.setBubble(response.totalSize);
		});
	});
}

init();

In short the code gets the session ID from the user’s cookie (the extension works in the context of the current user session for that tab) and uses that to call in using the REST API. Pretty easy huh?

Sourcecode and Extension Install

The sourcecode is on github if you want to experiment with it, and if you’d like to see it in action you can install it from the Chrome Web Store.

Written by Wes

September 14, 2013 at 1:26 pm

Salesforce: Files vs CRM Content vs Knowledge vs Documents vs Attachments

leave a comment »

The MatrixChoosing the right file or document management system on- (or off-) platform can be a difficult decision, and one of those things that’s difficult to change once implemented so it’s important to make the right choice up front.

Salesforce.com has a number of content and document solutions (and more on the way) and the options when given a set of decision points aren’t always clear. To this end I’ve created a matrix comparing the on-platform systems which should make that decision easier. It’s based on the official documentation but add in a few other key decision points (please don’t sue me Salesforce, I’m just a lowly a certified technical architect!).

If I’ve got anything wrong, or left something out please let me know.

Written by Wes

August 29, 2013 at 7:05 pm

Follow

Get every new post delivered to your Inbox.

Join 2,096 other followers

%d bloggers like this: