Posted on 2. August 2014

Polymorphic Workflow Activity Input Arguments

I often find myself creating 'utility' custom workflow activities that can be used on many different types of entity. One of the challenges with writing this kind of workflow activity is that InArguments can only accept a single type of entity (unlike activity regarding object fields).

The following code works well for accepting a reference to an account but if you want to accept account, contact or lead you'd need to create 3 input arguments. If you wanted to make the parameter accept a custom entity type that you don't know about when writing the workflow activity then you're stuck!

[Output("Document Location")]
[ReferenceTarget("account")]
public InArgument<EntityReference> EntityReference { get; set; }

There are a number of workarounds to this that I've tried over the years such as starting a child work flow and using the workflow activity context or creating an activity and using it's regarding object field – but I'd like to share with you the best approach I've found.

Dynamics CRM workflows and dialogs have a neat feature of being about to add Hyperlinks to records into emails/dialog responses etc. which is driven by a special attribute called 'Record Url(Dynamic)'

This field can be used also to provide all the information we need to pass an Entity Reference.

The sample I've provide is a simple Workflow Activity that accepts the Record Url and returns the Guid of the record as a string and the Entity Logical Name – this isn't much use on its own, but you'll be able to use the DynamicUrlParser.cs class in your own Workflow Activities.

[Input("Record Dynamic Url")]
[RequiredArgument]
public InArgument<string> RecordUrl { get; set; }
The DynamicUrlParser class can then be used as follows:

var entityReference = new DynamicUrlParser(RecordUrl.Get<string>(executionContext));
RecordGuid.Set(executionContext, entityReference.Id.ToString());
EntityLogicalName.Set(executionContext, entityReference.GetEntityLogicalName(service));

 

The full sample can be found in my MSDN Code Gallery.

@ScottDurow

Posted on 6. June 2014

Monitor, Monitor, Monitor

I once heard someone say that "the great thing about Dynamics CRM is that it just looks after itself" Whilst CRM2013 is certainly very good at performing maintenance tasks automatically, if you have a customised system it is important to Monitor, Monitor, Monitor! There are some advanced ways of setting up monitoring using tools such as System Center but just some regular simple monitoring tasks will go a long way for very little investment on your part:

1) Plugin Execution Monitoring

There is a super little entity called 'Plugin-in Type Statistics' that often seems to be overlooked in the long list of advanced find entities. This entity is invaluable for tracing down issues before they cause problems for your users and as defined by the SDK it is "used by the Microsoft Dynamics CRM 2011 and Microsoft Dynamics CRM Online platforms to record execution statistics for plug-ins registered in the sandbox (isolation mode)."

The key here is that it only records statistics for your sandboxed plugins. Unless there is a good reason not to (security access etc.) I would recommend that all of your plugins be registered in sandbox isolation. Of course Dynamics CRM online only allows sandboxed plugins anyway so you don't want to put up barriers not to move to the cloud.

To monitor this you can use advanced to show a sorted list by execution time or failure count descending:

If you spot any issues you can then proactively investigate them before they become a problem. In the screen shot above there are a few plugins that are taking more than 1000ms (1 second) to execute, but their execution count is low. I look for plugins that have a high execution count and high execution time, or those that have a high failure percent.

2) Workflow & Asynchronous Job Execution Monitoring

We all know workflows often can start failing for various reasons. Because of their asynchronous nature these failures can go unnoticed by users until it's too late and you have thousands of issues to correct. To proactively monitor this you can create a view (and even add to a dashboard) of System Jobs filtered by Status = Failed or Waiting and where the Message contains data. The Message attribute contains the full error description and stack trace, but the Friendly message just contains the information that is displayed at the top of the workflow form in the notification box.

3) Client Latency & Bandwidth Monitoring

Now that you've got the server-side under control you should also look at the client connectivity of your users. There is a special diagnostics hidden page that can be accessed by using a URL of the format:

http://<YourCRMServerURL>/tools/diagnostics/diag.aspx

As described by the implementation guide topic, "Microsoft Dynamics CRM is designed to work best over networks that have the following elements:

  • Bandwidth greater than 50 KB/sec
  • Latency under 150 ms"

After you click 'Run' on this test page you will get results similar to that shown below. You can see that this user is just above these requirements!

You can read more about the Diagnostic Page in Dynamics CRM. You can also monitor the client side using the techniques I describe in my series on Fiddler:

If you take these simple steps to proactively monitor your Dynamics CRM solution then you are much less likely to have a problem that goes un-noticed until you get 'that call'!

