If you’ve done much API generation then you’ll that you don’t want to have to make your users authenticate multiple times just because your API is going somewhere external. For example, if you have an API that reaches into Salesforce but your app uses Google SSO, you don’t want to have to present an oauth screen to your user after they’ve already authenticated. To work around this, you can use a JWT Bearer flow to login on behalf of a user and get a access token to work with.
I started down this path to flesh out a proof of concept for a related task. However, the Single Sign-On provider that we use is difficult to get access to and not worth the time to try to get permission to use it. So instead, I thought I’d just use my personal Google domain as the identity provider so I can get it done faster. So I’ve decided to document my journey and hopefully help someone else set this up.
If you’ve not noticed, ads on the internet are everywhere. On my personal machine, I run uMatrix in chrome and it works great for blocking things but that’s not really an option for all devices (like mobile phones) or for all users (like my wife and kids). This is where Pi-hole comes in.
Pi-hole is an application that runs a customized DNS (Domain Name System) server that whenever a system using it tries to look up the name of and if it’s on the Pi-hole’s blacklist it pretends that the host doesn’t exist. Thus your device can’t see the ad server and then can’t load the ad.
There’s a new feature in Salesforce called Change Data Capture that allows you to subscribe to a Cometd endpoint and stream changes to most or some of your objects. I’ve talked in a previous post about how to get data out of Salesforce and this seems like it might be the front-runner for one of the best ways. I would still plan on ways to get data if it exceeds the three day replay period and you’ll also need a way to do your initial data import.
What data can I get with Change Data Capture?
In a perfect world, everything you’d need would always live in Salesforce and you’d never have to worry about backing up data. Well, we don’t live in a perfect world. Lot’s of times you need to get data out of Salesforce and get it into an external system. You could do this for data backup, for populating a search index, for sending messages to an external system. With Change Data Capture, you can do this type of data flow in real-time.
Change Data Capture supports the following standard object (at time of writing):
In addition to the standard items above, Change Data Capture supports all custom objects.
One of the biggest reasons I wanted to set up Home Assistant was to be able to handle a “vacation mode” for my house to change things like the thermostats and lighting. The addition of an
input_boolean for this is really straight forward. However reminding myself to set vacation mode if we are away for a long period of time is something a bit harder. To do this, we need to calculate the away time for each user.
The linchpin for knowing if I should send a reminder is around how long a person has been away. Originally thought I could just use my Ubiquiti access point’s
last_seen time and calculate hours from there. However this field disappears after about 10 minutes of the user being disconnected from the access point. So I needed to find a way to persist the last_seen time event after the access point removes the data from the
If you’re not aware, having clean code is more than just about readability. It’s about sustainability, re-usability and knowing that your code is doing what you want it to do. This is where PMD comes into the picture. PMD is a static code analysis tool that takes code from many different languages, analyzes it and provides you with feedback. Fortunately for the Salesforce world PMD now supports Apex as one of it’s languages. So, let’s dive into how to set it up, run it and then how to use some of the rules included.
Now this little warmer may look innocent enough, but it’s a disaster waiting to happen. If you leave it alone, it will kill your whole family without remorse. Ok, that may be a bit hyperbolic, but these things can be kind of dangerous. According to the National Fire Protection Association in 2013 seven people died each day in the US due to home fires. And half of those deaths occurred between the hours of 11 pm and 7 am. Now, how many were caused by this cute little scooter, probably not many. But devices like this can cause fires. This scooter is a wax warmer. It heats up a tray that melts wax and makes your house smell lovely. But if you leave it on too long (by lets say forgetting about it and leaving it on for 48 hours) you get a different result. This has happened more than once in our household, and that’s what leads me to my first real world application of home automation.
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.