stunnware's CRM corner

Filtered Views for Microsoft Dynamics CRM 4.0 - v4.2

2009-11-30T10:00:00+01:00

I rarely post about product updates on this blog, but this time I make an exception. The reason is that the new features in the Filtered Views are great and I want to share it with you.

So far the Filtered Views allowed creating dynamic views based on parameters being supplied at runtime. With "at runtime" I mean that you pass parameters in your CRM script code. That was good enough to view associated data going well beyond the capabilities of a standard CRM view. However, good is never good enough, so here's the list of enhancements in the new release:

UI Filters to define custom search fields in filtered views
Multi-Language support
An entity context to activate field mappings when creating a new entity from a filtered view
Script support to perform typical tasks like hiding toolbar buttons or colorizing views

Probably the best explanation of what you can do with these new features is the following screenshot:

Stunnware Tools for Microsoft Dynamics CRM 4.0 - Support for CRM Online

2009-10-02T22:00:00+01:00

I was asked yesterday whether support for CRM Online was planned for the Stunnware Tools and the JavaScript Factory. My answer was that it hasn't been implemented just because I never had access to CRM Online. That was a minor issue though, because I instantly got credentials to a test organization and even admin rights for testing. That was great and it turned out that having a framework combining a set of tools was a good decision, because once I had the code implemented to use the passport and CRM Online services, all tools started working instantly.

I had added support for the offline services recently and now the Stunnware Tools support anything: On-Premise, Partner Hosted (IFD), CRM Online and the Outlook Offline client. If I have implemented the automatic version check correctly and you haven't turned it off, then you may already be aware of the new release before having read this post.

The new version is available for download at http://www.stunnware.com/default.aspx?area=products&group=swtools4&subarea=swtools4-download.

Client Side Scripting - Converting date/time values to or from XML

2009-09-29T23:00:00+01:00

Being a mystery in the beginning it's now common knowledge how to use the CRM web services in CRM form scripts. However, there were two questions recently dealing with date fields. Date values in XML are notated in a way that you probably know from your .NET code, 2008-03-12T13:55:46+01:00 for instance. The .NET DateTime object can easily handle it, but the JavaScript Date object cannot. The Filtered Lookup of course supports date fields in queries and I implemented appropriate conversion methods. Feel free to use them.

Client Side Scripting - Customer Products

2009-09-28T17:00:00+01:00

There was an interesting thread in the CRM developer newsgroups recently. Assume that you have built your product catalog and use CRM to create opportunities, quotes, orders and invoices, or at least some of these entities. All of them refer to the products in your product catalog. Now consider your customers. If they order products from your company regularly, then they most likely store your products in their own system. However, they will use their own product numbers to refer to your products and when ordering they will tell you these product numbers and not yours.

The question was how to enable a user to search for a product using both the internal product number and the external product number, where with "external" I mean the product number used by the customer.

An easy solution is adding a custom attribute to the product entity, but of course you can then only store one product number. This approach doesn't work when dealing with multiple customers, unless you like having a product number field for each customer. As each product can have many customer product numbers, the solution is a customer product entity and a 1:n relationship between products and customer products:

The JavaScript Factory

2009-09-15T15:00:00+01:00

As mentioned in the last article published a few minutes ago I had some work to do in the recent months. New major releases of the Filtered Lookup, which now supports multi-select lookup fields, the Filtered Views, Favorite Views and finally the JavaScript Factory.

JavaScript Factory

Most readers of this blog certainly are developers and most are developing CRM solutions. One part of CRM development are form scripts and my personal feeling is that many if not the majority of developers are still using the CRM editor to write script code.

This editor is a simple text box without any added functionality and while acceptable for smaller code changes it’s a real pain when working with larger code files.

A simple workaround is to copy the code from the CRM code window into a JavaScript file in Visual Studio 2008. Visual Studio 2008 has IntelliSense support for JavaScript and at least provides help for the objects of the document object model (DOM). However, as Visual Studio 2008 doesn’t know about CRM, it cannot provide IntelliSense for CRM-specific objects.

