Regular readers of my blog will recall my last post charting my exploits with the Salesforce Tooling API for a session I’m running at Dreamforce 2013…
Dreamforce 2013 Session: Apex Code Analysis using the Tooling API and Canvas
The Tooling API provides powerful new ways to manage your code and get further insight into how its structured. This session will teach you how to use the Tooling API and its Symbol Table to analyse your code using an application integrated via Force.com Canvas directly into your Salesforce org — no command line or desktop install required! Join us and take your knowledge of how your Apex code is really structured to the next level!
As I hinted at in the last blog I was not 100% happy with the Mind Map visualisation I initially used. It was fun to play with, but I wanted to illustrate the use of the Tooling API with something more functional. So I went searching for a new library. I wanted something that was HML5 based, that would dynamically render as the user selected Apex classes.
Inspired by the ObjectAid tool, as well as some feedback comments describing a very cool PlantUML based Apex tool, impressively written currently without the Tooling API called PlantUML4Force. While PlantUML is a great library, it was not dynamic enough and ultimately I wanted to be able to better illustrate the separation of concerns in the diagrams by having more granular control over the final diagram. I eventually found a bit of hidden gem called UMLCanvas…
I’ll eventually share this as a package once I’ve had a chance to work on it a bit more (it’s currently showing only UML Dependency relationships). In the meantime please take a look at the new video below and join me in my Dreamforce Session to hear about how I built it!
Technologies involved so far…
- Heroku hosted Java application
- Salesforce Canvas Java SDK
- Salesforce Tooling API (via JAX-WS to consume the Tooling API WSDL)
- Spring MVC Framework
- jQuery
- UMLCanvas
Andy in the Cloud 
October 15, 2013 at 9:29 am
Great work ( I hope you will share the code) and thanks for mentioning my Github repo.
October 15, 2013 at 2:07 pm
Thanks Robert, i will indeed share the code in due course, and your most welcome for the mention, great work also!
October 15, 2013 at 9:37 am
The reason why I choose to use PlantUML is the fact that its diagrams are nicely layouted by the powerfus GraphViz library.
When you want to autogenerate UML diagrams from an org you will run into the same problem as Salesforce.com own Schema Explorer – unreadable diagram 😉
Relying on Graphviz means you rely on an non-native server component. That indeed is a problem. But I planned to solve this by hosting a PlantUML instance on a Salesforce.com own Heroku instance.
October 15, 2013 at 2:15 pm
Yes I actually spent about half a day going over and over the decision to use or not use PlantUML, the reason being it is very pretty and has an nice auto layout engine!
Ultimately aside from wanting something more drag and drop dynamic within the page. I also found that Graphviz is a native compiled executable, so was not sure if Heroku would tolerate that (as i also would prefer to host the library separately). I found some postings that suggested it would not, but did not dig deeper. It’s a shame there is not a Java version of it?
Also to keep in mind, is the maximum URL length, I’ve read reports on the internet this is 2000 characters, though can be considered to be more. Watch out for this if the UML information your passing to the hosted PlantUML end point via HTTP GET grows large.
BTW, one other thought I had, was to one day create an Apex Wrapper around the Tooling API, much as I have done with the Metadata API. This would allow you to keep your solution native. Though i cannot say if the Tooling API callouts and/or request size limits in Apex might yet present a problem in such an architecture.
Great as always to chat with you, are you making it to Dreamforce btw?
October 15, 2013 at 2:23 pm
If Graphviz runs on Linux, you can likely get it working on Heroku – worst case, you’ll need to create a custom buildpack https://devcenter.heroku.com/articles/buildpacks#creating-a-buildpack
October 15, 2013 at 2:24 pm
Interesting there is Linux build for it. Thanks Pat!
October 15, 2013 at 6:47 pm
@Andrew and @Pat: There even exists a Heroku buildpack with Graphviz on Github but I was not yet able to get this running:
https://github.com/jeluard/heroku-buildpack-graphviz
October 15, 2013 at 7:31 pm
Very interesting!
I will post the current Heroku app code soon and perhaps we can prototype an abstraction layer (perhaps based on the Tooling API types) to support a plugin architecture for multiple UML rendering and layout customisation approaches?
I have also been thinking about ways to persist and/or recognise UML metadata (notes and annotations) from the diagrams, either as comments in the Apex classes and or as a Document in the org perhaps?
Also wondering how we can provide ways for users to teach it to show certain UML stereo types, to recognise vf controllers, services and such like, perhaps map some styling to the stereo types?
October 15, 2013 at 9:02 pm
Regarding Dreamforce… I guess I will not make it. We only go every second year.
October 15, 2013 at 10:24 pm
That is a shame, you and i must have a Hangout on Google sometime!
December 8, 2013 at 11:47 am
I’ve created an Ideas list, if you are still keen to help progress this? I spoke to one other at Dreamforce who is also keen, the submitted already a small fix to the pom.xml file. I’ve also included an idea to provide multiple rendering engines. https://github.com/afawcett/apex-umlcanvas/blob/master/FeatureIdeas.md
October 15, 2013 at 3:12 pm
Nice stuff, we can seriously visualize design patterns! And, object inheritances.
October 15, 2013 at 5:12 pm
Thanks and yes indeed, I’ll be using it in my design patterns session as well i think! You’ll notice the demo uses the patterns sample app code already… 😉
October 17, 2013 at 9:01 am
Reblogged this on Sutoprise Avenue, A SutoCom Source.
Pingback: Apex UML Canvas Tool : Dreamforce Release! | Andy in the Cloud