Sam Jones CRM Corner

Configure IIS Logging : Report Traffic within CRM

First posted by David Jennaway

Additional information by this author

 

A frequent request we come across is from companies who want to know which users are using CRM and when. The CRM platform provides the facility to gather detailed usage information by writing plug-ins, but a simpler and more general mechanism is to use the Internet Information Services (IIS) logging mechanism.

This article will explain how to derive useful usage metrics from the information provided by IIS logging. The main steps are:

1. Configure IIS logging to allow easy querying of the log data

2. Filter the raw log data to help identify usage patterns

3. Specify time periods to help categorize when people access CRM

4. Present the usage information in a graphical format through reports

Configure IIS logging

IIS logging allow the capture of information about every web request submitted to the server, and it is configured at the web site level. By default the log information is written to text files, but IIS can also write the information directly to a relational database, which allows easier analysis. For the purposes of this post, the simplest setup is to configure IIS 6.0 to write the log data to a SQL Server ODBC data source

 

1. Create a SQL Database. In this database, create a SQL table to hold the log data. IIS has a SQL script that will create the table with appropriate columns – this script will be in %windir%\system32\inetsrv\logtemp.sql

Download this file

Open the script within SQL Server Management Studio, swap to the correct database and execute the script

2. Create an ODBC data source on the IIS server with the connection details to the database in step 1. The data source must be a system DSN, and I’d recommend using Integrated authentication to SQL Server

 

3. In IIS Manager, open the Properties of the Microsoft Dynamics CRM web site. On the Web Site tab, select ODBC Logging in the Active log format dropdown, and set the associated properties to reflect the SQL table and ODBC DSN created in steps 1 and 2. If you specified Integrated authentication in the DSN, then the User name and Password will be ignored, though oddly, you cannot leave the password field blank

Filtering the log data

The IIS log will have a record for every request submitted to the web site. This includes requests for images, stylesheets and other supporting files, and can result in more data than you need . For instance, opening a CRM record can result in 30 records in the log table. There are also entries for CRM processes (such as the CRM Asynchronous Service) accessing the CRM platform.

This extraneous data can be filtered out with a SQL view. We use the following view definition:

CREATE view [dbo].[IISLogFiltered]
as
select ClientHost, username, LogTime, processingtime, bytesrecvd, bytessent, servicestatus, operation, target, parameters
from inetlog
where username not in ('-', 'CRMTEST\CRM4DEV$')
and parameters <> '-' and parameters not like 'lcid=%'

-- Replace CRMTEST\CRM4DEV$ with the account used by the CRM services

This assumes the SQL table has the default name (‘inetlog’), and filters out anonymous requests, and those from the CRM services. It also filters out requests with no query string parameters (or where the only parameter is ‘lcid’), which excludes the requests for the supporting files. You can explore the log data in more detail, and adjust the filters as appropriate.

Specifying time periods to categorize access

Even with the SQL view described above, you are still a step away from getting useful information about when users access CRM. The raw data stores the date and time of each request in one field, but it will help to process this into time and date periods. The approach we use is to build a SQL table that contains definable time periods , and a SQL function to match the log time to a time period. The SQL table can be created with the following script:

CREATE TABLE [dbo].[TimePeriod](
[PeriodText] [nvarchar](20) NULL,
[HourStart] [int] NULL,
[MinuteStart] [int] NULL,
[TotalMinuteStart] AS ((60)*[HourStart]+[MinuteStart]),
[TotalMinuteEnd] [int] NULL)

You should end up with something that looks like this :

You can then populate it with data for the time periods you want, for example:

This splits the day into hour-long periods between 8:00 and 18:00, with one period before and after the hour-long periods. The table can be used to find the PeriodText from a datetime field using a SQL function:

CREATE function GetTimePeriodText (@DateTime datetime) returns nvarchar(20)
as
begin
declare @tm int, @ret nvarchar(20)
set @tm = 60 * datepart(hh, @DateTime) + datepart(mi, @DateTime)
select @ret = max(PeriodText) from TimePeriod where @tm >= TotalMinuteStart and @tm < TotalMinuteEnd
return @ret
end

 

