August 15, 2007 by akezyt.

Last week I posted another article on MSDN. Code sample is available at GotDotNet. Last time I checked it got around 650 download so far.

Introduction

Microsoft CRM 3.0 shipped with an extensive web service API that can be used by various types of applications. Here is a sample Windows sidebar gadget (or just gadget) that retrieves queue items related to the currently logged in user every predefined interval. Since the gadget is always available on the desktop but small in size, the ideal information to display on gadget should be something dynamic and concise. In Microsoft CRM context, the queue item entity fits squarely as it is changed quite frequently and requires immediate attention from a user.

The code is provided at http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=A6791FE6-5A4C-4432-8FBD-BBD8A499120B

Figure 1 “In progress” queue items

Figure 2 “Assigned” queue items

Figure 3 Settings window

Developing CRM Gadget

For more information about developing gadget in general, please refer to MSDN article in the resource section. This article will focus more on CRM specific aspects.

Retrieving data from CRM

Gadgets are composed of HTML and Jscript. We can use XmlHttp from JScript to send hand crafted SOAP message to the CRM server. Then we use an Msxml2.DOMDocument to parse the response to get the result. We need not do it asynchronously as the user is not blocked by the gadget anyway and it will be much more complicated to do it asynchronously.

In keeping with best practices, this sample retrieves only columns that are needed to reduce server load.

Reading and writing settings through the gadget infrastructure

The gadget infrastructure provides a nice API for reading and writing settings. Be careful about storing sensitive information though. In this case, we just store the CRM server name, polling interval, and queue type so we are okay.

For reading settings

var currentServerName = System.Gadget.Settings.readString(”crmServerName”);

For writing settings

var temp = serverName.value;

System.Gadget.Settings.writeString(”crmServerName”, temp);

Securing gadget

Gadgets also subject to all sorts of cross site scripting vulnerabilities, since they are also web applications. All user input should be validated before using it. All external data (including data from the CRM server) must be properly encoded before rendering.

Using standard style sheet

This sample utilizes template.css to make the gadget look consistent with the CRM web application. For example the server name label is shown as a required field. This template.css file is shipped with CRM SDK. You can download it from Microsoft.com.

Deploying gadget

Because this gadget is a real application though it looks cute; there will be a time that you will want to patch it after you ship. The best way to enable gadget patching is to deploy it with MSI. However, for simplicity of our sample, I just use the zip approach. All you need to do is zip all HTML, JScripts, CSS, and the manifest (gadget.xml) together and change the resulting file’s extension from .zip to .gadget. Then the user can install it by double clicking.

Resources

- MSDN Windows Sidebar Gadget Development Overview (http://msdn2.microsoft.com/en-us/library/aa965850.aspx)

- System.Gadget.Settings in MSDN (http://msdn2.microsoft.com/en-us/library/ms723661.aspx)

- Other CRM Windows sidebar gadgets

• http://www.codeproject.com/gadgets/DynamicsCRMGadget.asp
• http://blogs.msdn.com/joris_kalz/pages/Vista-Microsoft-CRM-Search-Gadget.aspx

- CRM SDK (http://www.microsoft.com/downloads/details.aspx?familyid=9C178B68-3A06-4898-BC83-BD14B74308C5&displaylang=en).

Posted in CRM | No Comments »

February 24, 2007 by akezyt.

Cross posted from MSDN blog. I wrote this article last week and it was published this week.

Another View of CRM Data

[Code examples are on the CRM Sandbox in the downloads section.] MS Dynamics CRM shipped with grid view and form view for displaying data such as account or contact information. However, that does not mean it is the only way to present CRM data. This article will show a way to represent CRM accounts on a map.

Populating account’s coordinate. Before we can show the account on the map, we first need to populate account’s location into CRM. Most account/contact already contains shipping or billing address. However, they are not in the format that is easy to map or locate. Out of the box, account already contains ‘latitude’ and ‘longitude’ attributes that we can use but they are not automatically populated by CRM. So we need to convert the human readable street address into latitude and longitude coordinate. This process is called geocoding. For existing CRM deployment where accounts and contacts are created without latitude and longitude, we need to mass-populate them using web service information in the CRM SDK. The are several providers that offer geocoding service such as:

• MapPoint
• Yahoo Map

In this example, we use the MapPoint web service. It is free of charge but you need to register for developer account before you can use it. There are some restrictions on developer account so double check before using it on commercial system. For new account that will be created after this initial mass-populating, we could incrementally populate latitude/longitude for them using JavaScript on form’s OnSave event or using server side callout. Sometimes, it might be easier to geocode each account’s address on the fly and plot them on the map every time. However, doing so would cause serious performance and unnecessary load time. Moreover, after getting location data into CRM, we can do something interesting such as optimizing delivery/service truck route based on sales order’s account/contact address. Displaying Account on the Map In this sample, we will just show each account on map using Virtual Earth map control (http://dev.live.com/virtualearth/sdk). It is quite easy to use after we get account’s latitude and longitude. Another interesting part is how do we query actual accounts from saved query. The steps are like this:

- Retrieve the actual fetch XML on savedquery entity. - Convert that fetch XML into QueryExpression object using FetchXmlToQueryExpressionRequest. - Use the QueryExpression to retrieve list of accounts.

For better performance, we can also cache the QueryExpression so we don’t have to look it up every time and save 2 web service calls but we are not doing it for simplicity. JavaScript then use XmlHttpRequest to send request XML to our QueryService and gets back XML. I manually created request XML and parsed response XML. However, you can use ASP.Net AJAX to create JavaScript proxy and save some more time. Showing account in map view is just one of another way to use CRM data. We hope to publish some more examples in the near future. But for now, we trust this example will provide some interesting concepts and ideas to consider for your implementation of CRM.

Posted in CRM | No Comments »