A quick start to SF Console
by Simon Goodyear.
Average Reading Time: about a minute.
I thought I’d add a quick guide to getting the demo installed and running to save you having to read all that guff in the other posts.
1) Download and install this package into your SalesForce Org.
2) Log into this site with your SalesForce credentials; keep this window open.
3) Call Console.Write(‘Hello World’); from you Org – be it anonoymously or otherwise.
4) Go back to the window opened in 2) and either be amazed at how good it is, or unsurprised that it didn’t work
Alternatively if you’re feeling brave and want to get all the code and set this up yourself then you can get the SalesForce part of the app from this GitHub repository and the node.js part from this one.
It runs over over HTTP at the minute as I had a socket issue on HTTPS.
I’ve also been having a bit of a think about some things that it would be nice to add to the solution and I thought that I’d just make a public note of them in the vain hope that it forces me to do something about them.
On the UI: a clear button, maybe the option of a different colour scheme, sort out the having to refresh occasionally.
Within SF: the ability to turn the logging on and off, maybe log levels.
In General: perhaps a few screenshots of how to set it up and use it – although it’s not that complex.
These are my initial thoughts for enhancements, more suggestions are welcome as are forks on GitHub and pull requests… saves me the work after all!
Let me know of any difficulties… have fun.
This is the best piece of force.com work I’ve seen since Mike Leeches mobile framework. I’m gonna check out the code at some point but I’m guessing you’ve used web services. Does that mean that all the @future limitations apply?
Thanks. I thought about using webservices but the @future limits put me off. I took a slightly different route – I actually create a record and have an outbound message set to fire on it’s creation. It does mean you start pushing DML limits but these are higher and it’s a trade off. I have half an idea for getting it to work a different way but I’m fairly sure that it won’t work so we’re stuck with this for now.
Ah that’ll do the trick. So if you’re creating records then your DML statements can’t be dropped into constructors or getters/setters? I’m asking because I’ve puzzled through this problem a few years back and it looks like you’ve solved it!
I wasn’t aware that you couldn’t put DML in certain places (another area of force.com ignorance I have) – actually I just tried DML in a class constructor and all was OK.
I did a quick search and came across your post about this It’s funny that you should mention a log4j clone as this whole thing actually came out of my desire for the same thing! I have the guts of a logging framework that sits within the platform all set and almost ready to go (log4force anyone?) – this just became a more interesting distraction. The ideal situation would probably be some combination of both of these ideas – actually an ideal solution would be to have it baked in with the option of using an external endpoint.
Anyway, back to the point – if DML is restricted in some places then maybe adding an option to force the Console.Write() call to make a webservice call rather than DML would be useful?