It will also help to extract the date component, this can be done using the SQL Convert function. The following SQL view applies these functions to the above SQL view used for filtering. It also extracts the CRM organization name from the target (url), and removes the domain part of the username.

Create view IISLogFilteredWithPeriods
as
select ClientHost, username, LogTime, processingtime, bytesrecvd, bytessent, servicestatus, operation, target, parameters
, dbo.GetTimePeriodText(LogTime) as TimePeriod
, convert(nchar(10), LogTime, 103) as DateText -- The last parameter defines the format
, convert(nchar(8), LogTime, 112) as DateYYYYMMDD -- Useful for sorting dates
, case when charindex('/', target, 2) > 2 then substring(target, 2, charindex('/', target, 2) - 2) else '' end as Organization -- Get organization name from target
, rtrim(substring(username, 1 + charindex('\', username), len(username) - 1 + charindex('\', username))) as usernameonly -- Remove Domain part of user name
from IISLogFiltered

Note that the IIS log will store data in Universal Time (UTC). You can modify either the data in the TmePeriod table, or the logic in the GetTimePeriodText function, to apply timezone information. Another, though officially unsupported approach, would be to use the fn_UTCToLocalTime SQL function in the MSCRM database.

The whole structure should look like this :

 

Creating reports on the log data

Now we’ve got the structure to process the log data, we can present in to users via a SQL Server Reporting Services report. The layout is up to you, but we find an effective way to present the information is in a matrix, with the time periods along the columns, with conditional formatting to highlight periods of light or heavy use. The following is an example, using the report definition below:

The numbers are the count of requests, with the background colours indicating how heavy the use is (as it’s a test system I’m considering 5 or more requests per hour to be heavy usage).

The SQL statement that produced this report is:

select usernameonly as username
, TimePeriod, DateText, DateYYYYMMDD
, sum(processingtime) as ProcessingTime, count(*) as Requests
from IISLogFilteredWithPeriods
where logtime > dateadd(d, -7, getdate())
group by usernameonly, TimePeriod, DateText, DateYYYYMMDD

 

You can download the complete report XML HERE

Further thoughts – more analysis

The report provided in this post is limited to displaying the number of request per user. Further ideas for analysis are:

• Using the processingtime data to get an idea of the processing on the IIS server. This is a measure of the elapsed time from starting processing the request in IIS, to submitting the end of the response, and will be affected by the load on the IIS server. This can be useful for identifying when and if requests take a long time to complete
• Identifying the types of entities accessed. The target can help identify which entity has been requested. This takes a bit of parsing, but the topic ‘URL Addressable Forms and Views’ (http://msdn.microsoft.com/en-gb/library/cc150850.aspx) in the CRM SDK will help
• IIS logs are not useful for identifying the type of data operation (e.g. create, update, delete, assign) has been performed. If you need this information, you would be advised to use a plugin/callout mechanism for the auditing – see http://blogs.msdn.com/crm/archive/2006/12/05/creating-solutions-a-custom-crm-usage-log.aspx for an example of this
• The techniques described in this post were developed for CRM 4, but also work on CRM 3. The only difference is that there is no need to extract the Organization name from the target on CRM 3

Productive JavaScript development in Microsoft Dynamics CRM 4.0

1)  Use an external JavaScript file while doing development.  It will save you a lot of time.  Regularly you make a code change and then you need to save and publish every time you want to retest.  Yes, the preview feature is helpful some of the time, but it is still very time consuming.   Using an external file will also allow you to leverage Visual Studio which offers IntelliSense and syntax checking.

Add this code to your onload.  It loads a JS file from within your ISV folder.   It uses a query string parameter to prevent caching and it waits until the dom is loaded before it executes the code.

var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.type= 'text/javascript';
script.src= '/ISV/Entity/accounttesting.js?noCache=' +  Math.random();
script.onreadystatechange= function () {
if (this.readyState == 'complete' || this.readyState == 'loaded')
{
document.OnLoadCode()
}
}
head.appendChild(script);

Second, you can add calls in your OnSave and OnChange events to call code in the JavaScript file.  This will allow you to do all development in the one file.
OnSave:  document.OnSaveCode();
OnChange of account name:  document.OnChangeCode_AccountName();

Third, add a file name accounttesting.js to your /ISV/Entity folder under the website folder.  It will contain the following code.
document.OnLoadCode = function()
{
   alert("OnLoad code");
}

document.OnSaveCode = function()
{
   alert("OnSave code");
}

document.OnChangeCode_AccountName = function()
{
    alert("OnChange of Account Code");
}

// other functions
Last, start testing.  Any time you make a code change to the file you can refresh the account screen (F5) and the newest code will be executed.  Instant results!!!

Disclaimer:  You should only use this for development.  After you have tested your changes using this method you should copy the code back into the OnLoad and comment out the code that loads the JavaScript file.  Keeping the file in your OnLoad will save you time and headaches in deployment.  Plus, this is not supported.

2)  Use the debugger statement in your code if you want to walk through code.  You are able to leverage Visual Studio to analyze variable values as you execute your code.  Very useful!

First, within Internet Explorer, uncheck “Disable script debugging  (Internet Explorer)” and “Disable script debugger (Other)”

Next, add following code before any code you would like to debug.

debugger;

3) Use a helper library for calling the CRM web service through AJAX.    Calling the CRM web service requires you to work with the XML request using string concatenation which is very error-prone.  The libraries provide an object-oriented API to return data from CRM.  They also provide better error handling to help you troubleshoot errors

You can use my helper objects Click Here.  Ascentium has one as well Click Here.  Their library uses fetchxml while mine uses RetrieveMultiple.

4) Use Intellisense to help prevent mistakes as you code.  The book CRM as a Rapid Development Platform comes with a excellent Intellisense generator for Visual Studio.  http://www.thecrmbook.com/Video/Customization/EnableCRMJavascriptIntellisense/viewvideo.aspx.  It is well worth the 50 dollar investment.

