This weeks post is going to be another off topic one. I’ve been traveling more recently and I wanted to share the gear I use and what I like (and don’t like about) them.

Base Travel Gear

Regardless of the type of trip I’m taking, these items always come with me

Suitcase

I struggled for a long time to find the right suitcase. When looking for it my criteria was that I wanted a rolling suitcase that would fit in the overhead. This is a really wide category and there are hundreds that fit into this category. So I started looking at companies that I’ve use their gear before and the Osprey Merdian 22 caught my eye. It’s got some great features such as a disconnect-able backpack and straps that convert it to a backpack from a roller bag.

In Spring ‘15 Salesforce released a feature called “Quick Deploy” that allows you to only run a small subset of tests when you do your deployment instead of running all the tests. When you’re in an org like ours that running all tests can take upwards of 5hrs (or longer if the moon is aligned incorrectly) this is wonderful. Let’s take a look at how quick deploy works and how you can use quick deploy with Solenopsis.

How Quick Deploy Works

Quick deploy simply runs a provided list of tests when you run your deployment. This deployment is then staged under your Deployment Status in setup. Once the all the tests have run you’ll get a button that let’s you quick deploy.

Now that I’m starting to spend time playing with packaging code for use I decided to dig into how access modifiers affect visibility of methods and classes inside of managed packages.

Visibility Access Modifiers

Before we get started, let’s review what options we have for defining visibility in Apex

private – Methods, classes and variables marked as private are only visible inside the same class. If you define something as private then it cannot be accessed from an external class

public – Things that are marked as public are available for use by anything in the same namespace.

global – Things marked as global are available for use by anything on the platform.

Typically, public and private are enough for most implementations since your code resides inside the same namespace. When writing code to be used by others from your managed package you’ll want to make it global.

If you’ve been working with Salesforce for a while or you’re a larger company you’ll eventually want to get data out of Salesforce and into another system. So let’s take some time to break down the options that are available for getting data out of Salesforce in varying degrees of realtime.

One of the cool new features in Summer ‘16 is the ability to take a built in (or custom) address and automatically get that addresses latitude and longitude with SOQL (Read More). So took this as an opportunity to learn some more about it as well as some other mapping technologies. So for this my goal was to be able to create a heatmap of all the contact’s location under an account and place this on the account page.

This week is going to be just a social update on a couple of projects that I’m working on. I’ve got plans for a big neat post next week.

Me Code Pretty One Day…

I was hoping to present this at Dreamforce this year but it doesn’t look like that’s going to happen. So instead I’ll just talk briefly about it here

Apex Styleguide – Link – I’ve been asked several times what our team does for it’s code style and I’ve been working on an online style guide. It’s really a work in progress and will probably pivot a bit once Apex Checkstyle is complete. Right now all the rules are enforced by regexes and it doesn’t scale well and has a lot of false positives. If you want to create your own styleguide, feel free to fork the project. I’ll add build instructions for the site soon to make this easier.

Apex Checkstyle – Link – This has been something that’s been in the works for a while. Initially I tried to just make an extension to Checkstyle but there was just too many problems with that. So instead I completely forked Checkstyle and modified the grammar to help support Apex. While the project builds and it works on some very simple Apex code, it’s nowhere near ready for the big time. I’m going to keep working on it and hopefully someday soon it’ll be ready.

Other Projects

Escalations – Link – Another project still very much in it’s infancy. The idea behind this is to make an easy way for support centers to track escalations to cases. The plan is to have this both as a managed package as well as having the source available if you want to install it as unmanaged code.

SalesforceApps – Link – This is just a repo for random code that I’ve worked on that others may find useful. Right now I think the most useful bits are under the node_scripts directory.

Hands On Training – Link – Training is in my blood and it’s something I’ve always loved doing. You should checkout my hands on training. I have plans to migrate some others over to it as well as writing a couple more. You can follow the project if you want to be notified of updates.

There’s a great feature we use all the time in Solenopsis that isn’t as documented as it should be. This is the ability to write an XSLT to apply to your objects at time of pull, push or both.

Doing XML parsing in any language can be pretty tough. I wanted to share a quick how to for doing XML parsing in Apex based on a previous board post.

Let’s start with the data we’re trying parse

<?xml version="1.0"?>
<_CREDIT_SCORE for="Bob Dole">
  <_CREDIT_SCORE _CreditScore="668" _ReportingAgency="Experian" />
  <_CREDIT_SCORE _CreditScore="658" _ReportingAgency="TransUnion" />
  <_CREDIT_SCORE _CreditScore="660" _ReportingAgency="Equifax" />
</_CREDIT_SCORE>

For this data we want to pull out who the credit report is for and the credit data from the for field as well as from each of the _CREDIT_SCORE elements the agency and the score.

A very common use case for integrations with external systems is to have a service user that is authenticated and all subsequent interactions happen via that user. This flow is super easy when you can do username / password auth, but it becomes much harder when you’re only option is to use the oAuth flow.

Use Case

In a recent developer board post, a community user asked for help storing their credentials from the oAuth flow to box.com and then create a new folder whenever an account was created. The problem they were facing is that when you do the initial oAuth flow, you have to approve the use of the app and this requires human interaction. This is not something you can do inside of a trigger, so we’ll need to find another way to do it.

Soon, Salesforce will be requiring all connections to be TLS v1.1 or higher. This poses a problem for anyone using SoapUI with Java version 1.7 as that version of Java does not have TLS 1.1 or higher enabled by default. If you attempt to connect to an instance that has the “Require TLS 1.1 or higher for HTTPS connections” enabled you will get an error like the following

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="urn:fault.enterprise.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:UNSUPPORTED_CLIENT</faultcode>
            <faultstring>UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.</faultstring>
            <detail>
                <sf:UnexpectedErrorFault xsi:type="sf:UnexpectedErrorFault">
                    <sf:exceptionCode>UNSUPPORTED_CLIENT</sf:exceptionCode>
                    <sf:exceptionMessage>TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.</sf:exceptionMessage>
                </sf:UnexpectedErrorFault>
            </detail>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>