If you haven’t seen my post about SchemaPuker, check it out here.

The story begins last year, when a colleague of mine David Everitt built a handy tool for generating ERDs. It was essentially a visualforce page / controller that allowed you to choose objects and then it would output some text in the format of a PostgreSQL Schema file that you could then import in to Lucidchart.

PostgreSQL schema files are relatively easy to generate (as they are essentially plain text) and Lucidchart was the diagramming tool of choice where we worked, so this all made sense.

I saw this, and thought it was a brilliant idea. ERDs are something that are very often part of design documents, proposals, etc. Even if you are building new functionality, often you are using some, or all of the existing data model, so having a way to get this out of salesforce easily was very helpful.

You can read more about David’s tool at his blog, SlightlyTechnical, including how to try it yourself.

However, a visualforce page / apex class has its limitations.

  • If you were doing a discovery, perhaps you don’t have credentials to organisation you need to chart, or if you do perhaps you don’t have a sandbox, or permission to install anything in one
  • If you do have credentials and a sandbox, you then need to add the visualforce page and controller in to the org
  • It would just output the results into the page itself, making it harder to import into your charting tool

So I decided I would make a new version of the tool, plus it was a good excuse to play with the salesforce metadata API, which I hadn’t had a lot of exposure to at the time.

I decided I would throw together a Java application to do this, I had written plenty of little console based apps in the past, but had never done anything with a GUI, so this was yet another learning opportunity. I built the app using swing, the force.com WSC, utilising the metadata API and the SOAP API to handle authentication.

The application worked fine and had all the same functionality as its visualforce counterpart, with the added bonus that it would generate a text file, rather than display the output. After that, I got busy with life and forgot about it all.

This year, after giving my blog a bit of a refresh and thinking about what I could write about, when I remembered the tool. I dug out the source code, looked at it, cringed and thought about how I could make this thing better.

The obvious solution here was a cloud based app. Something that required no installation or setup, and was easy to use. Given that I already had a my previous iteration written in Java (and Java is the language I am most comfortable with) heroku seemed like the best fit for hosting this.

Life got in the way again, and it wasn’t till after a trip to surfforce (see my writeup here) and a discussion with Dave Carroll from salesforce that I thought about it again.

Dave was telling me about the work he had done on the force.com cli, and the plans to extend the tool. I told him about my at-the-time named ‘Salesforce ERD Tool’ I was planning to move to heroku. He suggested (quite rightly) that that was a rather boring name, and came up with the idea of calling it ‘SchemaPuker’, and the name was born.

After surfforce I decided I would tackle this. I had never written a java web-app, nor had I used a web framework or deployed anything to heroku before. So with yet another great learning opportunity I set about learning how to do this.

I chose Spring MVC as my framework, mostly due to the huge amount of documentation for it, its uncanny similarity to visualforce and Spring Boot, which made testing the app locally *really* easy, and allowed for no xml config files.

I decided I was going to use the salesforce lightning design system in for the UI of my application, it looks nice and there is an excellent guide available for it.

Next, was taking a look at authorisation. My previous tool used the SOAP API for authorisation, however this was not going to be suitable here. Using OAuth2 made much more sense (so much so that I made a post about it here).

 

Once I had authorisation sorted out, I was able to reuse most of the core of my original application, and once I had the UI tidied up, I had a minimum viable product. I do have some ideas for enhancements for the next version, such as graphical output, stored groups of objects and a better interface for choosing objects.

2 thoughts on “SchemaPuker: How it came to be

Leave a Reply

Your email address will not be published. Required fields are marked *