@ScottDurow

Posted on 15. April 2014

Fiddler2: The tool that gives you Superpowers – Part 3

This post is the third post in the series 'Fiddler – the tool that gives you superpowers!'

Faster than a Speeding Bullet

If you have done any development of Web Resources with Dynamics CRM then I'm certain that you'll have become impatient whilst waiting to first deploy your solution and then publish it before you can test any changes. Everytime you need to make a change you need to go round this loop which can slow down the development process considerably. Using the Auto Responders I described in my previous post (Invisibility) you can drastically speed up this development process by using Fiddler to ensure changes you make to a local file in Visual Studio are reflected inside Dynamics CRM without waiting for deploying and publishing. You make the changes inside Visual Studio, simply save and refresh your browser and voilà!

Here some rough calculations on the time it could save you on a small project:

Time to Deploy

15

seconds

Time to Publish

15

seconds

Debug iterations

20

 

Number of web resources

30

 

Development Savings

5

hours

Time to reproduce live data in test/development

1

hour

Number of issues to debug in live

10

 

Testing Savings

10

hours

     

Total Savings for small project

15

hours

 

What is perhaps more important about this technique that it saves the frustration caused by having to constantly wait for web resource deployment and ensures that you stay in the development zone rather than being distracted by the latest cute kitten pictures posted on facebook!

Do remember to deploy and publish your changes once you've finished your development. It seems obvious but it is easily forgotten and you're left wondering why your latest widget works on your machine but not for others!

More information can be found on this at the following locations:

@ScottDurow

Posted on 15. April 2014

Fiddler2: The tool that gives you Superpowers - Part 2

This post is the second post in the series 'Fiddler – the tool that gives you superpowers!'

Invisibility

This time it's the superpower of Invisibility! Wow I hear you say!

Fiddler is a web debugger that sits between you and the server and so is in the unique position of being able to listen for requests for a specific file and rather than returning the version on the server return a version from your local disk instead. This is called and 'AutoResponder' and sounds like a super-hero it's self – or perhaps a transformer (robots in disguise).

If you are supporting a production system then the chances are that at some point your users have found an issue that you can't reproduce in Development/Test environments. Auto Responders can help by allowing us to update any web resource (html/JavaScript/Silverlight) locally and then test it against the production server without actually deploying it. The Auto Responder sees the request from the browser for the specific web resource and rather returning the currently deployed version, it gives the browser your local updated version so you can test it works before other users are affected.

Here are the steps to add an auto responder:

1) Install Fiddler (if you've not already!)

2) Switch to the 'Auto Responders' tab and check the two checkboxes 'Enable automatic responses' and 'Unmatched requests pass-through'

3) To ensure that the browser requests a version of the web resource rather than a cached version from the server you'll need to clear the browser cache using the convenient 'Clear Cache' button on the tool bar.

4) You can ensure that no versions get subsequently cached by selecting Rules-> Performance-> Disable Caching.

5) You can now use 'Add Rule' to add an auto responder rule. Enter a regular expression to match the web resource name

regex:(?insx).+/<Web Resource Name>([?a-z0-9-=&]+\.)*

then enter the file location of the corresponding webresource in your Visual Studio Developer Toolkit project.

You are now good to go so that when you refresh your browser the version of your web resource will be loaded into the browser directly from your Visual Studio project. No need to publish a file to the server and affect other users.

There is one caveat to this – If the script that you are debugging updates data then this approach is probably not a good idea until you are have fully tested the script in a non-production environment. Only once you have QAed and ready to deploy can be it be used against the production environment to check that the specific user's issue is fixed before you commit to deploying it to all users.

Read the next post on how to be faster than a speeding bullet!

@ScottDurow

 

Posted on 15. April 2014

Fiddler2: The tool that gives you Superpowers – Part 4

This post is the fourth and final post in the series 'Fiddler – the tool that gives you superpowers!'

Ice Man

Perhaps Ice Man is the most tenuous super power claim but it's regarding a very important topic – HTTP Caching. Having a good caching strategy is key to having good client performance and not over-loading your network with unnecessary traffic. Luckily Dynamics CRM gives us an excellent caching mechanism – but there are situations where it can be accidently unknowingly bypassed:

  1. Not using relative links in HTML webresources
  2. Loading scripts/images dynamically without using the cache key directory prefix
  3. Not using the $webresource: prefix in ribbon/sitemap xml.

Luckily we can use Fiddler to keep our servers running ice cold by checking that files that are not being cached when they should be. There are types of caching that you need to look for:

Absolute expiration