You point the generator application against your instance of CRM and it generates JavaScript files for you to reference in your JS file.  Now you have Intellisense.  No more copy and pasting the field name from the forms window to make sure you don’t mis-spell it.  No more bugs because you spelled the word crmForm as crmform.

5)  Follow the DRY principle.  Don’t repeat yourself.  If you need to hide a field both onload and when a specific dropdown is selected, don’t copy and paste the code around.  Add functions to OnLoad and call the function wherever you need to.  Also, as you find useful code, such as hiding and showing fields, create functions for them and re-use them from project to project.

6)  Use try catch statements where possible.  Depending on your browser setings, it may be hard to determine what error is actually being thrown, especially in OnLoad.  Catching the error message and displaying an alert will help save time while troubleshooting errors.

try
{ 
   // Implementation here
}
catch (er)
{
alert(er.message);
}

 

First posted by Andrew Zimmer of Inetium

How to detect a duplicate entry in Microsoft CRM 3.0

Introduction

CRM systems are great but they are very prone to human error, the ease of data entry is sometimes counterproductive especially if you want to keep your data clean.

Using the code

In this code I used JavaScript for posting data to my detection script and C# for the .ASPX page.

Essentially all I needed to do was test against a single field.
On the change event of an input field in the Account entity I sent some data to a web service using JavaScript and returned a response.
If the response indicated that an account already exists than I gave the user the option to open the existing account's form.

The C# Code:
Essentially, I have the Fetch xml that will be sent to CRM 3.0 via the API.
In this particular case I needed to test the accountnumber field for duplicates.
I pass the account number to my script via a form post (will be shown later), that is why i am testing for the Request["AccountNumber"].
After building the xml the script sends the request to CRM and retrieves the response.
Load the xml into a System.Xml.Xm lDocument object and test to see if the number of rows returned is more than zero.
If it is more than zero, for my purposes the script returns the accountid.

 

 crmService.CrmService crm;
  // Put user code to initialize the page here
  crm = new CrmService();
  crm.Credentials = System.Net.CredentialCache.DefaultCredentials;
  string fetchxml = "<fetch mapping='logical'>";
  fetchxml+= "<entity name='account'>";
  fetchxml+="<all-attributes/>"; 
  fetchxml+="<filter type='and'>";
  fetchxml+=    "<condition attribute='accountnumber' operator='eq' value='{0}'/>";
  fetchxml+=    "</filter>";
  fetchxml+=    "</entity>";
  fetchxml+="</fetch>";
 if(Request["AccountNumber"]!="")
  {
  fetchxml = string.Format(fetchxml,Request["AccountNumber"]);
  string xmlResponse = crm.Fetch(fetchxml);
  System.Xml.XmlDocument xdoc = new System.Xml.XmlDocument();
  xdoc.LoadXml(xmlResponse);
 if(xdoc.SelectNodes("resultset/result").Count>0)
  {
     Response.Write(xdoc.SelectNodes("resultset/result")[0]["accountid"].InnerText);
  }else
  {
     Response.Write("0");
  }
 }else
  {
    Response.Write("0");
  }
 

