Visibility for Apex in Managed Packages

by Patrick Connelly posted on August 16, 2016

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.


Getting Data Out of Salesforce

by Patrick Connelly posted on August 13, 2016

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.


Heatmap for Contact Locations

by Patrick Connelly posted on August 01, 2016

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.


Opensource Update

by Patrick Connelly posted on July 28, 2016

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 StyleguideLink – 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 CheckstyleLink – 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

EscalationsLink – 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.

SalesforceAppsLink – 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 TrainingLink – 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.


Solenopsis with XSLT

by Patrick Connelly posted on July 22, 2016

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.


XML Parsing in Apex

by Patrick Connelly posted on July 14, 2016

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.


OAuth Flow for service users in Salesforce

by Patrick Connelly posted on July 05, 2016

When this article was originally written Named Credentials weren't really a thing (or at least not something I really knew about). Using that is going to be a better and more secure way to do this.

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.


SoapUI TLS 1.2

by Patrick Connelly posted on June 27, 2016

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>

Parse JSON with Reserved Words

by Patrick Connelly posted on June 21, 2016

One of the great things about Salesforce when dealing with external webservices is being able to easily parse JSON into Apex classes. I’ve covered this in several previous posts. However a common problem is that the system you are integrating with is they may be using a variable name that is reserved. With the following data, we can see that there is a variable named “case” if we ant to parse this data into a Apex class we won’t be able to because case is a reserved name.

{
    "data": [
        {
            "case": "123456",
            "subject": "Test case"
        }, {
            "case": "789012",
            "subject": "Another case"
        }
    ]
}

Clean REST Endpoints in Salesforce

by Patrick Connelly posted on June 13, 2016

One of the things I love working on are webservices. However, one of the things I dislike about using SOAP is that using the endpoint isn’t as nice as it could be. This is something that has been addressed by how REST endpoints are interacted with. By writing clean REST endpoints, your users can easily understand what is going on under the hood

Clean REST Endpoints

What do I mean by clean REST endpoints? Let’s take a look at two possible URIs and see which ones are cleaner and easier to understand. For the examples below, we are going to have two URIs, one to get a case by case number, and one to get it’s comments

#Get case using url parameter
curl "$SFDC_URL/services/apexrest/v1/cases?number=012345"

#Get case comments using url parameter
curl "$SFDC_URL/services/apexrest/v1/comments?number=012345"

#Get case using number in url
curl "$SFDC_URL/services/apexrest/v1/cases/012345"

#Get case comments using number in url
curl "$SFDC_URL/services/apexrest/v1/cases/012345/comments"

While the parameters are perfectly acceptable, they are not pretty. Also, it is difficult as a programmer to know if the param you have add to the URI is number, or casenumber or what. So instead if we have clean REST endpoints, we have the case number as part of the URI and it is just more logical as to knowing how to get a specific case.