These web resources will not show in Fiddler at all because the browser has located a cached version of the file with an absolute cache expiration date and so it doesn't need to request anything from the server. By default CRM provides an expiration date of 1 year from the date requested, but if the web resource is updated on the server then the Url changes and so a new version is requested. This is why you see a request similar to /OrgName/%7B635315305140000046%7D/WebResources/somefile.js. Upon inspection of the response you will see an HTTP header similar to:

HTTP/1.1 200 OK
Cache-Control: public
Content-Type: text/jscript
Expires: Tue, 14 Apr 2015 21:18:35 GMT

Once the web resource is downloaded on the client it is requested again until April 14 2015 unless a new version is published where CRM will request the file using a new cache key (the number between the Organization name and the WebResources directory). You can read more about this mechanism on my post about web resource caching.

ETAG Cached files

These resource are usually images and static JavaScript files that are assigned an ETAG value by the server. When the resource changes on the server it is assigned a different ETAG value. When the browser requests the file it sends the previous ETAG value if it hasn't been modified then the server responds with a 304 response meaning that the browser can use the local cached file.

Files that use ETAG caching will show in grey in Fiddler with a response code of 304:

During your web resource testing it is a good idea to crack open Fiddler and perform your unit tests – you should look for any non-304 requests for files that don't need to be downloaded every time they are needed.

Another way to ensure that your servers are running cool as ice is to look at the request execution length. Occasionally code can be written that accidently returns much too much data than required - perhaps all attributes are included or a where criteria is missing. These issues don't always present themselves when working on a development system that responds to queries very quickly, but as soon as you deploy to a production system with many users and large datasets, you start to see slow performance.

There are a number of ways you can test for this using Fiddler:

Visualise Request Times

