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"
        }
    ]
}

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.

Salesforce has released a new section under Trailhead called Superbadges, and they’re pretty awesome.

Superbadges?

Superbadges.

So if you’re familiar with Trailhead Projects, Superbadges are very similar to these but instead of guiding you through the process, you are given a set of requirements and you are required to implement it. All of the badges have requirements that you must meet before you can even start them. This is nice because it encourages you to learn the content before diving in. This way, the challenge of the badge is just building on your existing skills instead of teaching you new ones. For the first release, there are four Superbadges that you can earn:

At Dreamforce 2015, I wrote a hands-on training for Salesforce University and presented it both as a Dreamforce session, as well as recorded it for use on their site. I had a great time writing the content as well as delivering it in their studio. However, the problem is that the content is locked in place and the content isn’t 100% correct. Since publishing it, I’ve found some typos in the guide as well as some mistakes in time calculations. Because of this, I wanted to make the training available in a format that was easier to update as well as easier for people to report issues against.

It’s a pretty well known fact that I’m a big fan of Entitlement Management. I’ve given a Dreamforce talk, been recorded by SalesforceU, and even have a github repo for it (it’s a work in progress). So when I heard that the Trailhead team was releasing a new Entitlement Management module I was ecstatic.

That's a bunch of Red Hat!

May 15th marks my 10th year anniversary at Red Hat. That’s a bunch of time to be at one company, so I thought I’d take a couple of minutes to share my career path over the past 10 years as well as some fun pictures.

Keeping on the PDF and Trailhead theme, lets take a look at adding watermarks to our PDFs. There was recently a developer boards post about watermarking a PDF and it dovetailed nicely into the previous posts.

With today’s PaSS offerings, you may find yourself in a position like I was. Let’s take the scenario of hosting an application on Openshift, but also wanting to store that code on Github. Historically, anytime you wanted to do a git push to both Openshift and Github, you’d have to submit two push commands. Now, you could write your own git alias to do that for you, but I recently discovered a better way to do this. (This also works if you are using Heroku)

One of the downsides of the code I posted a couple of weeks ago to generate PDFs is that if you want to add new fields to your invoices, you have to edit the Visualforce page. By updating our Visualforce and using field sets, we can dynamically add fields to our invoices

After last weeks post, let’s take a look at how we can send a PDF attachment via a Visualforce email template. Our goal is to be able to automatically send an invoice to our customer whenever their Battle Station is fully operational. We will be taking the Battle Station Invoice PDF and making it something we can attach to an email and then create a workflow to send that email when the status changes to complete.