The JavaScript:

This portion can be used in either the OnSave event for any entity or the OnChange event for any field.

I don't need to worry about browser incompatibility when developing for Microsoft CRM 3.0, because the platform was built to be used in IE6+.

I create the URL along with the data of the field i want to test against, and use the Microsoft.XMLHTTP ActiveX object to post it to your script.

If you take a look at the C# code for the script, it returns "0" if nothing is found and the acount id otherwise.

At this point i ask the user if they would like to be redirected to the existing account.

 

var url = "http://localhost/CheckDuplicateAccounts/CheckDuplicateAccount.aspx?AccountNumber=" 
+ crmForm.all.accountnumber.DataValue;
var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("POST", url, false);
xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");
xmlhttp.send("");
var result = xmlhttp.responseText;
if(result != "0")
{
  if(confirm("This account number already exists in the system, would you like to open the 
EXISTING account?"))
  {
    document.location = "http://"+document.domain+":5555/sfa/accts/edit.aspx?id=" + result;
  }
}

How To : Making a field Business Required with Javascript

A recent client of mine had a number of very complex requirements within a new CRM implementation. One of these was that certain fields became 'Business Required' based on a certain set of criteria. I really wanted this to be a client side fix so I began investigations. Here is what I discovered :

Make the field 'Business Required'

My code was placed in the onLoad event of the form, but you could just as easily use the 'OnChange' event of an attribute instead.

SetFieldRequiredOrRecommended(crmForm.all.parentcustomerid_c,FORM_FIELD_TYPE_REQUIRED,

LOCID_FORM_REQUIRED_ALT);

crmForm.all.parentcustomerid.req = 2;

Make the field 'No Requirement'

SetFieldRequiredOrRecommended(crmForm.all.parentcustomerid_c,FORM_FIELD_TYPE_NORMAL,"");

crmForm.all.parentcustomerid.req = 0;

Make the field 'Business Recommended'

SetFieldRequiredOrRecommended(crmForm.all.customertypecode_c,

FORM_FIELD_TYPE_RECOMMENDED,"");

crmForm.all.customertypecode.req = 1;

Where did that function come from?

The function 'SetFieldRequireOrRecommended' is actually found in the Global.js file within CRM. You can find this file in (typically) C:\Program Files\Microsoft Dynamics CRM\CRMWeb\_static\_common\scripts

 

Practical Uses…

if (crmForm.all.customertypecode.DataValue == 3) {
  crmForm.SetFieldReqLevel("accountnumber", 1);
}
else {
  crmForm.SetFieldReqLevel("accountnumber", 0);
}

Other Useful Functions : CopyTextToClipboard

You can use any of the functions within Global.js. For instance, onChange of a particular attribute, I would like to copy the value of another to the clipboard for use with 'Ctrl-V'. Add the following to the OnChange event of your chosen attribute....

var sMessage = "Success!";


var sFailMessage = "Failure - boo!";

CopyTextToClipboard(crmForm.all.telephone1.DataValue, sMessage, sFailMessage);

ISV Utilities for Comparing Customizations and Transferring Configuration Data

Summary

Learn how to build and use two new powerful tools developed for Microsoft Dynamics CRM. The Customization Comparison Utility lets you compare the customization files between two Microsoft Dynamics CRM systems and the Configuration Data Utility lets you transfer custom configuration data from one Microsoft Dynamics CRM system to another.

Download the Visual Studio 2008 and Visual C# code samples for this article:

• CustomizationComparisonUtility.exe
• ConfigurationDataUtility.exe

The Readme.doc documents that are included with the sample code contain information about how to set up and build the sample applications. The user guides contain detailed information about how to use the sample applications and view the results.

Applies To

Microsoft Dynamics CRM 4.0

Microsoft Visual Studio 2008

Introduction

Microsoft Dynamics CRM is a highly customizable system. Not only you can modify different sections of the product, you can also create new components to address business needs. The Microsoft Dynamics CRM platform offers a robust set of tools, APIs, and documentation that helps you build custom business applications. As the applications built on the Microsoft Dynamics CRM platform become more and more complex, a need for specialized support tools grows. In this article you will learn about two very useful tools that help you analyze the impact of customizations on the system and maintain consistent configuration data across multiple Microsoft Dynamics CRM systems.

Evaluating the Impact of Customizations with the Customization Comparison Utility

To evaluate the impact of customizations, it is helpful to compare customization files between the source and the target systems before you import customizations. The Customization Comparison Utility helps you accomplish this task.

Analyzing Customizations

Often you have to export custom components from one Microsoft Dynamics CRM environment and import them into another, for example, from development into test or production. However, before you import customizations, it is very helpful to assess the impact of customizations on the target system. The system where you import customizations may have been changed since the last installation. You have to consider the extent of the changes and how they may affect the new installation. While some of the changes, such as renaming of the attributes or adding new attributes, are minor, other modifications, such as deletion of entities or changes in the forms may have a significant effect on the system.

Analyzing and understanding the system customizations may result in more successful deployment of a new version of the application. This analysis minimizes the risk of overwriting important customization data in the target system. For example, if only several attribute names have changed, you may be able to do a plain import using the import/export functionality built into Microsoft Dynamics CRM. However, if some key components were deleted, such as entity forms, you may have to merge the customizations with the changes in the target system. Comparing customization files between the two systems helps you determine which approach will result in more successful deployment. This is also very useful when you are diagnosing the problems between two systems. By comparing the customization files, you can often identify possible causes of the existing problems.

Using the Customization Comparison Utility

The Customization Comparison utility lets you easily compare two Microsoft Dynamics CRM customization.xml files. Unlike other XML comparison tools, this utility can read and understand Microsoft Dynamics CRM schema. The results of comparison show the differences in entities, attributes, forms, views, workflows, security roles, entity maps, and relationships. You can use this tool before you import customizations into a system to evaluate the effect they will have on the system.

Use the tool to compare XML customizations files between the source and the target systems. If you use a zipped customization file, make sure that it contains only one customization XML file. The following illustration shows the results of comparison between two customization files. The compared items include entities, roles, workflows, entity maps, and relationships. You can drill down into each item to see more details. From the entities, you can view the changes in attributes, forms, and system views. You can easily see the changes in source and target. It shows the items that are present in the source file and not present in the target file and the items that are present in the target file, but not in the source file.

In addition to reviewing the results of the comparison in the grid, the tool includes a report that you can easily export to Microsoft Office Excel for additional analysis.

The tool offers a command line version that you can run from a command prompt.

For more information about how to use the tool, see the Customization Comparison user's guide included in the download package for this utility.

Transferring Configuration Data with the Configuration Data Utility

When you work with multiple environments, such as development, test, and production, or multiple Microsoft Dynamics CRM organizations, keeping consistent configuration data across all systems can be very important. The Configuration Data Utility helps you achieve this. It lets you export custom configuration data from a source Microsoft Dynamics CRM system and import it to a target Microsoft Dynamics CRM system.

Storing Configuration Data in Custom Entities

In Microsoft Dynamics CRM you often use custom entities to store business information. However, you could also use custom entities to store system configuration data. For example, if an application integrates Microsoft Dynamics CRM with a third-party system, you could create a configuration entity with attributes such as pollingtime, url, and retries to store the configuration data needed for the integration. This is very convenient because the data stored in the configuration entity can be used by the system administrators to configure a new application or update an existing application. To keep the configuration data up to date, you may have to frequently upload the new data, or have an automated task to do it.

Using the Configuration Data Utility gives you a simple and efficient way to transfer custom configuration data from one system to another. One of the main benefits of this utility is that you can import configuration data from multiple custom entities at the same time. While it only imports and exports data for custom entities, the tool can handle useful scenarios, such as importing records that reference other records that are also being imported.

Important

For the tool to work correctly, the schema for the source entities and the target entities must be identical.

Note

In more complex cases, use the Microsoft Dynamics CRM data export and import tools or Data Migration Manager to transfer data for custom and system entities.
For more information about these tools, see Microsoft Dynamics CRM online Help.

Using the Configuration Data Utility

Use the Configuration Data Utility to export the source system configuration data and import it into a target system. The tool provides a convenient interface that lets you select the custom entities that contain the configuration data in the source system, save the data into a data file, and then import the records from the data file into a target system.

To run the tool, you must be a system administrator with appropriate privileges to create, read, and update entity instances.

The following illustration shows the entities in the source system that are selected for export.

For import, specify the target server where you import the configuration data and the data file that you created during export, as shown in following illustrations.

For more information about how to use the tool, see the Configuration Data Utility user's guide included in the download package for this utility.

Differences between Workflow and Plugins in CRM 4.0

Original Post by David Jennaway (MVP Excitation Ltd) - Reproduced here for reference.

---

A common question I get is ‘what is the difference between workflow and plugins, and when should I use one or the other ?’. This article is intended to be a comprehensive answer to these 2 questions.
First of all, I want to clarify the distinction between what I consider 3 distinct categories of workflow – the terminology is my own:

• Simple workflow. This is one or more workflow rules created within the MSCRM interface, and which do not include custom workflow activities.
• Workflow with custom workflow activities. I’ll explain more about custom workflow activities later in this article; for now the key point is that a custom workflow activity is .Net code that is written to perform functions not possible in simple workflow, and this code can be called from a workflow rule
• Workflows created with the Workflow Designer in Windows Workflow Foundation. It is possible to build workflows outside of the CRM user interface, but I’m not going to include them in this article.

Simple workflows
The main characteristics of simple workflows are:

• * Creating a simple workflow involves no code
• Workflows run only on the CRM server – workflow processing is not available within a client that is offline
• Workflows run asynchronously – any data changes made within a workflow rule will not show up immediately within the CRM user interface
• Workflows can be run manually or automatically. The automatic running of workflows is based on several data modification events
• Workflow rules are entity specific
• The state and stage of a workflow instance can be viewed within the CRM user interface by any CRM user with appropriate permissions

Some limitations of workflows are:

• Workflow rules cannot be created for all entities
• Although workflow rules can be triggered by the most common data modification events, there are some events that don’t trigger workflow rules
• * Simple workflows offering limited capability to perform calculations

Characteristics and limitations marked with an asterix (*) do not apply if using custom workflow activities; the others do still apply.

Custom workflow activities
Custom workflow activities allow you to extend the capabilities of workflow rules. Three common uses are to perform calculations on CRM data, to access CRM functionality that is not available in the out-of-the-box workflow activities, and to access external data.
Custom workflow activities are written as .Net assemblies which have to be registered on the CRM server. These assemblies can include information about parameters that can be passed into or out of the activity.

Plugins
A plugin is .Net code that is registered on the CRM server. A plugin assembly can be registered for one or more steps – these steps correspond to the combination of the message (event), entity and stage. An example of a step would be the Create message for the account entity on the pre-event stage. Registration of the assembly and steps is part of the plugin deployment process, and there is no direct user interaction with plugins
The main characteristics of plugins are:

• They have to be written as .Net code
• Although they typically run on the CRM server, they can be deployed and configured to run on a CRM client that is offline
• They can run either synchronously or asynchronously. If they run synchronously, any data changes made within the plugin will show up immediately within the CRM user interface
• Synchronous plugins can run on either the pre-event or post-event stage. The pre-event stage happens before data is written to the CRM database, and a plugin registered on a pre-event step can cancel the data writing and provide an error message to the user.
• More entities can have plugins registered for them than can have workflow rules
• Plugins can run on more events than can workflow rules. An example is that plugins can run on data retrieval, not just modification events

The main limitations of plugins are:

• Plugins cannot be run manually; they only run on the steps for which they are registered
• There is no user interaction with plugins, other than error messages that might be throw by a synchronous plugin

Sample Scenarios
So, having covered the main characteristics and limitations of simple workflows, custom workflow activities and plugins, when should you choose one or another ? Here are some common scenarios:
What you want to achieve can be done with a simple workflow, and it is acceptable or desirable for this to happen asynchronously and on the server only
In this case I’d go with simple workflows; there’s no point writing code if you don’t have to.
What you want to achieve has to run synchronously
If so, workflow won’t do, so it would have to be a plugin. An alternative could be to use client script, but I don’t intend to complicate this article by including this in any more detail
You need to be able to cancel the data operation
A pre-event plugin is the only option covered here, though again client script should be considered
You want to give users the discretion to run the operation manually
Here you’ll need a workflow. Whether or not you need a custom workflow activity depends on the complexity of the operations. Again, there may be an option outside of the scope of this article – to write an ASP .Net application that is called from an ISV Config button
You need to write custom code, but you want users to decide whether this code should run, and under what circumstances
In this case I’d go with a custom workflow activity, as you could make this available for users to add to their own workflows

Further Information
There is more detail about how to write and deploy plugins and custom workflow assemblies within the CRM 4.0 SDK, though unfortunately there’s not a lot of information about when to choose one or the other.
The classroom training material ‘Extending Microsoft Dynamics CRM 4.0’, course number 8969, should have more information both about building plugins and custom workflow assemblies, and when to use them. This course will also cover other solution technologies such as client script and ASP .Net extensions.

One of the MS team, Humberto Lezama has also produced a useful matrix indicating the relative merits of workflow and plugins. This can be found here

How to hide buttons on CRM Forms

One of the most common operations we do is to hide certain buttons within the CRM using DHTML. This ought to have been relatively easy and using CRM3 it was. You simply used the following :

document.getElementById('[yourcontrolnamehere]').style.display = "none";

Unfortunately, things have changed in CRM 4 and not for the better. In CRM 4.0 there is some auto-incremented number or randomly generated number that gets placed at the end of all of the ElementId's on a page. Which means that the code used for CRM 3.0 will break.

Recently, due to some operational reasons, my client wanted to disable the 'Convert Campaign Response' button on the Campaign Response Form.

So, there are a number of ways this can be achieved. First of all, we need to know the actual name of the control we are about to hide. I find that the IE Developer ToolBar is one of the very best methods of achieving this. You can download the tool bar from HERE . When you have downloaded and installed the toolbar, you will be able to use it to find the actual name of the control inside CRM.

1) Navigate to the form you wish to check

2) Press F11 and then the Toolbar Icon

 