Furthermore you cannot split large files into modules easily. It is possible to dynamically load JavaScript libraries into CRM forms, but managing such libraries is a manual step.

For developers using Microsoft technologies it's usually a no-brainer to use Visual Studio and developing CRM form scripts shouldn't be different. If you search the Internet for articles on how to edit form scripts in Visual Studio then you will find some and if they are sufficient for you then you're done. Anyone else is welcome to have a closer look at the JavaScript Factory, which provides the following features:

Creates a Visual Studio Solution for any CRM organization, extracts the JavaScript code and enables direct editing in Visual Studio 2008.
Merges the OnLoad, OnChange and OnSave event handlers into a single file for easier editing.
Allows multiple source files for each entity.
Provides IntelliSense support for the entire CRM form object model, including custom entities and attributes.
Saves and publishes changes directly from Visual Studio 2008.
Updates existing solutions with updated customizations.
Starts full create and update forms directly from Visual Studio 2008.
Manages organization-specific and -unspecific JavaScript libraries.
Builds the form script by compiling the form code and all referenced libraries. As a result you have a single script file in CRM, but can have dozens or even hundreds of modules containing these files.
Because of the file-based solution approach you can use version control systems to manage your code.
Supports On-Premise and IFD setups.

That's just the Visual Studio part. The CRM JavaScript Factory for Microsoft Dynamics CRM 4.0 is a server-side module that can be used to support developer teams:

Builds CRM form scripts on the fly without having to publish changes.
Enables developers to edit the script code and to take full advantage of the library management and IntelliSense support, even without the CRM JavaScript Factory for Visual Studio 2008.

The server component is code-complete but documentation isn't finished yet. Won't take long to complete though. If you are interested in this solution then go to the product page and download the documentation to get a first impression. The product page also contains information about how to obtain an evaluation license, in case you want to try it out.

The CRM 4.0 Metadata Cache - Part 2

2009-09-15T14:00:00+01:00

As I had some work to do recently it took much longer to complete this article, though the implementation was finished a long time ago. I have attached the code to this article and you can download it by clicking the download button in the top left corner.

The implementation uses two main classes, the CrmOrganizationMetadataCache and the CrmMetadataCache. CrmOrganizationMetadataCache is used to cache the metadata of one organization. CrmMetadataCache manages multiple organization caches, which is a requirement for any solution supporting multi-tenancy.

The implementation supports a variety of options. I included a wish list in the previous article:

It must provide an organizational cache.
It must be capable to deal with multiple organizations to support multi-tenancy.
It should give a choice between read-all-at-once and a lazy-loading approach.
It should never request more data than needed. For instance, if you request an entity with attributes and relationships and the attributes were already retrieved, then only relationships will be loaded and the result is merged into the existing cache.
It must be thread-safe. This is very important for server-side applications, where multiple users will call your code in parallel. The cache will be defined as a static member in your implementation, but static members are not thread-safe by default. Intelligent synchronizing of requests is important for a good performance.
It must have methods to persist itself. Saving a cache to disk and loading it when the application starts again is much faster than requesting the data from CRM again.
It must have the ability to check for updated metadata and to clear the cache if the metadata was changed. As this is not required by all applications, appropriate settings have to be available.
Helper classes must exists for easy language management, though this can be implemented at various places. A short explanation: when reading the metadata you are running under a certain user account. This user account (systemuser) is used by CRM to retrieve the user's language settings. All UserLocLabel properties in the returned metadata contain the localized labels for this user. When you cache the metadata and simply user UserLocLabel to access display names, then all users using a different language will be somewhat disappointed. Instead of using UserLocLabel you have extract the appropriate label from the LocLabel collection. For that to work you need to retrieve the user settings first and use the language settings as an argument into the LocLabels array. It isn't too complex, but worth to be put into a helper class.

With the exception of the last item in the list all features are available.

I cannot guarantee that the code is free of errors and I also don't say that it's perfect. But I added a lot of comments to make it easy to understand. Feel free to use and enhance it.