Every so often, I get it in my teeny little head that I can write code. This is probably due to the fact that I once, in ye olden times, wrote what then passed for as code. So, my wooly brane says: Write some code! These thoughts come to said head over the weekends and I figured I should at least write aboot what I've done this weekend so it doesn't, as so many others have, fall into disuse in a lonely directory of my harddrive. At least the embarrassment of having shown it to the 2 people who read my blog (hi mom!) will motivate me to continue messing with it.
This weekend is "CRM Helper" - a windows forms application to help CRM Developers restore, import, publish, build, deploy, and load data into an organization so that they can develop and test. A big fat caveat here is that this app draws heavily from the command-line only versions of these applications created by one
Mr. Jack Hand. So, with that said, you can take whatever this is with a grain of salt.
This was my design process: Wake up at 8:30a on Caturday, think & draw until about 9:30a, go hang out with WSJ on Kindle, Rocky Patel and Abigail, then come back and program for a few hours. Sunday, repeat, with some variation. This is what I ended up with:
Goals of this weekend's project were to:
- Create a one-stop-shop app that could do all steps involved in a full restore to deploy to create a test/dev-ready organization
- Restore a CRM Organization from a database backup
- Import & Publish CRM Customizations
- Build the CRM project, deploy to the server, register plugins
- Load in Sample data
- Refine each step into a more wizard-like process so that the intricacies of the various steps aren't a knowledge prerequisite
Future goals are to:
- Have one big red button that does it all (chains all steps) for a non-developer audience
- Use the Crm Deployment API to restore orgs
- Allow remote usage in addition to on-server usage
- Create libraries out of the command-line code
Parts that are working (but I'm not happy with) are:
- Preferences - this is actually fairly good, but it's missing organization (and a "Microsoft" style), and persistence
- Restore Database - calls an osql command as expected, could use some threading
- Import & Publish - calls crmimportpublish.exe, and needs to be turned into a library and threaded properly; too many windows, can shorten
I always learn a whole lot more about .NET and winforms programming along the way, so my major challenge is to keep on focus and not spin off into how to best thread a process or best persist settings. For me, once the core of the app is done (all features work, maybe not as expected, but work) the I can go back and refactor and optimize. Refactoring and optimizing before the first cut of the full scope of the app has been done has, in my experience, tended to slow me down and discourage me from completing something, feeling like I have to go back and add in the latest thing I've learned. Granted, that's not always completely true - if I find something compelling enough, I will refactor, it's just a risk to the first-cut scope being completed.
Next steps here are to make sure all parts work and then persist settings. Major refactoring comes in right after that.
The client where I work has a set of analysts, a majority subset of whom are used to looking at a software application as “database-driven,” meaning they need to see the database table schema in order to understand the flow of the application. They’re technical enough that they can use the “language” of a database’s table diagram, its glyphs, to understand the business logic that it represents. They’re familiar with a database’s Entity-Relationship Diagram (Database ERD). They consider themselves masters of creating a database ERD and using that to communicate to a DBA what sort of database to create and to give that to a .NET developer to tell what to build around.
With Microsoft Dynamics CRM, as with other Enterprise-class software applications and many ORM-driven applications, the underlying database schema isn’t the “language” the business is written in – that underlying table schema is the representation of the CRM framework’s data store. The CRM Database ERD doesn’t contain only the business’s logic but also CRM’s. If CRM’s power is enabling business processes, then when these types of analysts look at a reverse-engineered database ERD of CRM’s organization database for insight, they come away bewildered, not understanding how such a different schema could even manage to encapsulate their business, or worse, irritated that it’s so difficult to read the database table ERD and can’t see how CRM would make application development any faster than if they just created a custom ASP.NET application.
One of the major issues they have is with a classic CRM Design Pattern – the Denormalized Attribute Pattern. This pattern provides one way of solving the need to display information on an entity from one or many related entities – copying them to the main entity in question. From a database ERD standpoint, it appears that there’s duplication of information, a major red flag from a database design perspective. Even when not using this design pattern, looking directly at a CRM database with its two tables per entity on custom entities and its attributes for related “foreign keys” for N:1 and N:N relationships tend to confuse analysts who aren’t familiar with the CRM framework.
What’s the solution to satisfy an analyst who feels like they’ve lost their primary means of communicating business data storage and logic via a db ERD? A better “language” or glyph system would be UML, a notational representation of an object model, or a more abstract (actual) Entity-Relationship Diagram.
In some following posts, I’ll describe communicating business and technical analysis via UML and a custom CRM ERD language and how it relates a traditional database ERD, particularly one reverse-engineered from a CRM organization.