There is a little known feature in CRM 3.0 called the Metadata Browser. You can find this feature by pointing your browser at http://<myserver>/sdk/list.aspx. The Metadata Browser is a set of web pages which lets you view an Organization’s Entities, Attributes and Relationships.
Michaeljon Miller wrote up the tool in the 1.0 days and it eventually shipped in 3.0. More info on it’s history and can be found in his blog post here. I’ve also seen people call the metadata service directly to automatically document their Customizations using Word, Excel, XML etc.
I’m interested in finding out what people are actually using the Metadata Browser for. Is it a good way of just looking at the Metadata. Do they cut and paste it into documents? Feel free to send your feedback in the comments of this post or email me directly.
The benefit of the metadata browser is that it displays more information than the metadata service currently returns.
As I'm heavily using the metadata and dynamic entities, I have to look at the metadata quite often, so I'm using my own metadata viewer (complete source available on my web site) which is much faster than clicking through web pages.
Although the tool is useful for a quick view of the fields you have, their size etc... What would be really usefull would be a further breakdown and/or option to view any associated Jscript on the fields and forms. Quite often people will 'just add a bit of code' and not document it. Then you have to find it!
Hi Michael - which specific pieces are missing from the metadata service that you'd like to see?
I'm not using it often, but it is useful for creating documentation. I'm using it to quickly determine which fields are of which type and if its a text field, then what the maximum size is.
It would be great if it could be exported immediately to be used in documentation. Some different view would then be needed. One like now with all data, another view based on the data which is visible on the screens etc. Also it should be possible to define which columns should be shown.
I would like to see the additional settings in relationships (cascading rules, conditions) and I also would like to see the EntityNameReference as a separate attribute type. Today it's returned as a PicklistAttributeMetadata. If I rely on this when creating (very dynamic) code, I'm producing a PicklistProperty which obviously fails, as it has to be an EntityNameReferenceProperty. Today I have to hard-code the properties to make it work.
In general you should provide all information available in the metabase. If you don't, there will always be someone asking for it.
We have used this for implementation of two tasks.
1. Read the nav bar items of entity - Relationship entities of any entity.
2. Read the attribute values for the entities. e.g how many no. of contacts against one account entity.
Also i am using this for studying & documentation. It is good way to have details in browser.
Well I'm not very technically minded, but it looks like a much quicker, easier and more intuitive way of looking through entities, attributes etc.
This could help me when I create forms and find attribute names for embedding in e-mails etc, which never seems as straight forward as it should.
It might also help me get my head around how relationships work.
It also helps me how the whole thng fits together, and to see the customisations we've had done, so I can understand a bit about how our customisations have been done, and discuss these in a (slightly) more intelligent manner.
So, maybe it even has vale for
I've used the metadata browser until Michael Hoehne released his metadata viewer. I use it sometimes now to take a quick look at the objecttypecode of a custom entity.
I also very much agree with Michael on what the metadata service should return: everything that's in the metabase. You know, 3rd party developers want access to all the info the CRM team has :).
But most important, the metadata should be trustworthy and at the moment it's not for field sizes. See http://www.cwrmobility.nl/weblog/2007/01/trusting-crm-metadata.html to see what I mean.
I totally agree on that. I 've read your posts before and there shouldn't be any magic behing the scenes. The metadata *must* reflect the underlying data source, otherwise we run into problems sooner or later.
I started a small project today that generates a MSDN-style chm file of a CRM server system and I'm wondering if querying the metabase is sufficient. Maybe I'm adding some code to query the database structure as well to highlight these differences. We'll see.
Sweet. I know this is going to be a tool I start introducing to my partners. Thanks!
I think it serves its purpose. I am thinking of it as a data dictionary. It does more than that. I am happy to see that it something like it available.
There is a little known feature in CRM 3.0 called the Metadata Browser. You can find this feature by pointing your browser at http://&lt;myserver&gt;/sdk/list.aspx. The Metadata Browser is a set of web pages which lets you view an Organization’s
I use this tool for documentation purposes, such as creating data dictionaries for clients and so forth. Its usefulness is limited as it doesn’t include the field display names.
Can I please know if i need to access it do i need to have the sdk installed on the server.
The SDK is already installed. It is not a separite install. The documentation is at http://msdn.microsoft.com/en-us/dynamics/crm/bb501031.aspx Enjoy