We’ve been slowly replacing all of our SOAP endpoints with REST endpoints inside of Salesforce. The upside of this is that they are much easier to use. The downside is that they are harder to functionally test without a bunch of work to generate session Ids. (This was made even more frustrating by a recent change that obfuscates out the session id in debug logs) So, I decided to figure out how to run a Postman request that would then store the session id and server url for later requests to use. This post will cover how to set that up and use this one request. I plan on writing more in-depth blog later about how to use Postman to test custom REST endpoints later.
I’ve written quite a few web services in Salesforce, and I’ve written about them a couple of times. And my love of testing is pretty well known. One thing that’s always been a problem is testing the web services in an automated fashion as a real consumer would. I’ve talked about manually testing them with SoapUI before, and while useful doesn’t fit into an automated process well. So let’s jump into the world of JMeter and how we can automate our web service testing for Salesforce.
I previously did a post on writing Jira Attachments from Salesforce, and the question has come up of how to write Jira Attachments into Salesforce. This is actually WAAAAY easier than it was to write attachments out. The way that the data is structured from the Jira, we can get a list of all the attachments and the link to it’s content directly from the Jira GET request. This makes for way fewer calls to get the actual content of the attachment.
I recently stumbled upon a “new” feature in Salesforce that allows you to use an Apex class to calculate your milestone trigger time for entitlement processes. Given a new feature that I’m working on for our entitlement process, I thought to myself that this could be a good chance to play with it and see what I could do. If you’re not familiar with the entitlement process in Salesforce, take a chance to look over (or run through) my hands-on training for entitlements so that you’re familiar with the terminology and the concepts since I’ll be jumping right in.
New servers mean new things to play with and new setups that have to be done. I set up a new VM that I wanted to always be connected to a VPN and for that VPN to come up whenever the system is started. The biggest “problem” here is that this VM is running in runlevel 3 so no GUI is available. So let’s jump into setting up an OpenVPN client using network manger’s command line interface
One of the challenges you get when you have a special snowflake org is lots of people want to write lots of reports and lots of dashboards for each of their special use cases. Now, lots of times reports aren’t the right way to go with this so you have to educate your users on the right way to do this and their old reports get abandoned. Or a user will create a one off report and never look at it again. As it stands right now, we have several thousand reports that haven’t been looked at in more than 90 days.
A while ago, someone posted on the developer boards a question about how to bulk create tasks for contacts via REST. I thought it was an interesting enough problem to cover how to do it and how to format the data correctly to use it.
Before we can bulk create tasks for a contact, we need to know how to identify those contacts. To do this, I create an unique external Id field called External_Id__c. As long as your contacts are uniquely identifiable then it doesn’t matter what field you use. For this example I have two contacts under different accounts “Andy Young” with an external Id of “ayoung” and “Edna Frank” with an external Id of “efrank”
After updating the Case object to API 38.0 I didn’t notice that the Case.Type field had changed. In API 37.0 this is what the Case Type field looks like
<fields> <fullName>Type</fullName> <inlineHelpText>The case type</inlineHelpText> <picklist> <picklistValues> <fullName>Value 1</fullName> <default>false</default> </picklistValues> <picklistValues> <fullName>Value 2</fullName> <default>false</default> </picklistValues> <sorted>false</sorted> </picklist> <trackFeedHistory>false</trackFeedHistory> <trackHistory>false</trackHistory> <trackTrending>false</trackTrending> <type>Picklist</type> </fields>
And this is what it looks like in API 38.0
<fields> <fullName>Type</fullName> <inlineHelpText>The case type</inlineHelpText> <trackFeedHistory>false</trackFeedHistory> <trackHistory>false</trackHistory> <trackTrending>false</trackTrending> <type>Picklist</type> </fields>
In the turmoil of all the other changes to the object file, I completely missed the change. And when the deployment failed I was at a loss to figure out why. The failure wasn’t about the picklist in particular, it was about the picklist value in a record type.
One of the problems I had with the way that we generated the PDFs in previous Battle Station Invoice posts was that the table header wasn’t repeated for long lists of supplies or resources that continued on the next page. There’s a simple way to add the table header for PDFs generated in Salesforce using the flying saucer mark-up but that won’t generate the table header correctly for us. It seems that the
-fs-table-paginate tag does not play well when combined with a Visualforce component so we’ll need to take a bit more of a native CSS approach.
NOTE: If you are doing this with plain Visualforce and apex:pageBlockTable, the -fs-table-paginate is the way to go.