3) Click 'Find' and then 'Select Element By Click'

4) Select the button that you want to hide.

This handy little tool gives you the names of all elements on the page and now, all you have to do is hide them. There are a number of solutions out there.

Solution Number One

var Hide = function(menuItem){

if (document.getElementById(menuItem) != null)

{

document.getElementById(menuItem).style.display = "none";

}

}

var RemoveSpacerAfter = function(menuItem){

if (document.getElementById(menuItem) != null)

{

var item = document.getElementById(menuItem);

if (item.nextSibling != null)

item.nextSibling.style.display="none";

}

}

Hide('_MBConvertResponse');

RemoveSpacerAfter('_MBConvertResponse');

 

Solution Number Two

//Get all of the List Elements

var lis = document.getElementsByTagName('LI');

var i = 0;

//Loop through the list items

while (i < lis.length) {

//Don't worry about any list item that doesn't have the title you are looking for.

if (lis[i].getAttribute('title') == 'View directions to this account.')

{

//Replace the DHTML with blank tags to hide the button

lis[i].outerHTML='<SPAN></SPAN>'

}

i = i + 1;

}

You can also delete menu options from the Actions menu on any entity. Here's the same code again but removing the 'Delete  Case' menu item from the Actions Menu

//Get all of the List Elements

var lis = document.getElementsByTagName('LI'); 

