Customising the Activity Views (and other such views) via Plugins

RetrieveMultiplePluginfeatureThe Requirement

I had a requirement to display a list of activities, both open and closed on the dashboard. Simple enough I hear you say. Well, it was until I needed to include a few more fields to make the user experience better. I wanted to categorise the activities, so as well as showing the type of activity (email,phone,letter,task), I wanted to give them a short description that would make a lengthy list of activities easily readable.

The Idea

Upon looking at the activities, such as email and phone call, I noticed they had a system default field called category, of which it was a single line of text. As it was present on all of the activities, I thought I would just use it. After much time spent updating my workflows to populate these category fields with the appropriate tags, I was ready to update the view.

The Problem

Bugger, it was then that I realised that the category field was unique to each activity, and not stored on the activity pointer (the entity that you would normally use to list all types of activities in one view). The activity pointer had the subject and description fields that are shared across other activities (plus a few more), but not the category field. And to top it off, the activity pointer entity is not customisable. So, at that point I started to think about using workflows or JavaScript to just simply prepend the tags I wanted to use to the beginning of the subject line, but it soon became apparent that it was not going to be suitable as there would be too much involved with making sure manual updates to activities didn’t spoil my tagging.

I began the “google”.

The Solution

Eventually, I happened upon a possible solution using plugins. Initially I was thinking of using a create or update plugin to change the subject field. Got too confusing, but, there was light at the end of the tunnel. I began experimenting with a plugin for the RetrieveMultiple command. This is what provides data for views within Dynamics, and even the activity pointer entity can have a RetrieveMultiple plugin to intercept the data it is about to send back to the web browser allowing you to tinker with the data returned.

To begin with, using the CRM Developer Toolkit for Visual Studio 2012, I browsed to the Activity Entity in the CRM Explorer window, right clicked and selected Create Plugin. Below are the selections I made to set up the plugin.

RetrieveMultiplePlugin

After that, I just added the code (at the bottom of this post) to intercept the returned EntityCollection’s subject field, and alter it in such a way so that it has the activities category and direction fields within.

The below line gets the EntityCollection that is about to be returned to the clients Grid View from the plugins OutputParameters collection.

EntityCollection entityCollection = (EntityCollection)localContext.PluginExecutionContext.OutputParameters["BusinessEntityCollection"];

I then loop through every entity, find the category from the appropriate activity entity (the activitypointer id is the same id that is stored within the email entity for example), and then modify the activitypointer’s subject attribute to include the category.

It really is that simple.

Interesting, this could be used in all kind of situations where you need to alter the displayed views (perhaps hiding fields based on security roles, or encrypting/decrypting passwords for viewing etc). One of the key uses though may be to retrieve data from other entities to include in a view that may not be possible by just using fetchxml.