The order in which your scripts, SOAP and REST requests are executed in can greatly affect the performance experienced by the user and so you can use Fiddler's Time line visualizer to see which requests are running is series and which are running in parallel. It also shows you the length of time the requests are taking to download so that you can identify the longest running requests and focus your optimisation efforts on those first.

  •  

    Simulate Slow Networks

    If you know that your users will be using a slow network to access CRM or you would just like to see how the application responds when the requests start to take longer because of larger datasets you can tell fiddler to add an artificial delay into the responses. To do this you can use the built in Rules->Performance->Simulate Modem Speeds but this usually results in an unrealistically slow response time. If you are using Auto Responders you can right-click on the Rule and use set Latency – but this won't work for Organization Service/REST calls. The best way I've found is to use the Fiddler Script:

    1) Select the 'Fiddler Script' Tab

    2) Select 'OnBeforeRequest' in the 'Go to' drop down

    3) Add the following line to the OnBeforeRequest event handler.

    This will add a 50 millisecond delay for every kB requested from the server which assuming there was no time server time would result in ~160 kbps downloads.

    If you've not used Fiddler for your Dynamics CRM Development yet I hope these posts are enough to convince you that you should give it a try – I promise you'll never look back!

    @ScottDurow

    Posted on 15. April 2014

    Fiddler2: The tool that gives you Superpowers – Part 1

    The next few posts are for those who saw me speaking at the most recent CRMUG UK Chapter meeting about Fiddler2 and wanted to know more (and as a thank you to those who voted for me in X(rm) factor!). I've been using Fiddler for web debugging for as long as I can remember and I can honestly say that I could not live without it when Developing Dynamics CRM extensions as well as supporting and diagnosing issues with existing solutions. I first blogged about it in connection with SparkleXRM development but this post elaborates further on the super powers it gives you!

    What is a Web Debugger?

    Fiddler2 is a Web Debugger which basically means that it sits between your browser and the server just like any normal proxy, but the difference is that it shows you all the HTTP traffic going back and forwards, allows you to visualise it in an easy to read format as well as allowing you to 'Fiddler' with it – hence the name.

    You can easily install fiddler for free by downloading it from http://www.telerik.com/fiddler.

    The following posts describe the superpowers that Fiddler can give you whilst you are developing solutions or supporting your end users.

    X-Ray Vision

    When you perform any actions in your browser whilst Fiddler is running then each and every request/response is being logged for your viewing pleasure. This log is incredibly useful when you need to see what requests your JavaScript or Silverlight is sending to the server. It shows you the error details even when the user interface may simply report that an 'Error has occurred' without any details. The prize for the most unhelpful error goes to Silverlight with its 'Not Found' message – the actual error can only be discovered with a tool like Fiddler2 by examining the response from the server to see the true exception that is hidden by Silverlight. The HTTP error code is your starting point and Fiddler makes it easy to see these at a glance by its colour coding of request status codes - the most important of which are HTTP 500 requests that are coloured red. For any solution you are developing, the bare minimum you should look at is for any 404 or 500 responses.

    If you wanted to diagnose a problem that a user was having with CRM that could not reproduce then try following these steps:

    1. Ask the user experiencing the issue to install Fiddler2 (this may require administrator privileges if their workstation is locked down).
    2. Get to the point where they can reproduce the problem – just before they click the button or run the query, or whatever!
    3. Start Fiddler
    4. Ask the user to reproduce the issue
    5. Ask the user to click File->Save->All Sessions and send you the file.
    6. Once you've got the file you can load it into your own copy of Fiddler to diagnose the issue.

    If the user has IE9 or above and they are not using the outlook client then the really neat thing about the latest version of Fiddler is that it can import the F12 Network trace. This allows you to capture a trace without installing anything on the client and then inspect it using Fiddlers user interface. To capture the network traffic using IE:

    1. Get to the point where they are about to reproduce the issue
    2. Press F12
    3. Press Ctrl-4
    4. Press F5 (to start the trace)
    5. Reproduce the issue
    6. Switch back to the F12 debugger window by selecting it
    7. Press Shift-F5 to stop the trace
    8. Click the 'Export Captured Traffic' button and send you the file

    Now you can load this file into fiddler using File->Import Sessions->IE's F12 NetXML format file.

    Once you found the requests that you are interested in you can then use the inspectors to review the contents – the request is shown on the top and the response is shown on the bottom half of the right panel. Both the request and response inspectors gives you a number of tabs to visualise in different ways depending on the content type. If you are looking at JavaScript, HTML or XML your best bet is the SyntaxView tab that even has a 'Format Xml' and 'Format Script/JSON' option on the context menu. This is great to looking at SOAP requests and responses that are sent from JavaScript to make sure they are correctly formatted.

    The following screen shows a soap request from JavaScript and inspectors in syntax view with 'Format Xml' selected.

  •  

    This technique is going to save you lots of time when trying to work out what is going on over the phone to your users!

    Next up is Invisibility!

    @ScottDurow

     

    Posted on 28. February 2014

    Ribbon Workbench updated - getServerUrl is removed in CRM2013 UR2

    With CRM2013 UR2 being released very soon I have made an update to the Ribbon Workbench that you'll be prompted to install by the auto update when you next open the Ribbon Workbench. I strongly advise you to install this update before you install UR2 otherwise the Ribbon Workbench will no longer work, and you'll need to re-download and re-install.

    This is because when I updated the Ribbon Workbench for CRM2013 I retained the use of getServerUrl – the update now uses getClientUrl because UR2 has removed getServerUrl altogether.

    getServerUrl was deprecated back in CRM2011 with UR12 so it's probably about time it was removed anyways!

    Posted on 28. January 2014

    Chrome Dynamics CRM Developer Tools

    Chrome already provides a fantastic set of Developer tools for HTML/Javascript, but now thanks to Blake Scarlavai at Sonoma Partners we have the Chrome CRM Developer Tools.

    This fantastic Chome add in provides lots of gems to make debugging forms and testing fetchXml really easy:

    Form Information
    - Displays the current form’s back-end information
    - Entity Name
    - Entity Id
    - Entity Type Code
    - Form Type
    - Is Dirty
    - Ability to show the current form’s attributes’ schema names
    - Ability to refresh the current form
    - Ability to enable disabled attributes on the current form (System Administrators only)
    - Ability to show hidden attributes on the current form (System Administrators only)


    Current User Information
    - Domain Name
    - User Id
    - Business Unit Id


    Find
    - Ability to open advanced find
    - Set focus to a field on the current form
    - Display a specific User and navigate to the record (by Id)
    - Display a specific Privilege (by Id)


    Test
    - Ability to update attributes from the current form (System Administrators only)
    - This is helpful when you need to update values for testing but the fields don’t exist on the form


    Fetch
    - Execute any Fetch XML statement and view the results


    Check it out in the chrome web store - https://chrome.google.com/webstore/detail/sonoma-partners-dynamics/eokikgaenlfgcpoifejlhaalmpeihfom

    Posted on 5. December 2013

    Form File->Properties dialog in CRM 2013

    One of the lesser known features of CRM 2011 was the File->Properties dialog that you could view on a record form. It would look something like:

    This dialog was very useful for finding out the effective permissions of the current user on a particular record but in CRM 2013 it is no longer present in the user interface – but it is still there in the background!

    If you used to use this dialog in CRM 2011 I've created a managed solution that provides you with a Properties button on the Command Bar that shows the CRM 2013 version of this dialog.

    FormPropertiesButton_1_0_0_0_managed.zip (2.39 kb)
    (The usual disclaimer applies)

    After installing the solution, you should see a new button in the Command Bar overflow menu:

    The dialog looks like this:

    The only down side is clicking OK gives the 'Are you sure you want to navigate away from this page' dialog.

    Hope this helps.

    @ScottDurow

     

    Posted on 27. September 2013

    Microsoft.Xrm.Client (Part 3b): Configuration via app/web.config

    In this series we have been looking at the Developer Extensions provided by the Microsoft.Xrm.Client assembly:

    Part 1 - CrmOrganizationServiceContext and when should I use it?

    Part 2 - Simplified Connection Management & Thread Safety

    Part 3a – CachedOrganizationService

    So far in this series we have learnt how to use the Microsoft.Xrm.Client developer extensions to simplify connecting to Dynamics CRM, handling thread safety and client side caching.

    This post shows how the configuration of the Dynamics CRM connection and associated OrganizationService context can be configured using an app.config or web.config file. This is esspecially useful with ASP.NET Portals and Client Applications that don't need the facility to dynamically connect to different Dynamics CRM Servers.

    If you only want to configure connection string, then you would add a app.config or web.config with the following entry:

    <connectionStrings>
    <add name="Xrm" connectionString="Url=http://<server>/<org>"/>
    </connectionStrings>

    The Connection string can take on the following forms:

    On Prem (Windows Auth)

    Url=http://<server>/<org>;

    On Prem (Windows Auth with specific credentials)

    Url=http://<server>/<org>; Domain=<domain>; Username=<username>; Password=<password>;

    On Prem (Claims/IFD)

    Url=https://<server>; Username=<username>; Password=<password>;

    On Line (Windows Live)

    Url=https://<org>.crm.dynamics.com; Username=<email>; Password=<password>; DeviceID=<DeviceId>; DevicePassword=<DevicePassword>;

    On Line (O365)

    Url=https://<org>.crm.dynamics.com; Username=<email>; Password=<password>;"

    You can find a full list of connection string parameters in the SDK

    You can then easily instantiate an OrganizationService using:

    var connection = new CrmConnection("Xrm");
    var service = new OrganizationService(connection);

    If you want to simplify creation of the ServiceContext, and make it much easier to handle thread safety – you can use a configuration file that looks like:

    <configuration>
    <configSections>
        <section name="microsoft.xrm.client" type="Microsoft.Xrm.Client.Configuration.CrmSection, Microsoft.Xrm.Client"/>
    </configSections>
    <microsoft.xrm.client>
        <contexts>
            <add name="Xrm" type="Xrm.XrmServiceContext, Xrm" serviceName="Xrm"/>
        </contexts>
        <services>
            <add name="Xrm" type="Microsoft.Xrm.Client.Services.OrganizationService, Microsoft.Xrm.Client"
            instanceMode="[Static | PerName | PerRequest | PerInstance]"/>
        </services>
    </microsoft.xrm.client>
    </configuration>

    You can then instantiate the default context simply by using:

    var context = CrmConfigurationManager.CreateContext("Xrm") as XrmServiceContext;

    The most interesting part of this is the instanceMode. It can be Static, PerName, PerRequest, PerInstance. By setting it to PerRequest, you will get a OrganizationService per ASP.NET request in a portal scenario – making your code more efficient and thread safe (provided you are not using asynchronous threads in ASP.NET).

    The examples above I find are the most common configurations, although you can also specify multiple contexts with optional caching if required for specific contexts – the SDK has a full set of configuration file examples. Using the configuration file technique can simplify your code and ensure your code is thread safe.

    On the topic of thread safety, it was recently brought to my attension that there appears to a bug with the ServiceConfigurationFactory such that if you are instantiating your OrganizationService passing the ServiceManager to the constructor in conjunction with EnableProxyTypes, you can occationally get a threading issue with the error "Collection was modified; enumeration operation may not execute". The work around to this is to ensure that the call to EnableProxyTypes is wrapped in the following:

    if (proxy.ServiceConfiguration.CurrentServiceEndpoint.EndpointBehaviors.Count == 0)
    {
        proxy.EnableProxyTypes();
    }

    More information can be found in my forum post.

    Next up in this series are the Utility and extension functions in the Microsoft.Xrm.Client developer extensions.

    @ScottDurow