One of Rupert Murdoch's journalists gets drunk at the Walkley Awards and 'tries' to assault Stephen Mayne.

Since the 'Read' action for our solution can't be triggered by a callout we will need to enlist the assistance of the Form onLoad event. You will need to install a HTTP Debugging Proxy like Fiddler to get build this solution.

We will write some JavaScript to call the CRM web services on the Form onLoad event. My colleague Arash has a good post on his blog on how to do this. The tricky part is building the SOAP message and that is where Fiddler comes in handy.

1. Create a basic Console app to call the CRM Web Service and add a record to the log entity.
2. Capture that traffic using Fiddler and inspect the SOAP packet.
3. Throw away the Console app.
4. Build up your JavaScript as Arash describes.
5. Add your script to the onLoad Events of the entities which you wish to monitor.

That's it!

Here is my script which I used.

Next: In Part 6 we will create an installer package to deploy the application.

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

I'm making a few infrastructure changes with the PhilipRichardson.org domain. If you are trying to reach me at philip@philiprichardson.org and receive no reply - please try my microsoft.com account. There 'should' be no disruption to the website and sharepoint infrastructure.

Update: Everything is working OK. Email, WWW and SharePoint all functioning normally.

Creating the callout to record the create, update, delete, assign and set state actions is not too difficult. First you should familiarize yourself with callout development in Microsoft CRM. It's pretty easy and we have some nice samples to get you started. It's all in our SDK: web or download. Note that callouts are sometime referred to as Business Logic Extensions in the SDK.

I want to use a generic (little 'g' generic not big 'G' generic) callout which all entities will consume.

Here is the code I used in my version of this solution. As you can see it's hardly brain surgery.

1. Callout gets fired.
2. Appropriate method is called (eg. PostCreate). This method calls the UpdateCrm method and passes through the 'action' and userContext and entityContext parameters.
3. UpdateCRM method does the following:
   1. Gets the URL of the CRM server from the registry. There are other ways to do this - but I'm a little obsessed with the registry at moment.
   2. Then create the CRM web service stuff and set the caller id to that of the user who triggered the callout.
   3. Then make a regular web service call to add a new record to the log entity.

The one big gotcha: Do not register this callout for the log entity!

The one little gotcha: Do not register this callout for the Assign Event on Organizational Owned entities (because they can't be assigned)!

Next: In Part 5 we will develop the code to log the Read action.

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

Building the CRM Logging Entity is trivial - however we need to think through how the solution will actually perform the logging. The callout can call the web service using the user's credentials or with an administrative set. The Form however must call the webservice using the user's credentials. Therefore we will need to give regular users Create privileges on this entity. We can prevent them from deleting logs - but they will be able to create false logs.

I want this entity to be able to log data from any entity in the system so I won't build any hardcoded relationships. I'll use the entity type code (which I can get from the callout and the form) and store IDs with nvarchars.

1. Create a new Entity
   1. Name = Log
   2. Plural Name = Logs
   3. Ownership = Organization
   4. Schema Name = philipri_log
   5. Notes = No
   6. Activities = No
   7. Show in Settings = Yes
   8. Primary Attribute - This will store a description of the CRUD action (eg. Create).
      1. Display Name = Action
      2. Schema Name = philipri_Action
      3. Requirement Level = No Constraint
2. Add Attribute - This will store the integer referring to the Entity.
   1. Display Name = EntityTypeCode
   2. Schema Name = philipri_entitytypecode
   3. Requirement Level = No Constraint
   4. Type = Int
   5. Format = None
   6. Minimum Value = 0
   7. Maximum Value = 2,147,483,647
3. Add Attribute - This will be the GUID of the actual record on which the action is being performed
   1. Display Name = RecordId
   2. Schema Name = philipri_recordid
   3. Requirement Level = No Constraint
   4. Type = nvarchar   
   5. Format = text
1. Maximum Length = 50
4. Then go an strip all the fields off the form. You want to make it hard for people to create 'phony log records'.
5. Create some nice practical views. As you can see we use the Created By and Created On attributes to show which user performed the action.
   
   

OK so now we have a nice tidy entity to store the Log data. We can access this entity with our strongly typed web service, export to excel, write reports off it etc.

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

Before we begin any coding we must gather business requirements. For a small solution like a usage logger we don't need a spec or some large Wiegnarian document. However if you are building something larger: gathering requirements in a consistent and professional manner is critical.

Here are the requirements which I sketched out for the solution:

The purpose of this solution is to create a record of user actions to measure adoption. The solution shall record create, read, update and delete actions performed on all customizable and custom entities within a Microsoft CRM 3.0 implementation. This actions should be written to a normal CRM entity which is available for querying and reporting. Create, Read, Update and Delete access to the CRM log entity shall be restricted to a subset of users.

Let's dissect these requirements to see what kind of technical design we might use. We need to monitor the classic set of CRUD actions performed by the system. A callout seems like a likely candidate since it can monitor Create, Update and Delete events. We'll also need to monitor the Assign and Set State events as these are a subset of Update. For Reads we have the weakest solution as we will need to do something to the Forms and we have no possible solution for Reads on the Grid.

At this point we would want to go back to our 'customer' and discuss the Read issue. If they plan to really use this solution for security purposes then monitoring Reads via a form event is probably not a great solution. An example might be a police department wanting to know who had viewed someone's criminal record etc. If we really are just monitoring adoption then everything should be OK. It always pays to double check 'borderline' requirements like this.

In Summary: We will collect the actions using a callout (a post callout to be precise) and a JavaScript event on the Form. We'll need to write the data into a CRM entity and set it's permissions accordingly.

Next: In Part 3 we will create the CRM Entity to store the Logs.

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

I spend a small percentage of my time developing solutions for CRM. It's important as Program Managers to gain an insight into our target persona's experiences. I typically focus on the VAR (Value Added Reseller) - ie. the Consulting Partners who sell and implement CRM. They often build small to medium solutions unique to one (or few) customers. The other end of the spectrum is the ISVs (Independent Software Vendors) who typically create large horizontal/vertical solutions and maintain a professional software engineering team.

More information on our personas can be found here. The ones I think about a lot are Sean, Mort and Isaac. I also consider Nancy, Susan and Chris. When I meet customers and partners I'm always comparing them to a persona. This is probably unhealthy...

The solution I recently developed creates an log of CRM usage. Typically such a log is used to monitor adoption (ie. have you herded your cats into the barn?). In a series of blog posts I'll take you through the process of developing the solution and the deployment package. Stay tuned.

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft crm dynamics crm microsoft crm

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.

Tags: microsoft