HttpCode

I came across an interesting problem recently deploying an ASP.NET application to the ISV directory in CRM 4, the ASP.NET application was working fine using the Cassini web server inside of Visual Studio, but when it was deployed to the ISV directory on the CRM server it failed to run.

Basically any postback caused the web forms to loose all it’s current data, so things like dropdown lists would end up blank.

It was pretty obvious that this was caused by ViewState being turned off.

The default web.config file of CRM looks like:

<pages buffer="true" enableSessionState="false" enableViewState="false" validateRequest="false"/>

Since the ISV directory inherits from this web.config file, all the applications in the ISV directory will also have viewstate disabled.

So just add the following line to your web.config file in the ISV directory:

<pages enableViewState="true"/>

Personally I don’t really see the need to enable viewstate, in most cases it isn’t needed if the programmer understands it’s purpose, but sometimes your just trying to deploy code that someone else wrote.

A lot of functionality can be added to CRM with JavaScript, if your like me and do the bulk of your normal web development JavaScript with a toolkit like JQuery, you will quickly miss the power and ease of doing things without it. The good news is that it is pretty easy to load JQuery into the page:

var script = document.createElement('script');

script.type = 'text/javascript';

script.src = '/ISV/jquery.js';

script.onreadystatechange = function()

{

if(this.readyState == "complete" || this.readyState == "loaded")

   setupPage();

};

var head = document.getElementsByTagName('head')[0];

head.appendChild(script);

Now you can use the setupPage() function with all your familiar JQuery goodness.

CRM 4 has lots of excellent customization options, one of which is the auto-numbering of entities:

The Settings – Administration section allows you to setup some options for auto-numbering your entities, you can choose the prefix, and the suffix length:

This is pretty powerful, but how would approach this problem if you needed your entities to have a more complex numbering scheme? Being a developer, everything looks like a development task to me. So I would start with a plugin that implements the IPlugin interface:

       public class AutoNumber : IPlugin

Then we need to implement the Execute method such as:

        public void Execute(IPluginExecutionContext context)
        {
           
            if (context.InputParameters.Properties.Contains("Target"))
            {
                DynamicEntity entity = (DynamicEntity)context.InputParameters.Properties["Target"];

                if (entity != null)
                {
                    if (!entity.Properties.Contains("AttributeName"))
                    {
                        entity.Properties.Add(new StringProperty("AttributeName", GetAutoNumber()));

                    }
                }
            }
        }

So the above code will check to make sure our input properties contains the ‘Target’ parameter, this will be the entity that is affected by the plugin. From here we can cast it to a DynamicEntity  which will make it easier to work with. Once we have an instance of DynamicEntity the whole task of updating and attributes becomes trivial, the above code just creates a new property and calls some method that will generate the complex AutoNumber.

Once the plugin has been developed, the next important step is to register the plugin. The best tool for the job is probably the CRM Plugin Registration Tool:

The first step is to register the plugin assembly:

This will prompt you with a form that allows you to select the assembly and the location it will be stored i.e. Database, file system or GAC.

Once the assembly has been registered we can register a ‘new step’, this is done from the same menu as the assembly registration.

You will be prompted to fill out the following form:

For our plugin we will choose the following options:

Message: Create  (since we are doing an auto number, it makes sense to only run the plugin at the create stage)

Primary Entity:  Your choice

Plugin: Your assembly that was loaded at the previous step

Post Stage: we want to run it after the entity has been created, otherwise the built in CRM auto numbering will overwrite our value.

Synchronous: lets fire the event synchronously, no reason not to, the end user will be presented with a consistent interface this way.

Step Deployment: your choice

Triggering Pipeline: Parent

As you can see its all fairly simple and straight forward, now you can have an auto number that be what ever you need, it might be simple like some combination of a financial year or complex where a lookup to some external system needs to take place, but at the end of the day at least there is a nice mechanism in place to help you out.

A little while ago I created a simple Application Definition for working with some CRM 4 data via the BDC.

Well recently the CRM Search Accelerator for Microsoft Dynamics CRM 4 have been released, which provides a better Application Definition File:

The enterprise search accelerator allows Microsoft Office SharePoint Server (MOSS) customers to view and search for Microsoft Dynamics CRM data directly from their SharePoint portals. By combining these two technologies users from different areas of the business will be able to:

• View and edit any Microsoft Dynamics CRM data such as accounts, contacts, opportunities, sales orders, invoices, service cases and any custom entity data through MOSS.
  
• Launch a MOSS search which can return documents, emails, web content and Microsoft Dynamics CRM data.

A new web part for CRM 4 integration into SharePoint has been released by Microsoft:

Overview

The List Web Part for Microsoft Dynamics CRM 4.0 provides a way to view and update Microsoft Dynamics CRM records using a Windows SharePoint Services 3.0 SP1 or Microsoft Office SharePoint Server 2007 SP1 Web site. Microsoft Dynamics CRM users can create shared or personal List Web Parts of Microsoft Dynamics CRM records from a SharePoint Web site, open records in Microsoft Dynamics CRM 4.0 from the List Web Part, and create connected List Web Parts.

Ascentium has a blog post with some screen shots.

I was having a bit of a play around with CRM 4 and build an application definition file that provides the entities: Account, Contact and Product.

So you can use the BDC web parts to display the contacts in the account like:

You can download the Application Definition File here.