I know that this post isn’t my usual fare but I feel that after the week that has passed I should write something, if only to record my own thoughts. Just in case you’re wondering what I’m referring to it is of course the recent referendum in the UK about it’s membership to the European Union.
As hopefully you’re all aware there is a little event happening in London next Friday called London’s Calling It is our take on the similar community led events happening across the US and is by all accounts set to be the best event in the European Salesforce calendar – sorry World Tour 😉
Much has been written about the event by sponsors, speakers and other members of the community but I wanted to write something myself. In particular about the dev content of the event.
When asked the question: “Just when does asynchronous apex actually run?” Most people will answer by saying something along the lines of “when the system has available resources”. And they’re correct, or at least partially correct as there is one other important thing to remember; it won’t run until the successful completion of the current transaction. But is this always the case?
Why is this important?
Let’s take a simple and common example; we need to call an external webservice to keep some data in sync as it changes within Salesforce. Since we can’t make a callout from within a trigger the accepted pattern is to call a future method (considered to be asynchronous apex) with the callout=true flag set. This creates a new transaction for us that isn’t part of the trigger and we’re free to call our external system.
This is all good so far. Now let’s imagine that for some reason our trigger, after calling this future method throws some kind of unhandled exception. This means that the whole transaction is going to be rolled back with no changes being committed to Salesforce. If our future method executed as soon as we called it we would now be in a situation where the external system is out of sync with Salesforce. Hence why the platform waits for the current transaction to finish successfully before letting it be run.
So why are you bringing this up?
Let’s be honest I’m not going to be bringing this up purely for the educational purposes of the masses. I’m bringing it up because I believe that I have found an annomoly with this expected behaviour. Let’s look at the following code, a trigger and a helper class;
Pretty straight forward stuff. So what am I expecting to see if I run the following execute annoymous code;
Well, we’re inserting 300 records and we know that the platform batches calls to triggers up into 200s so we should come through our trigger twice and as such call two future methods. We should be able to see that in our debug logs. Also we remember that both executions of the trigger are in the same transaction (the debug of the count shows us that too) therefore both of our future methods should run after the trigger transaction has completed. And if we look at the timings for the trigger and the future methods we can see that this is indeed the case.
So far all I have done is to describe what should happen and then demonstrate that it does happen; not the most interesting of post. Let’s alter this example slightly and see what happens. Instead of inserting the data using an execute anonymous block let’s use the data loader. I have loaded a simple CSV file with 300 accounts in it via the Data Import Wizard. We’re loading the same data so we’d expect to see the same results in the debug log.
If we check the execution of the trigger itself we can see that we have, as expected, passed through it twice and within the same transaction. So that’s good.
However a closer look at the times of execution highlight a problem. We can see that one of the future methods is being executed before the trigger transaction has completed. This is not how we expect the platform to behave.
Is this really such a problem?
Yes! Yes it is. Let’s change our code to throw an exception in the second pass of the trigger. And then rerun our two tests.
In the first test, the execute anonymous one, we see that the future methods never run. This is good, remember our sync example before? If there’s an unhandled exception and the transaction gets rolled back then we don’t want to communicate with the outside world.
The second test, loading via the data import wizard, doesn’t look so good.
We can see that one of the future methods has been executed despite the fact that in reality the whole transaction should have been rolled back. So, whilst no records will have been inserted our future method is still called. It’s interesting to note that the second future method isn’t called, the one that is in the same trigger execution as the exception.
What can we do about it?
To be honest I don’t think there’s a great deal we can do about it other than be aware right now. I have seen this behaviour with queueable jobs too, so I am presuming it affects all asynchronous apex. My personal next step is to raise the issue with Salesforce and get some clarity around it and whether it’s a bug.
It’s all about Lightning right now and rightly so it’s the future; a good looking, exciting future. So what have I been doing with all of this then? I always find new technology is best learnt when you have a real use case and I have been lucky enough to have one to work on over the past few weeks. Not only that but it’s one that has lead me to have to do something that I couldn’t find documented anywhere!
Last week at the Paris World Tour I was asked a question about the getContent() and getContentAsPDF() methods on the PageReference class. I was rushed and gave the best answer that I could at the time. However, as the two gentlemen left me I had a nagging feeling that I was missing a piece of information. This morning I have finally found the time to come back to the question and get the complete answer. But first the question;
Why do getContent() and getContentAsPDF() throw an exception when called from a future method, despite the documentation saying that you can do this?
Lightning Process Builder has been around a while now and I think that we’re all starting to get use to it and see it’s potential; it’s massive.
There are of course a few teething problems, as you would expect, and they have mostly been documented but I just wanted to add to the list. Not as a complaint, more as a warning.
One of the biggest challenges that I face when writing my code is making sure certain things are enabled in an Org. For example some people still don’t have Chatter enabled so trying to post to a feed is going to cause my code to blow up. Each time I come across something like this I always have to go hunting to find the best way to figure out if something is on or not. This trawling of the internet finally got the better of me the other day and I have started a Feature class.
A few days ago I noticed that this blog wasn’t looking like it should.
— Simon Goodyear (@simongoodyear) January 13, 2015
In fact it turns out quite a lot of it has disappeared. So firstly apologies if you’re getting here through search results – most of the content behind those permalinks is no more. And that which is left appears to have completely been messed up.
I am currently working through getting all of this information back but it’s not going to be an overnight return to it’s former glory. However, new posts should continue to be added and more importantly I will turn that backup feature back on!
We all love Visualforce, right? It gives us the chance to have that finer grained control over how things look for users and users love us making things look good for them – often much more than any functionality we provide. And when dealing with Visualforce, it’s often not long until we need to write a Custom Controller or a Controller Extension in Apex to allow us to fulfil some requirement or other. Controllers provide us with three main functions; to provide access to data, to provide us access to business logic through actions and to provide navigation. Actions and navigation are pretty straight forward as there is only one way to implement them in your controllers. Data however can be implemented in two ways and what’s worse… at the same time!
I learnt something rather intriguing today on the old Force.com platform: decimals just don’t behave how I expected them to when converting them to strings. I have obviously set myself up with that line but nevertheless let me go through the motions.
Before today I would have expected the following code to display the same three strings on each of the lines.
That is, despite how I declared the decimal in code, they would all be stored the same and hence all output the same way – truncated to zero decimal places in this case, given they are all exactly one. However when I run the page I get the following result:
This struck me as a bit odd as it’s actually remembering how I declared the number and then using that when it converts it back to a string.
This got me thinking a little bit: is there some weird bug where by the numbers are considered to be different? I didn’t think this was the case but you can never be too sure so I added the following two methods to my test class and got the following output on the page:
As expected comparing the numbers they are the same; they are both exactly 1. However comparing the strings we see that they are different (I know we could see that from the previous output but it’s always good to see what the compiler thinks).
My next thought was what does it do when we add decimals together that have been declared with a different precision? This leads to the following tests:
We can see from this that order of inputs doesn’t matter and that the result will always have the precision of the most precise input.
So now that we know how it all works, even if it wasn’t what I originally thought, but where does that get us? Well strangely enough I had an application for this pretty much straight after I discovered it. I had to send a JSON object to a ReST service and needed to make sure that all the numbers I sent were formatted to show two decimal places. This little oddity means that I can simply multiple my input by 1.00 and I know that when I take the string value of the result I will have everything formatted just the way I want it. Perfect.
It has been rightly pointed out to me that this phenomenon is expected and well documented behaviour (SF Docs) Thanks gain @jamesmelv before I write my next post I will promise to read the documentation.