Preface
In a previous post, I talked about how to log in to Salesforce with CasperJs. At the time I did not have a good example of what to do next with it. Well, this week I had a need that is something that other people can relate to.
In a previous post, I talked about how to log in to Salesforce with CasperJs. At the time I did not have a good example of what to do next with it. Well, this week I had a need that is something that other people can relate to.
Anyone that has ever had to deal with editing multiple Entitlement Processes in Salesforce will know the pain of having to do this in multiple environments and making sure you don’t fat finger this manual process. In the past when I’ve had to do this, I’ve either sucked it up and did it manually, or did it with Selenium. I wasn’t a big fan of either of these solutions since I’m a command-line kinda guy. That’s when I was told about CasperJs and I think I’m in love.
As I wrote about a long time ago I use to use a custom script with irssi to push to mumbles. Well, mumbles has gone defunct and I couldn’t really find a good growl client for linux. Plus with me traveling into the office weekly, it’s just not going to work well since growl is more push notification. So this lead me to research a true messaging system to try it.
We use Elluminate Live! for some of our meetings, and it has always bothered me that I have to launch the browser to use Elluminate especially for reoccurring meetings. So one afternoon I set out to fix this problem. I wrote the following script and have been using it for about a month now without any issues. You can set the parameters at the head of the script if you have a reoccurring meeting you want to use, or set the parameters at run time (or in an alias for multiple reoccurring meetings) if you need too.
Today I started setting up the repository for people to use to install the Solenopsis rpm. The problem is I want to be able to build the rpm (via Jenkins) and push it to a remote server and automatically have the repo rebuild when it sees an rpm updated or added to the directory.
To do this, I wrote a small python script that can be run and backgrounded. It sends a pushover notification and runs createrepo against the target directory.
The other day I came across a problem where sending in a blank field to Salesforce via SOAP was not nulling out the field. Instead, the enterprise WSDL was treating this as if nothing was sent, and therefore not updating the field at all. This make sense. If you were to send a sparse data structure over with only fields you want to update, you wouldn’t want to either have to provide the current value of every field or have them all nulled out. So, how do you null out a field with SOAP via the enterprise (or partner) WSDL in Salesforce?
One thing that comes up a lot in the in the #salesforce IRC channel is doing dynamic Visual Force driven off of picklists. So, let’s buckle up and get to it.
In this simple example we are going to make an extension to the case page. On this page we are going to us a custom Product/Version object to display on the page. The product list well be determined on the start/end date of the product. And the version will be driven by the currently selected product. Product
Version
One thing I find myself doing a lot is swapping two files in bash. I thought about making this into a bash script then I realized 1) that’s over kill and 2) not as portable as I want. So, if you add this to your .bashrc then re-source it, you’ll be able to run the command swap to switch two files
function swap() {
TMP_NAME="TMP_$RANDOM"
mv "$1" "/tmp/$TMP_NAME" && mv "$2" "$1" && mv "/tmp/$TMP_NAME" "$2"
}
Scheduled actions in Apex are great to use when you need to have a section of code run at a particular time in the future and Time-Based workflows will not work. In the example below I’ll talk about how to schedule code to run at the first of every month, in addition talk about some constructs you can use to make your life easier when you have to redeploy/change this code
In a previous post I discussed how to test Salesforce webservices with soapUI. In this post I will show how to use the “default” methods inside the enterprise WSDL.
First we need to login to Salesforce and get our session Id. Under the SoapBinding list, expand login and choose Show Request Editor. After opening the request editor we need to remove the extra headers we don’t need, and fill in our username and password.