var i = 0;

//Loop through the list items

while (i < lis.length) 

{ 

//Don't worry about any list item that doesn't have the title you are looking for.

if (lis[i].getAttribute('id') == '_MIonActionMenuClickdelete112')

{ 

//Replace the DHTML with blank tags to hide the button

lis[i].outerHTML='<SPAN></SPAN>'

}

i = i + 1;

}

 

 Item Names

Item names are also fairly easy to figure out. You can view them by opening the relevant form, pressing Ctrl-N and then 'View', Source. Here are some basic ones that are much the same for all entities.

Actions Menu

Add Activity = _MIlocAddActTo4401

Add a Note = _MIlocAddObjTo5

Attach a file = _MIlocAddFileTo5

Delete Account = _MIonActionMenuClickdelete1 (Entity: Contact would be 2)

Mail Merge = _MIonActionMenuClickwebmailmerge1 (Entity:Contact would be 2)

Sharing = _MIonActionMenuClickshare1

 

General Buttons

Jewel Button = ms-crm-Menu-JewelButton

Save = _MBcrmFormSave

Save & Close = _MBcrmFormSaveAndClose

Print = _MBcrmFormPrint

 

A word of explanation for the Delete menu item. The number at the end of the id is in fact the ObjectTypeCode for the entity. So, the name of the delete button for the Accounts entity has the number 1 appended, contacts has the number 2 and so on. Once you have the hang of the naming conventions, it is pretty easy to guess what any given button or menu item is likely to be called. Once you have this information, you can view the source, search for the value and then confirm the correct information prior to applying the javascript.