Below is the Execute code to include in the plugin to achieve what I have described.

 protected void ExecutePostActivityRetrieveMultiple(LocalPluginContext localContext)
        {
            if (localContext == null)
            {
                throw new ArgumentNullException("localContext");
            }
            if (localContext.PluginExecutionContext.OutputParameters.Contains("BusinessEntityCollection"))
            {
                EntityCollection entityCollection = 
                    (EntityCollection)localContext.PluginExecutionContext.OutputParameters["BusinessEntityCollection"];
                if (true)       // This could be some form of user role check
                {
                    if (entityCollection.Entities.Count > 0)
                    {
                        Entity ActivityEntity = null;
                        foreach (Entity entity in entityCollection.Entities)
                        {
                            if (entity.Contains("activitytypecode"))
                            {
                                string type = entity.Attributes["activitytypecode"].ToString();
                                if (type != "")
                                {
                                    // These Activities have a direction field to indicate outgoing or incoming
                                    if (type == "email" || type == "letter" || type == "phonecall") 
                                        
                                        ActivityEntity = localContext.OrganizationService.Retrieve(
                                            type, entity.Id, new ColumnSet("category", "directioncode"));
                                    else
                                        ActivityEntity = localContext.OrganizationService.Retrieve(
                                            type, entity.Id, new ColumnSet("category"));
                                    if (ActivityEntity.Attributes.Contains("category"))
                                    {
                                        if (ActivityEntity.Attributes.Contains("directioncode"))
                                        {
                                            entity.Attributes["subject"] = 
                                                ActivityEntity.Attributes["category"].ToString().PadRight(30) + " - " +
                                                ((bool)ActivityEntity.Attributes["directioncode"] ? "Outgoing" : "Incoming")
                                                + " - " + entity.Attributes["subject"];
                                        }
                                        else
                                        {
                                            entity.Attributes["subject"] = 
                                                ActivityEntity.Attributes["category"].ToString().PadRight(30) + " - " + 
                                                entity.Attributes["subject"];
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }

Object Type Codes Cheat Sheet for Dynamics CRM 2011

Sometimes when developing, you need the entity object type code (of which there are quite a few).  Below is a quick list of them for reference.

 

1 Account
2 Contact
3 Opportunity
4 Lead
5 Annotation
6 BusinessUnitMap
7 Owner
8 SystemUser
9 Team
10 BusinessUnit
11 PrincipalObjectAccess
12 RolePrivileges
13 SystemUserLicenses
14 SystemUserPrincipals
15 SystemUserRoles
16 AccountLeads
17 ContactInvoices
18 ContactQuotes
19 ContactOrders
20 ServiceContractContacts
21 ProductSalesLiterature
22 ContactLeads
23 TeamMembership
24 LeadCompetitors
25 OpportunityCompetitors
26 CompetitorSalesLiterature
27 LeadProduct
28 RoleTemplatePrivileges
29 Subscription
30 FilterTemplate
31 PrivilegeObjectTypeCodes
32 SalesProcessInstance
33 SubscriptionSyncInfo
35 SubscriptionTrackingDeletedObject
36 ClientUpdate
37 SubscriptionManuallyTrackedObject
40 TeamRoles
41 PrincipalEntityMap
42 SystemUserBusinessUnitEntityMap
43 PrincipalAttributeAccessMap
44 PrincipalObjectAttributeAccess
112 Incident
123 Competitor
126 DocumentIndex
127 KbArticle
129 Subject
132 BusinessUnitNewsArticle
135 ActivityParty
150 UserSettings
1001 ActivityAttachment
1002 Attachment
1003 InternalAddress
1004 CompetitorAddress
1006 CompetitorProduct
1010 Contract
1011 ContractDetail
1013 Discount
1016 KbArticleTemplate
1017 LeadAddress
1019 Organization
1021 OrganizationUI
1022 PriceLevel
1023 Privilege
1024 Product
1025 ProductAssociation
1026 ProductPriceLevel
1028 ProductSubstitute
1030 SystemForm
1031 UserForm
1036 Role
1037 RoleTemplate
1038 SalesLiterature
1039 SavedQuery
1043 StringMap
1055 UoM
1056 UoMSchedule
1070 SalesLiteratureItem
1071 CustomerAddress
1072 SubscriptionClients
1075 StatusMap
1080 DiscountType
1082 KbArticleComment
1083 OpportunityProduct
1084 Quote
1085 QuoteDetail
1086 UserFiscalCalendar
1088 SalesOrder
1089 SalesOrderDetail
1090 Invoice
1091 InvoiceDetail
1111 SavedQueryVisualization
1112 UserQueryVisualization
1113 RibbonTabToCommandMap
1115 RibbonContextGroup
1116 RibbonCommand
1117 RibbonRule
1120 RibbonCustomization
1130 RibbonDiff
1140 ReplicationBacklog
1200 FieldSecurityProfile
1201 FieldPermission
1202 SystemUserProfiles
1203 TeamProfiles
2000 UserFiscalCalendar
2001 UserFiscalCalendar
2002 UserFiscalCalendar
2003 UserFiscalCalendar
2004 UserFiscalCalendar
2010 Template
2011 ContractTemplate
2012 UnresolvedAddress
2013 Territory
2020 Queue
2027 License
2029 QueueItem
2500 UserEntityUISettings
2501 UserEntityInstanceData
3000 IntegrationStatus
3231 ConnectionRole
3232 ConnectionRoleAssociation
3233 ConnectionRoleObjectTypeCode
3234 Connection
4000 Equipment
4001 Service
4002 Resource
4003 Calendar
4004 CalendarRule
4005 ResourceGroup
4006 ResourceSpec
4007 ConstraintBasedGroup
4009 Site
4010 ResourceGroupExpansion
4011 InterProcessLock
4023 EmailHash
4101 DisplayStringMap
4102 DisplayString
4110 Notification
4200 ActivityPointer
4201 Appointment
4202 Email
4204 Fax
4206 IncidentResolution
4207 Letter
4208 OpportunityClose
4209 OrderClose
4210 PhoneCall
4211 QuoteClose
4212 Task
4214 ServiceAppointment
4215 Commitment
4230 UserQuery
4250 RecurrenceRule
4251 RecurringAppointmentMaster
4299 EmailSearch
4300 List
4301 ListMember
4400 Campaign
4401 CampaignResponse
4402 CampaignActivity
4403 CampaignItem
4404 CampaignActivityItem
4405 BulkOperationLog
4406 BulkOperation
4410 Import
4411 ImportMap
4412 ImportFile
4413 ImportData
4414 DuplicateRule
4415 DuplicateRecord
4416 DuplicateRuleCondition
4417 ColumnMapping
4418 PickListMapping
4419 LookUpMapping
4420 OwnerMapping
4423 ImportLog
4424 BulkDeleteOperation
4425 BulkDeleteFailure
4426 TransformationMapping
4427 TransformationParameterMapping
4428 ImportEntityMapping
4500 RelationshipRole
4501 RelationshipRoleMap
4502 CustomerRelationship
4503 CustomerOpportunityRole
4567 Audit
4600 EntityMap
4601 AttributeMap
4602 PluginType
4603 PluginTypeStatistic
4605 PluginAssembly
4606 SdkMessage
4607 SdkMessageFilter
4608 SdkMessageProcessingStep
4609 SdkMessageRequest
4610 SdkMessageResponse
4611 SdkMessageResponseField
4613 SdkMessagePair
4614 SdkMessageRequestField
4615 SdkMessageProcessingStepImage
4616 SdkMessageProcessingStepSecureConfig
4618 ServiceEndpoint
4700 AsyncOperation
4702 WorkflowWaitSubscription
4703 Workflow
4704 WorkflowDependency
4705 IsvConfig
4706 WorkflowLog
4707 ApplicationFile
4708 OrganizationStatistic
4709 SiteMap
4710 ProcessSession
4800 WebWizard
4802 WizardPage
4803 WizardAccessPrivilege
4810 TimeZoneDefinition
4811 TimeZoneRule
4812 TimeZoneLocalizedName
7100 Solution
7101 Publisher
7102 PublisherAddress
7103 SolutionComponent
7105 Dependency
7106 DependencyNode
7107 InvalidDependency
8000 Post
8001 PostRole
8002 PostRegarding
8003 PostFollow
8005 PostComment
8006 PostLike
9100 Report
9101 ReportEntity
9102 ReportCategory
9103 ReportVisibility
9104 ReportLink
9105 TransactionCurrency
9106 MailMergeTemplate
9107 ImportJob
9333 WebResource
9502 SharePointSite
9508 SharePointDocumentLocation
9600 Goal
9602 GoalRollupQuery
9603 Metric
9604 RollupField
10021 msdyn_PostAlbum
10022 msdyn_PostConfig
10023 msdyn_PostRuleConfig

LinqPad for testing plugin development and workflow activities

We all know that developing and debugging plugins with Microsoft Dynamics CRM 2011 (and 2013) can be troublesome.  Having to code blind and expecting it to work when you deploy it to your server to test it.

I have recently started using LinqPad to develop my plugin and workflow code, testing to make sure the logic works, before copying the code into Visual Studio and deploying.

LinqPad is a very handy tool that reminds me of days before where you could just write code straight into an editor, and run it, not having to create projects, and building and debugging.

Its fully extendable, and once you have it set up, makes writing straight forward C# code and Linq queries very easy.  There are a couple of ways to use it depending on if you prefer early or late bound approaches to manipulating and retrieving your Dynamics Entities.

First things first though, download and install it from the LinqPad website.

LinkPad

Install it on your machine, and run it.

There are two ways of using it, late bind and early bind.  I prefer Late bind (where you reference your entities in a generic fashion) but early bind (where you can reference your entities and attributes by name) has its uses.  For plugin development, late bind is bar far the easiest to get started with as you dont have to generate class files for your Dynamics deployment, and your assemblies are much smaller.

To set up early bind, you simply add the Dynamics URL as a data connection within LinqPad, and your ready to go.  To use late bind, you have to write some C# code to enable a connection to your Dynamics Server (but don’t worry, I am going to provide you with some sample code).

Adding a connection for Early Bind

To add a connection so that you can reference your entities via name, simply click on the Add Connection link at the top left to bring up the “Choose Data Context” window.

LinqPad2

Choose WCF Data Services 5.5 (Odata 3) and on the next screen, enter the following URI :

LinqPad3


You can leave the username and password section blank if your logged in with Active Directory, ad you can also select either XML or JSON. When you hit OK, the data connection will now appear and you can expand it out to show all of your entities, and their attributes.

LinqPad4

You can now begin writing code as long as the code window has the connection set to use the connection you have just created.

Adding a connection using custom code

In my opinion, the best way to use LinqPad is to write your own connection. If you are a registered user of LinqPad, you can use NuGet to download all of the CRM assemblies ready to roll, but I am going to go through the steps required in case you are just using the free version.

The first thing you need to do is to select the My Extensions document in the bottom left window. This is where you can write some code that will allow you to connect to Microsoft Dynamics.  I have enclosed a sample below which you should just be able to copy and paste into the window once you have set up the environment.

First things first, in the My Extensions window, hit the F4 key to bring up the windows properties. In this window, this is where you need to add all of the MSCRM SDK DLL’s you will be requiring, such as

LinqPad5

Simply browse to the files (assuming you have already download the SDK) and add them in to your extensions window. You then also need to set up your namespaces so that you can access them.

Microsoft.Xrm.Client
Microsoft.Xrm.Sdk
Microsoft.Xrm.Sdk.Client
Microsoft.Xrm.Sdk.Deployment.Proxy
System.Collections.Specialized

Now for the code that you will use to connect to Dynamics. Simply Paste the following :

void Main()
{
	// Write code to test your extensions here. Press F5 to compile and run.
}

/// My Extensions is a class to allow a connection to MS Dynamics 2011	
public static class MyExtensions
{
	// Stores a number of specific connection strings
	public static  NameValueCollection ServerConnections = new NameValueCollection();
	// Populates the connection strings
	public static void PopulateConnectionStrings()
		{
			ServerConnections.Add("HALL2013","url=http://crm2013/HALL2013/XRMServices/2011/Organization.svc;");
			ServerConnections.Add("HALL2011","url=http://crm2011/HALL2011/XRMServices/2011/Organization.svc;");
		}
	// GetOrgContext - return a connection 
	public static OrganizationServiceContext GetOrgContext(string connectionString)
		{
			PopulateConnectionStrings();
			CrmConnection connection = CrmConnection.Parse(ServerConnections[connectionString]);
		
			var result = new Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy(
				connection.ServiceUri,
				connection.HomeRealmUri,
				connection.ClientCredentials,
				connection.DeviceCredentials);
		
			result.EnableProxyTypes();
			Microsoft.Xrm.Sdk.Client.OrganizationServiceContext orgcontext = new OrganizationServiceContext(result);
			return orgcontext;
		}
	// GetOrgService - return a connection
	public static IOrganizationService GetOrgService(string connectionString)
		{
			PopulateConnectionStrings();
			CrmConnection connection = CrmConnection.Parse(ServerConnections[connectionString]);
			
			var result = new Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy(
			connection.ServiceUri,
			connection.HomeRealmUri,
			connection.ClientCredentials,
			connection.DeviceCredentials);
			
			result.EnableProxyTypes();
			return result;
		}
}

Hit the green play button, and in theory, it should build and compile.

I have coded this so that you can add extra connection strings in case you have multiple environments. You can then simply instantiate a connection by using :

var conn = MyExtensions.GetOrgContext("HALL2011");

Writing Code

Now, to begin, create a new query by clicking on the plus sign at the top of the main text window. A query will be set up and it should be ready to go with all of the assemblies and namespaces you set up within your extension.  Make sure you have C# Statements selected, and type in the following as a simple test to make sure everything is working :

var conn = MyExtensions.GetOrgContext("HALL2011");

var response = (WhoAmIResponse)conn.Execute(new WhoAmIRequest());

response.Dump();

Should give you the following

LinqPad1Res1

The results, by default are rendered as XML, but you can click the grid button just along from the run button to display the data as a grid. You will notice the line response.Dump().  LinqPad extends everything with this command, and will output it within the results pane.  You can use this to output variables and objects so you can see what it looks like.

LinqPad1Res2

And your set. You can now right code, linq queries etc and run them straight away.  If you change the Language selector to C# Program, you can even create functions and test them just as you would in Visual Studio.  This allows you to test all of your plugin and workflow activities logic within LinqPad before putting the code into your CRM server. You can easily add other reference assemblies and namespaces to your queries as you see fit.

Another example (using an email template and then finding the attachments)

InstantiateTemplateRequest instTemplateReq = new InstantiateTemplateRequest

{

TemplateId = new Guid("CE6E9346-8FFB-E311-8997-005056A507B0"),

ObjectId = new Guid("995623E6-58F8-E311-8997-005056A507B0"),

ObjectType = "incident"

};

InstantiateTemplateResponse instTemplateResp = (InstantiateTemplateResponse)conn.Execute(instTemplateReq);


Guid id = new Guid("CE6E9346-8FFB-E311-8997-005056A507B0");

var files = from f in conn.CreateQuery("activitymimeattachment")

where (Guid)f["objectid"] == id &&

(string)f["objecttypecode"] == "template"

selectnew {f};

files.Dump();

Debugging within Visual Studio

And it gets better, why not just use LinqPad to set up some test data, and then call your plugin code directly and debug within Visual Studio.

In LinkPad, within your query window, hit the F4 key and add your plugin assembly and its namespace to your query properties.

In LinqPad, you can set up any variables your plugin code may need. As an example, I have started to place my plugin logic within a separate static class with various methods that take parameters.  This way, the plugin can deal with the input and output parameters, but I then have separate code blocks that do the processing.  In LinqPad, you can then simply call this logic with the appropriate parameters.

If you then use the command

Debugger.Launch();

It will kick off Visual Studio’s debugger and you can step through your plugin code. Simples.

Child Workflows in Dynamics CRM 2011

While facing a particular issue in how to design some workflows that I just knew where going to change in structure down the line, I found this very useful article which I would recomend having a look at.

When and How to use Child Workflows

I have been using them to add all of my procedural code, such as getting queue’s, creating emails etc and all the related setup.  This would be the child workflow.

Then all my condition statements and decision making appears in the main workflow which simply calls the child workflow at the correct time.  This means if your main workflows structure changes, you do not have to redo all of the other steps (as we all know how poor the Dynamics Workflow Designer is at changing structure, moving things and cut,copy,paste).

This is the way I will be handling things from now on.

Updating Plugins and Workflow Activities

When updating plugins or workflow activities, if you are adding input / output parameters, or changing the name or display, sometimes after updating, the changes do not take effect within the Dynamics Workflow editor.

Instead of having to stop and start services, did you know that the update can be triggered by changing the assembly version information before you update.

In Visual Studio, just edit the properties of your Workflow Project as outlined in the screenshots, increment the assembly version, and rebuild and deploy.  The change in version will be enough for Dynamics to refresh its cache for using the activity in the workflow designer.

assemblyinfo1assemblyinfo2

Migrating an Organisation to a new server

Sometimes, you need to be able to move or duplicate an existing Microsoft Dynamics CRM 2011 organisation database to a new or different server, perhaps for testing purposes, or just simply for a backup.  This is relatively straight forward as the entire organisation is kept in the one database.

To do this, from within SQL Server Management Studio, you first need to backup the database by right clicking the database name, and selecting Backup from the Tasks menu.

Migrate

Once you have created a backup of your organisation database, on the new sql server that will be hosting the new environment, you need to restore the database so that it is available dor CRM to use.  You do this from the Tasks menu as well.

Migrate1

Once the SQL Database is in place, on the Dynamics Application Server you need to use the Import function within the Deployment Manager tool to import the database into an organisation.

Migrate4

Select the SQL Server and the name of the database.

Migrate5

This will then attempt to map the users within the source database into the current domain and start the import process.  When this is complete, you will have a fully functioning copy of the organisation.

Shared Data Source for reporting

When developing reports for Microsoft Dynamics using SQL connections, it is recommended to use a shared data source so that you can include your reports within a solution and allow them to be promoted across different environments without having to amend the data source.

Microsoft Dynamics provides a Data Source called MSCRM_DataSource which always points to its SQL environment, so if your reports use a shared data source called the same, it doesn’t matter which environment it is installed on, it will be using the correct Data Source for your SQL server.

Shared Data Source in Report Project
Shared Data Source in Report Project

CRM 2011 Checking for changed fields in a form

Sometimes, when trying to close a form down in Dynamics, or trying to print preview, you will often get the following message.

isDirty

This will nearly always mean that when the form has loaded, some of the attributes have actually changed, so Dynamics detects that the form is not up to date, and requires a save before proceeding.

This can sometimes be tricky to work out what has changed, so below is a useful little trick.

In Internet Explorer, hit the F12 key when the form is displayed, and select the script tag.  Copy and paste the following code in to the script input area and run it.  This should then print out the name of all of your “Dirty” fields.

var listOfAttributes = frames[0].Xrm.Page.getAttribute();
for(var attrib in listOfAttributes){
   var currentAttrib = listOfAttributes[attrib];
   if (currentAttrib.getIsDirty && currentAttrib.getIsDirty()){
     console.log(currentAttrib.getName());
   }
}