Using the DOM in Microsoft CRM 4.0

One of the beauties of CRM is the ability to use client side code, in particular, I am fond of attachEvent(). Here is a brief demonstration of how to change the colours of a field within crmForm using the DOM and attachEvent(). It should be noted that this particular little gem is from the department of 'Unsupported but fun to do anyway'.

Attach this to the Onload event of the Account Form (or any form you like, just change the references)...

function CompanyName_GlowField()
{
/* The Event's SrcElement will be the element that fired
the event in this case, it will be the Microsoft Dynamics
CRM form element */
event.srcElement.runtimeStyle.backgroundColor ="#ffdddd";
}
function CompanyName_RevertField()
{
/* Runtimestyle will automatically revert the style back to
what it was prior to our code changing it. */
event.srcElement.runtimeStyle.backgroundColor ="";
}
/* Hook up events to the Account Name field */
crmForm.all.name.attachEvent("onmouseover",
CompanyName_GlowField);
crmForm.all.name.attachEvent("onmouseout",
CompanyName_RevertField);

 

As you can see, this is quite a powerful little feature. You can add custom logic to this function to further enhance the effect, perhaps changing colours depending on the value, a range of values or a particular dependency.

Have fun.

Microsoft Dynamics CRM Plug-in Template for Visual Studio

Peter Hecke has created a Dynamics Plugin template for Visual Studio. This is extremely helpful not just for experienced developers but also for people just starting out with CRM plugin development as the SDK can be a little coy in places regarding the HOW of actually implementing something. You can read Peter's original post HERE

 

Thanks Peter!

Accelerators for Microsoft Dynamics CRM

The first of the long awaited Accelerators are here. In a nutshell, they are add-on modules that delivery extended capability to Microsoft Dynamics CRM 4.0.

The Microsoft Team have also released a series of blog posts on these components and they are really well worth the read. You can find them HERE.

Today the first two accelerators were released; CRM Notifications (Newsfeeds (RSS) that allow users to subscribe to CRM “events” relevant to their job role) and Extended Sales Forecasting (Enhanced sales forecasting mechanism for Microsoft Dynamics CRM 4.0). These can be downloaded through PartnerSource.

 

PartnerSource:  https://mbs.microsoft.com/partnersource/newsevents/news/MD_CRM_Accelerators.htm

Personally, I have been given the task of investigating the Extended Sales Forecasting component so I will be posting my observations shortly.